‍At Lune we are on a mission to make every product and service climate positive by default and we are starting by offering the API for carbon offsetting and removal.

We are well aware that carbon offsetting does not always have the best reputation; some companies may decide to use carbon offsetting to carry on emitting and wash away their guilt.

At Lune, we strongly emphasise that offsetting is necessary but it is only part of the solution. To achieve the targets of limiting temperature rise to 1.5˚C outlined in the Paris Agreement, companies must reduce their emissions and offset what they are not able to cut.

To that end, in our small way, we also try to find opportunities to reduce our own emissions. Here’s how we’re doing it.

What can we reduce?

Being a technology company, we first needed to address cutting cloud emissions.

Picking Intel servers has become second nature … it’s not something that you think about. Let’s face it, Intel has produced great CPUs for so many years, but we’ve come to the point where the market is offering a wider variety to choose from.
Lune is hosted on AWS and for our API we use EC2 t3 instances with Intel CPUs.

Could we transition to the more power efficient ARM-based t4g instances (aka Graviton 2)?

Some of our customers require predictable performance - could we keep our existing order rate?

Note: our default rate limit is considerably lower than our real throughput.
Let’s get testing ..

Establishing Benchmarks

We have been benchmarking our API using https://github.com/wg/wrk.

Our benchmark consists of running wrk with different number of open connections, each for the duration of 30 seconds.

Here’s the median and 99th latency percentile as a function of concurrent connections.

We’ve benchmarked t3.x v t4g.x instances of equal size.

ARM latencies are slightly better, but not greatly.

Infact, I would say, looking at both benchmarks, the two instance types are evenly matched.

One interesting fact to note is that ARM beats Intel when it comes to the number of requests that timeout, although both observations are well outside our operational range based on concurrent connections.

Emissions

At Lune, we are currently able to estimate emissions for the following categories: shipping, flights, electricity and any purchase of a product or service.

Compute emissions are still a work in progress, however, from our initial research, we estimate that our Intel instances emit approximately 7kg CO2 per month each compared to our ARM instances which emit 4.5kg CO2 per month each.

We will, of course, offset those with Lune.

Here’s a chart showing monthly emissions of t3 v t4g instances as a function of their size.

Drop us a line if you are interested in this functionality, and once it’s ready, we will be in touch!

Conclusions

Given that the ARM instances emit 35% less CO2 per month and that our API benchmarks show no performance regressions, we’ll be transitioning all instances to ARM.
As an additional bonus, the ARM instances are also 40% cheaper than the equivalent Intel ones!

This is just one of our contributions to fighting climate change. 

Stay tuned to learn about what we are up to next.

Like what we are working on? We are hiring!

Credits: big thank you to https://www.cloudcarbonfootprint.org/ and https://medium.com/teads-engineering/building-an-aws-ec2-carbon-emissions-dataset-3f0fd76c98ac whose data has helped me write this post.