The next sustainability slow movement — slow software?

Sustainability matters, and as part of that we have seen the rise of the “slow movement” — slow food designed to be good, clean and fair for all, slow fashion where all aspects of the supply chain are considered in order to respect people and the environment. The slow movement asks us to look at the bigger picture rather than just our need in that moment, and consider the long-term costs of our decisions on others.

It’s hard to argue that this isn’t something we should all be thinking about — we all live in this world, we’re all affected by it. But it’s harder to actually do it — life is busy, the fast options are convenient, and it can be hard to feel like your choices really make a difference.

In tech there are growing conversations about sustainability, but the same challenges exist. It seems complicated, and maybe you wonder if your choices matter — will it really make a difference which programming language I use? How do I really know the impact of choosing one instance type over another?

At the end of last year Amazon Web Services (AWS) expanded their Well Architected Framework (WAF) to include a new pillar — Sustainability. (Full disclosure, I do now work for AWS, but this blog represents only my personal opinions). Having used the WAF to guide my architectural discussions and decisions for the past few years, I was very interested to see what the newest pillar would contain, and what direction it could offer me.

Some of the key things were unsurprising:

• Turn off stuff you aren’t using (my mum definitely made sure this was drilled into me as a child)
• Speed up inefficient code (who doesn’t love that)
• Reduce the amount of data you store (decluttering and minimalism is cool these days)

But then I reached a sentence that caught me off guard —

“Redefine SLAs to meet business requirements, not exceed them.”

Not exceed them. What an odd thought. When you are given a target, surely it’s great to exceed it? When we need to trade off on SLA it tends to come down either technical feasibility/complexity or cost. What does sustainability have to do with it? Here is the full text of that section:

Align SLAs with sustainability goals
Define and update service level agreements (SLAs) such as availability or data retention periods to minimize the number of resources required to support your workload while continuing to meet business requirements.

All of it makes perfect sense. But I had never properly considered it, or had it as a factor in discussions when deciding how quickly we could recover in an outage, or how fast a page should load. Make your app as fast as it needs to be, but no faster. Don’t optimise for an uptime that is more than you need.

Studies show that the average person won’t wait more than 3 seconds for a web page to load. 10 years ago that would have been unthinkably fast. Instead we waited. If you are 30, you are older than the World Wide Web. If you are 20, you are older than Google, Wi-Fi and the iPod. If you are 15, you are older than the iPhone, the Kindle, Netflix streaming service and Alexa.

The belief that technology should serve us up everything instantly and be always available happened very fast. Most of us didn’t have a choice for most of our lives. We waited while the internet screeched into its connection. We waited for the website to slowly appear onscreen. Want to watch a movie? Remember to kick off the download before you go to bed. Maybe by the time you get back from work tomorrow it’ll be ready.

So let’s talk about “align SLAs with sustainability goals”. What would the impact be for your application to be down for an hour — it’s uncomfortable for sure, but is 100% uptime worth the extra things that will need to run to support that? When we are automating tasks we may be able to reproduce what would take a human an hour in a few seconds. But do we need to it right away? Could we be more efficient by batching those tasks? Could you wait 5 mins instead of 5 seconds? What about 20 mins? When I’m accessing something that would have previously required someone to go fetch a paper file, should I really expect it instantly? Just because it’s possible doesn’t mean it’s necessary.

Here are my main takeaways from this best practice:

• Sustainability often comes along with cost or performance benefits — but be careful that you aren’t only choosing sustainability when it does. Understand it as a separate and equally (if not more) important concern. Be willing to choose it even when you don’t get any “business value” back.
• Talk about sustainability when you plan out business SLAs — don’t chase faster or more available just because. Take only what you need.

I write this for myself more than anyone. I work in technology, I find it hard not to be impatient with software, not to want the latest hardware. I don’t think often enough about how sustainable the choices I make are in this space — as I write code, as I use technology — but I want to.

So, to take a small step, I’m going to start trying to ensure I document in my code and wider documentation where choices were made with sustainability in mind — and where I have to own a TODO in those areas. It will force me to treat it as a standard design decision, and it will allow me to share that with others.

Seeing Sustainability get equal footing alongside Security, Reliability, Operational Excellence, Cost Optimisation and Performance Efficiency is a clear step in the right direction for the industry. The Well Architected pillars represent what AWS believes both to be best practice for building in the cloud, but also key technical drivers for business success. I think it gives developers permission to have real conversations around it as they do their day jobs. I hope it starts conversations that lead to bigger things. I hope it moves sustainability from an “aspirational, we’ll get to that later” thing to a normal “part of our day job” thing.

If you want to have conversations about this, drop me a comment here, or connect with me on twitter @virtualgill.