We share our thoughts on the AWS Sustainability Pillar that forms part of the Well-Architected Framework. It is the sixth and final part of a series of talks. The Sustainability Pillar is a new pillar that AWS added at re: Invent two years ago. What’s nice about sustainability is that it rolls up a lot of good practices and is a straightforward measure.
Today, we’re talking about the AWS Sustainability Pillar. We’ve talked quite a lot about sustainability. It’s a new pillar added at AWS re: Invent at the end of 2021. So we’ve talked about it a fair amount because (1) it’s new and exciting, and (2) we’ve been following this for the past two years, and it’s a brilliant addition. What’s nice about AWS sustainability is that it rolls up a lot of good practices and is a straightforward measure.
It’s tough to measure carbon, but it’s effortless to understand when someone like AWS measures for you. This pillar is slightly different; it doesn’t have all the same questions. They may change it eventually. But it’s more like a list of best practices broken down into sections. So let’s list them out:
- Region Selection,
- User Behaviour Patterns,
- Software and Architecture Patterns,
- Data Patterns,
- Hardware Patterns,
- and Development and Deployment Process.
There’s a bunch of questions within those. Let’s fly through them.
Region Selection
Region Selection is relatively straightforward. Cloud providers supply some regions with greener energy than others. Some regions use non-sustainable resources, depending on where you are. If you don’t have massive latency requirements or a real need for super-fast, low latency, then you’re best putting it into a more sustainable region. US 1 and Ireland are sustainable regions. There are others across the AWS ecosystem. Google and Azure have the same. Where you put your workload can have a sustainability impact. All other things being equal, go for the greener one. Go for the most sustainable region for your workload.
Some regions need to be more sustainable, and some are very sustainable. A lovely phrase that Werner Vogels used during the launch that Adrian Cockcroft also uses: ‘The cloud providers look after the sustainability of the cloud; they’ll make the data centres as sustainable as possible. It’s our responsibility to look after sustainability in the cloud.’. So they’ll have a sustainable data centre, and we have to design sustainable workloads. So that was a nice split. With region selection, you should put workload there if they say a particular region is green.
The difficulty of sustainability in your data centres
With a move to the cloud, if you’re on your data centres, you’re going to have a hard time trying to be as sustainable or green as the cloud providers because they’re investing hundreds of millions or billions probably across the globe to sustainably power, cool and provide all the resources they need for the data centre.
It is the shared responsibility model. The white paper discusses the separation of responsibility for that pillar. It’s good to touch upon those as we run through it. Significantly, cloud providers will keep their side of it as green as possible and coach you, as an architect or business owner, on making good decisions concerning what you’re doing in your space, what you’re building on the cloud, and the various sustainable approaches.
It is the whole premise of the cloud. An organisation like Amazon, Microsoft or Google will do data centres better than you. If you look at User Behaviour Patterns and use their assets elastically using the latest technology, it will be more sustainable, efficient and cheaper on modern cloud. If you go down the legacy cloud route and treat the public cloud like a data centre, then you’re not going to be very sustainable, you’re not going to be very cheap, and you’re not going to be very efficient. So it’s that elasticity thing that we know was popular ten years ago when the cloud started, but people have forgotten about it.
User Behaviour Patterns
Under the User Behaviour Patterns section, it’s about aligning your SLAs with your sustainability goals. That screams out at us, especially with recent climate crisis news. With the requirement for boardroom-level mandates, these concerns will be more prevalent and visible to all teams, up and down the hierarchy. The C-Suite will ask how green your solution is. How green is your product? How green is your business? Making sure you align workloads and solutions on the cloud to SLAs is what we’re going to be concerned with over the following number of years.
It’s no different from buying a soft drink. You have to know if it’s in sustainable packaging. It’s a big issue. In the future, when you use a digital service, you’ll want to use something sustainable, which is effectively cloud.
Software Architecture Patterns
The following section is Software Architecture Patterns. This one is interesting. It’s about keeping your code base and architecture efficient, such as refactoring optimization and more effective data access.
It’s good practice as it ties back into efficient design. When you work in enterprise spaces, you question the value of older business products running in the background. You’ve got to assess if this is worth the compute constantly. Is this worth the cycle times? Are we getting value for money? Now, you’ve got to factor in sustainability. Is it racking up your carbon footprint? It’s another factor to consider. Should we invest time in reducing the amount of maintenance? How efficiently or inefficiently is something running? It is an exciting area for people working in large organisations supporting lots of different apps and workloads.
Impact on devices
There’s an interesting question on optimising the impact on customer devices and equipment. If you have an inefficient client-side app with a lot of data processing on the device that it doesn’t need, you could sustain the lifetime of that device by having a more effective and efficient client-side app, web app, or mobile app. There are lots of things we can concern ourselves with.
If you’re on a mobile app, do you need to send the most oversized image over the network? And make the device or optimise it accordingly? Or can you optimise it ahead of time? There’s a bunch of stuff around needing to be faster than you need to be. Another thing about architecture is that in the olden days, there were constraints. So you had to do proper architecture. There are some modern apps with massive amounts of scale. As it scales, the architecture is not ready, and they rely on the network. You’ve got modern technology, but it needs to be optimised.
The question is, ‘How do you use software patterns and architectures that best support data access and story patterns?’ If you follow a serverless-first approach, you’re on the road to sustainability.
Think in terms of limited resources.
Lousy design has an impact on users and their devices. They could be using unsustainable resources to charge their machines or phones. I always think about IDEs and the bigger IDEs in auto-completion and indexing because they get hot quickly! I’ve seen many IDEs moving onto the cloud: Cloud9 and VS code. And you’re thinking it should be in the cloud, too. Over the past year, energy prices are going through the roof in the UK. If we can do anything to reduce that, it also helps us.
Has it come full circle? Back then, CPU, memory, disk, and network were limited. You had to design and consider your poor resources. I’m going back that way again. We should consider limited resources so you’re not using what you don’t need.
A very thin client for all your needs. And everything is done in the cloud, server-side, from your IDE to everything else.
Data Patterns
So, the next section is Data Patterns. It’s a huge one. There’s an awful lot of waste with data flying around the internet. Again, we quote Adrian Cockcroft: ‘If you collect a piece of data and don’t put it directly into a model, you should just delete it.’ you don’t need it! It is a bit extreme, but it’s a great idea.
There’s a lot of good practice here. Data can be toxic from the perspectives of privacy breaches and security. You should have a good handle on these issues. Your data classification is critical. If you don’t extract value from it, eliminate it, or it will be unsustainable.
Everything’s becoming more data-centric, and the amount of compute that goes into chomping data is 90% of what IT does. How much electricity or energy is used in processing data? How do you minimise data movement across networks? That’s huge, right? Only move what you need when needed- not everything for the craic! When will they start charging for egress when you’re going to the cloud?
Hardware Patterns
The next one is Hardware Patterns, which is about sizing our stuff correctly. We’ve all been in teams where the question is: ‘What size box do you need?’ And the answer is: ‘The biggest one humanly possible!’ It’s a natural reaction, but you don’t need that.
It is where a serverless-first mindset and approach kick in. You don’t even have to concern yourself with many of these questions. It automatically scales up and down appropriately. We don’t have to worry about picking hardware or incident sizes ahead of time.
A good one is the Lambda Power Tuner. It will help you pick the optimum hardware size. And sometimes the biggest is not the most efficient. With Graviton chips coming in immediately, you are on a more sustainable compute platform without having to do too much.
Development and Deployment Process
The last section of the AWS Sustainability Pillar is the Development and Deployment Process. How do you increase the utilisation of build environments? Build everything all the time!
We often see environments and assets sprawl without tangible benefits. So again, it’s all about being smart about setting up your clients, your pipelines and your environments to ensure they’re delivering value. They’re not just there because that’s how we have always done it. People run huge test suites that go on for days. They publish results that only some people look at.
Avoid the sprawl
The question is: ‘How do you adopt methods that can rapidly reduce or introduce sustainability improvements?’ If you’re on a serverless spectrum, the cloud providers are working for you and introducing new capabilities. Graviton is a great example. It’s lower cost, more powerful, better performing, and more sustainable. If you’re on a serverless way of delivering your solution, you can take advantage of that instantaneously.
You must ensure your design and architecture can move with those innovations. That’s a large part of that spirit, like Graviton and different chipsets and shifting towards getting advantage of that.
So that’s the AWS Sustainability pillar.
That’s the craic. Next time, we’ll examine all six pillars to see which one we like best. Thanks for listening. There is more on TheServerlessEdge.com, our YouTube channel, Twitter @ServerlessEdge, and Podcast.