As always, let’s start with where we are and who we are listening today.

Environment Variables Podcast

They are the official podcast of Green Software Foundation1, which is a non-profit organization focused on reducing carbon emissions of web technologies. With their sentences:

We are a non-profit 501(c)(3) registered in the United States and are part of the Linux Foundation.

And I just remembered I took a course from Linux Foundation about green software. I didn’t share any of the notes from there! Shit.

Chris Adams

He is a climate focused technologist from Berlin as written in his LinkedIn page3. He also has different foundation from Holland. Let’s cite their words from podcast:

So my name is Chris Adams. I am the executive director of the Green Web Foundation, which is a Dutch nonprofit focused on reaching a fossil free internet by 2030. I'm also one of the policy chairs of the Green Software Foundation policy working groups. And I'm also one of the maintainers of a library called CO2.js, which as you imagine is the library to help you work out the carbon footprint of various digital services.

Kate Goldenring

Senior software engineer4 from the USA. She is the guest speaker for today.

Me

I am just a podcast addict :)

Podcast Notes

In this episode5, Kate mentioned Bytecode Alliance6 about building WebAssembly7 specifications. Let’s hear what she said:

And I'm still in the open source world contributing to our open source tooling there. And we actually work with the Bytecode Alliance, which is an alliance, as it sounds, of companies such as Microsoft, Amazon, Adobe, Fermyon were involved. And it's all about building out WebAssembly specifications so it can do more in more places.

She also attended a CNCF (Cloud Native Computing Foundation)8 YouTube channel to demonstrate more technically how we can achieve greener serverless via web assembly.

She also mentioned Marc Brooker blog post named “Surprising Scalability of Multitenancy9”

I want to call out that I similarly had an epiphany when I discovered this concept and I actually found it within Mark Brooker's blog. He's a distinguished engineer at AWS and one of the original authors of AWS Lambda. And in this blog, he talks about how the cost of a system does not always equal the value you get out of the system. And in a cloud context, the cost of running an application on a piece of hardware is the amount of compute resources you need available for it. And so as you mentioned at the start, oftentimes we provision for the peak. So the traffic to an application is rarely constant. And when you're choosing how many resources to provision, you have to make sure there's enough of those resources of CPU and memory to handle a burst of requests. And so this means that we pay for the short term peak traffic that an application may get. However, when we think about the value we get out of a system, that's the long term average traffic. And you can think about this and even see this in payment models for serverless platforms, where you may be paying for average requests per month. And so the problem with this, when you're paying for the peak but you're receiving the average is that we have this gap and that can cause low resource utilization. And so we ideally want to close this gap and a way to do that is with multitenancy

Sysdig did a report10 in 2023, and by referencing to that report we can say 69% of CPU is unused in containerized cloud, which suppose to be better than monolith architecture. We are still using 1 third of the total capacity. She suggests we can flip the numbers and use 70%.

A couple of extra notes of mine from that report:

• 87% of Container Images have high risk vulnerabilities
• 90% of granted permissions are not used
• For large deployments, optimizing an environment can save an average of $10 million on cloud consumption bills. On average, organizations of all sizes could be overspending by 40%.

Per request isolation in serverless computing ensures that each request to an application is independent of others, guaranteeing statelessness across requests. By creating a new instance or isolation for each request, any bugs triggered by one request will only affect that specific request, not others. Traditional challenges in achieving per request isolation, due to slow virtual environment startup times, have been overcome with web assembly technology, which enables the creation of new application instances for every single request instantly.

And Kate and her team come up with a solution11 for WebAssembly as it is still immature language. Let’s read what she said about it:

Yeah, and I think I've been painting this beautiful picture of WebAssembly, but it is still a fairly nascent technology. And so Fermyon is the company I work for, and we were really excited about simplifying the developer experience. So having someone come in and say, "Hey, I want to use this WebAssembly technology.


How can I use it?" And so if you're familiar with Docker, which kind of created that experience for containers. They created this Docker build, Docker run experience. We wanted to do that for WebAssembly with also the step of helping you even create that application. And so the open source tool for this that we've created is called spin and it is becoming the way to build serverless WebAssembly applications.


And so just with a simple spin new, you'll have templates that pop out for all these different languages. So we have 10 different languages that you can scaffold an application for. And there's SDKs for Rust, Go, Python, JavaScript.

Spin is not a locked in solution for cloud as it is more like Kubernetes that you can migrate to any cloud provider easily.

Based on carbon intensity formula from GSF12, she said oversubscribing to a server would reduce not only operational emissions, but also embodied emissions.

…and in measuring our software carbon intensity, the Green Software Foundation has that Software Carbon Intensity formula,


and that is a sum of operational emissions and embodied emissions, and it is very clear that you reduce operational emissions by not running your application. When you're not using it, so by leaving the gym,


but actually by oversubscribing, we're also reducing embodied emissions by having higher density and not needing as many servers. And so I think this whole concept can help us decrease our software carbon intensity.

And if you want to read an article about that, here is one13 for you.

Thanks for reading. I would say that podcast websites are well organized to quickly get insights. But listening the episode directly is always best option.