In this piece I’ll introduce you to a mental model you can use, if you are building digital products (like websites or apps), and you want to reduce the environmental impact created by the server infrastructure you’re using.
In the Green Web Foundation, we’ve spent some time thinking about the climate crisis and the role tech plays, and we’ve come to use a mental model to conceptualise where we are able to effect some change. We call it Platform, Packets, Process, and it more or less breaks down as follows:
- Platform – emissions caused by servers and infrastructure you run yourself
- Packets – emissions caused by infrastructure other people use (i.e the rest of the internet, that you don’t control)
- Process – emissions baked into decisions about the way you deliver a digital product to your users, or how people are set up to work in your organisation
In this post we’ll just cover Platform, but we’ll touch on others in future.
Platform – your providers and your provisioning
As we’ve mentioned before Platform here refers to your own infrastructure that you run or manage – so, servers basically.
When you’re talking about servers you have two levers available to you who you choose to get your servers from, your providers, and how much infrastructure you rent or purchase to manage the workload you expect – your provisioning.
Provisioning – matching capacity to demand
In most cases, while we talk about the internet being a global phenomenon, the reality is that we’ll see usage ebb and flow at different times of day, especially if you build something designed to be used at work.
The chart below is from The Power of Wireless Cloud report, and was used to show how the usage profile of the internet changes at different times of day. You can how usage of the internet drops off after midnight, then climbs again, we start using the internet at work, then basically go home to watch netflix, before starting over. If you use Google analytics or Matomo, you may see similar shaped charts in usage for your own sites and products:
Pay for the peaks, and accept the troughs
When it was relatively complicated to bring a new server online, there was an incentive to pay for equipment that could handle the peak usage, even if it would spend most of its time, idling, simply because setting up a big server for only the peaks of use was so complicated. In the words of Adrian Cockroft:
To optimize delivery the best practice was to amortize this high cost over a large amount of business logic in each release, and to release relatively infrequently, with a time to value measured in months for many organizations. Given long lead times for infrastructure changes, it was necessary to pre-provision extra capacity in advance and this lead to very low average utilization.
Evolution of business logic from monoliths through microservices, to functions – Adrian Cockroft
So, you might visualise us buying a single, huge server at like so:
While this meant we could always handle the top end, it also meant that when the machine was idling, we were essentially wasting CPU capacity, as we paid the same no matter what the server was doing.
Burning money, burning coal
You can imagine all the wasted capacity that you’re paying for as money you were burning, but in a very real sense, because the internet still largely runs on fossil fuels, this means you’re also paying to burn fossil fuels, and emit loads of CO2 into the sky here – bad news for the climate:
Using smaller servers, and scaling horizontally
In this scenario, if your site or service become really popular, if possible you’d typically scale vertically, by buying an even bigger server, rather than architecting you whole setup.
Another approach has become more popular since then – which would be to use a larger number of smaller, virtual machines working together, that you can spin up and down to match usage.
You might picture this as a bunch of smaller machines, rather than a single monstrous box:
Burning less money, but still burning money (and coal)
This is an improvement over what we had before, as we’re not wasting quite so much excess capacity, but as we scale the number of machines up and down, to match traffic, the scaling is somewhat coarse, and we still end up with unused capacity – which equates to paying to burn CPU cycles, and burn fossil fuels once again.
A newer approach – abstracting the servers away entirely
An increasingly common approach now is what’s referred to as “serverless” – where you’re not really managing servers or scaling them up or down yourself at all now.
Instead of paying for physical servers over months or years, or paying for-easy-to-scale virtual servers over periods of days or hours, you’re now paying for a computing capacity on a per request basis.
When no one is using your service, you effectively pay nothing, and there’s no server running – you don’t pay for any unused capacity, as your services scale down to zero – which also means no unnecessary burning of fossil fuels too – huzzah!
Your lovely golden cage
There’s always a catch here of course.
While paying for compute capacity involves less waste in terms of unused capacity, you have a comparatively small number of providers of this ‘serverless’ way of using computing power, and in many cases, you need to write code that fits the way the platform running your code was designed to get the most from it.
In many cases, more familiar databases or tools might not work the way you’re used to – so what you save in server bills, you might pay for in developer hours as staff try to bend unfamiliar new tools to their will.
This is why, we think it’s useful to think in terms of who your provider is, as well as how you provision computing resources to run a website or service.
Choosing your provider, and the economics of green power
Something special has happened over the last 5-10 years. The cost of renewables has come down so much, that it’s now cheaper to generate electricity with green power than fossil fuels. This changes our diagrams somewhat now, and this chart from Carbon tracker is illustrative.
What does this mean for us now?
The biggest difference is that before, when we were paying for capacity we weren’t using directly, before, we were burning fossil fuels, and emitting carbon dioxide to do so.
All the ideas about being able to save money from avoiding waste still apply.
Two of the biggest players, Microsoft and Google either run on green power, or account for all the carbon emitted by their servers now with offsets or renewables energy credits, as well as providing all these ways to run your infrastructure, and if you want to use a smaller provider you have many options.
Why this matters
We know how objectively bad the climate crisis is, and we know the human costs are getting worse by the day, often hitting the most vulnerable and least responsible the hardest.
So, when you’re not using green power, in addition to making tradeoffs about how much capacity you waste, you implicitly make a decision about how much avoidable harm to other people you’re okay with inflicting.
This is an uncomfortable thing to think about, but we’re grown ups now, and just as we expect other professionals to take measure to prevent avoidable harm in other industries, we can and should expect it ourselves – especially when switching is so easy now.
Summary
As we’ve covered before, there are tradeoffs you make when you go towards a more abstracted, serverless world, in terms of developer time to fit a specific platform, or greater risks of lock-in with a single company.
But if the idea of these new ways of building digital products sounds interesting, and you also care about living on a habitable planet, you can use both of these levers now – you can make choices about who your provider is to save on emissions by moving away from fossil fuels, but also on how you provision the resources you used for your websites, and services.
Helping you choose
We maintain the world’s biggest open database about how the internet is powered – which providers you might be from run on green power, and which ones still use fossil fuels.
We make this information available through our API, our checking tools, and open datasets, for free, and we’re looking for ways to make it available to more people, and groups to design workshops and training materials to help people take this into account when designing new services.
If you think you might be able to help, or you’d like to work with us, you can get in touch via email, mention us on social media by mentioning @greenwebfound, or even drop into our public chat room to say hi.
