Transcript
McNally: Welcome to the Zen of Green Software. This presentation is brought to you by Thoughtworks, and Lisa McNally, and Marco Valtas. Just in the last couple of months, we've seen catastrophic events across the globe, and here in the U.S., from devastating floods in Pakistan, to very unusual life-threatening heatwaves in the UK, to destructive wildfires in the Sierras. Of course, most recently, we've seen the widespread damage of an incredibly powerful hurricane in Florida that killed more than 100 people and caused billions of dollars in destruction. Catastrophic events are not a recent phenomena. Although erratic, these events are becoming a familiar trend.
From Debate to Recognition
Let's orient ourselves with how we've understood climate change these last 30 years and the consequences of business as usual. In the early '90s, there was a lot of debate and uncertainty about the perils of climate change. The debate was centered on whether our human activity had anything to do with global warming, or was it just normal weather fluctuations and nothing to be too concerned about. Over time, although skepticism was still holding strong, the climate change discussion started becoming less of a debate and more of a science backed recognition that our activities indeed were the main cause of warming in the second half of the 20th century. In fact, just last year, scientists received the Nobel Prize in Physics for work over these last 30 and 40 years, being able to show and pinpoint the effect of human behavior on a change in climate. Climate change is being driven by human activities, especially the burning of fossil fuels to meet our needs for energy. We've been wasting time these last 30 years debating whether it's real, and whether we have anything to do with it. Action is non-negotiable. We're responsible, and our actions and decisions matter. We don't have the luxury to choose which sectors we should primarily focus our carbon reducing behaviors on. Identifying efficiency as an imperative across all sectors matter, from transportation, to energy.
As a Technologist, What Can I Do About It?
You may be asking yourself as a technologist, what does this have to do with me, and what can I do about it? Marco will provide some very compelling cases for action, especially in the context of the push and pull of needing to address competing goals, like sustainability on one hand, and profitability on the other. I first want to underscore the connection between our daily reliance on tech and its associated impacts. Action is necessary, and informed strategic action of course is even better. Understating the connection between our behavior as technologists and the emissions that are generated from our work and our demand is critical. To that end, let me share some illuminating data points to help pull this all together.
Impact of Tech on Emissions
Let's look at the impact of our industry, technology on emissions. Technology, from software to hardware to data centers, and the architecture of our IT systems all rely on electricity to power and make them usable. Today, 80% of electricity generated globally is still from fossil fuels. I'm stating the obvious because I think it's always helpful to be explicit in this linkage between technology, energy, and carbon emissions as an impact of our demand as technologists. The contribution of the information and communication technology, or ICT's share of the world's carbon footprint grew from 1.5% in 2007, to 4% in 2019, which is on par globally with the aviation industry, and is expected to grow to 14% by 2040. Of this, data centers are expected to contribute to almost half of the ICT's carbon footprint. Even with considerable efficiency gains expected already being achieved, through the use of renewables to power the sector, there's still so much more to be done. Given our growing appetite for tech, the industry will need to reduce carbon emissions by 45% in the next 10 years to meet the goals of the Paris Climate Agreement. Thankfully, we're all part of the industry, and we're talking about those strategic approaches today.
What do we need to do? As technologists, understanding the great opportunity to mitigate climate change in the sphere of our own influence, we do a disservice by assuming that the only viable solution is powering data centers with renewables. Of course, using clean sources of energy to power data centers and our technology is critical, but it's not always possible. Therefore, we also need to also rethink how we use our computing resources, where we allocate them, and when and where we operate them. In this talk, we are illuminating actions, behaviors, and decisions that drive demand on those data centers, and much more, diving into ways to optimize our software to do more with less energy and improve carbon awareness of fuel types, for example, that power our technology infrastructure.
A Conceptual Framework
Decision making about how we use and allocate our resources could fall under either of two categories. This is a nice conceptual framework that we use to think about our solutions through tech. On one hand, we have greening by technology. On the other we have greening of technology. I'll define both, but our talk focuses more on approaches for the greening of technology. Greening by technology is defined by driving sustainability, by leveraging tech itself to achieve innovations, achieve changes in business models, and achieve our net zero goals. We're seeing a lot of momentum from startups that are bringing new climate tech solutions to a wide range of industries and use cases. This includes data storage and carbon tools, from carbon sequestration to scrubbing carbon from the atmosphere, and AI tools that can improve efficiency in a business's production. There's carbon capture technology, carbon sequestration, carbon management platforms, lots going on in this space. BlackRock CEO, Larry Fink, said that the next 1000 unicorns will be in climate tech. It's projected that $130 trillion will be committed to clean tech by global investors in 2023. Lots of opportunity, lots of innovation in this space.
This talk, though, is going to be focused more on the greening of technology. The definition that we use here is making the technology itself more energy efficient, or using the technology to be less carbon intensive. For example, using real time information from a dashboard, a cloud dashboard to make better decisions like moving workloads to greener regions, or greening our cloud operations. We recognize as technologists that there is a lot of opportunity to make the technology we use more energy efficient, from improving efficiency of the code itself to carbon awareness associated with running workloads in the cloud, to the hardware we procure, and when we operate it. This is where it starts to get really interesting, since it's not just about applying the tools that are doing the work. It's about embodying the way as technologists, the way of efficiencies for the long term to enable sustained reductions. It's not just about using the tool. It's about being one with the tool to optimize its performance. This presentation is focused on greening of tech, which is really an emerging field, versus the greening by technology, which has more to do with the innovation that we just discussed. There's a lot of other avenues and channels of information there out there. We thought it would be really great to really focus this one on greening of tech in order to learn some specific strategies there. As there's still a lot of competing tensions between making technology itself more efficient, we're looking at ways to balance this with the need for operating that technology to help, for example, an organization to reduce overall costs, remain profitable, while also meeting net zero goals.
Balance in Our Software Practice
Marco Valtas will now walk us through some of these tensions, to help us better understand these conflicts between different goals and provide specific strategies that we can employ to reach that important balance with emissions reductions. Despite the tensions of profitability, cost, and sustainability goals, we'll focus again on optimizing software development and operations.
Valtas: We're going to visit those three points of tensions again. The goal of this part is actually connecting as our practitioners, what we do on a daily basis that relates to carbon in our work. First, we're going to talk about the tension between cost and carbon, specifically about cloud costs. How I manage my costs. That's the theme of cutting carbon. What's the relation between those two. Then we're going to talk about carbon and profit, which is profit, in a sense, like a financially sustainable business. We're talking about the day-to-day decisions around investing in the project and the products that we produce, and how that relates to the carbon if you want to be carbon conscious about it. The last topic is the readiness and energy, which is revisiting our software practices. We have modern software practices that we use every day, in order to ensure that our code has high quality and is responsive to changes. When those were put together, energy wasn't in one of the topics that are being considered around those practices. We're going to revisit some and ask ourselves if they're energy efficient.
The Carbon Footprint of Personal Devices
I want to ask you, have you ever checked the carbon footprint of your laptop, or any gadget? I did mine. Here are results for just the Apple gadgets that I'm carrying around with me: my laptop, iPad, and iPhone. The insight that I got after looking at these numbers is that we have this faint relationship that we know that our devices, when they were created, they will produce carbon in their lifetime. We don't have a good sense of how much that is. When I saw those numbers, I got impressed. We were talking about 1000 pounds of carbon in the atmosphere through the lifetime of those, just three gadgets. Let's look a little bit closer on how this is broken down. That footprint is throughout the lifetime. It's from the production to the disposal. Zooming in in the iPad case, 82% is on the production of iPad, and then 13% here is on the use, is the energy that you use. As Lisa said, the way that we connect to carbon emissions is through the energy that we use in our ICT industry. This will be important for a later point in this talk.
Cost and Carbon
Let's talk about cost and carbon. Specifically, I'm going to talk about cloud costs and carbon. Because cloud cost and carbon is front news. The cloud providers are talking about it, and how can we think about it? Clouds work in the pay-as-you-go model. If you buy more resources, if you're using more CPUs, you're going to pay more. It's intuitive to think that if you're using more resources, you're definitely using more energy. If you're using more energy, you're emitting more carbon. It's ok to make a conclusion that, if I can see the cost of my cloud, if I optimize for its cost, if I reduce it, I will reduce the emissions. That works for a simple model of cloud. That works for a model where you're using the same resource, and you're not using your other options on cloud. If you look at how the regions are distributed, you can see that different regions will have different carbon intensities. Each region has a different price, according to cloud providers. Here, I have an example for AWS, but that will apply for any other cloud provider. You cannot see a straightforward correlation. If you zoom in, in some of those regions, contrasting U.S.-East with EU-North, you can see that you're cutting the emissions considerably moving from the U.S.-East and EU-North, but you're not cutting costs, you're actually investing in moving to another region. That's one of the things that breaks down that model of, if I cut cost, we'll automatically cut carbon. It doesn't hold for a complex model of cloud where it can move from regions, you can use other services.
If you think about cost in itself, we're not doing a very good job there too. This article published in 2021, says that it's estimated $26 billion were wasted in cloud resources. That means servers that are not being used, disconnected applications that are still running, but nobody is accessing them. Those are all using energy and by proxy emitting carbon. There's lots to do in the future of managing our cloud resources, not only from the point of view of cost but also carbon. The message that I hope that you take from this section, is that it's not enough just to measure your costs or just considering your costs when talking about the cloud footprint. Thoughtworks created this Cloud Carbon Footprint tool that helps you to see those numbers and see your emissions on the three major cloud providers. There are other tools around. The message here is that you should measure your carbon, not just rely on your cost when you're trying to balance those two. The idea of paying for resources needs to be balanced with the sources of energy that you're using, and how much you want to sometimes invest in reducing your carbon footprint, sometimes reducing the cost, because it's a budget constraint that you have.
Carbon and Profit
Let's go to the second topic, which is profitability, which is just the day-to-day decisions that a business makes to be sustainable financially. Let's start with visiting the Green Software principles. We're going to use the Green Software principles as a hook to our business decisions. I'm going to visit only one. You can go to principles.green, and see them all. They were published by the Green Software Foundation, and they help you with some statements and guidelines on how to make decisions around creating software, and manufacturing software, and use of technology that is more friendly. For embodied carbon, first we need a definition. Embodied carbon is the carbon emitted to create and dispose of a device. In the beginning, I said about the iPad, that 82% of the carbon is on its creation. That's the embodied carbon that we're talking about. The principle is talking about being hardware efficient. Being hardware efficient can be seen in several ways. We're going to see in one particular way.
A particular way you're going to see is, if you're a company and you create a mobile app, one of the key architectural decisions that a company makes when creating a mobile app is what devices you're going to support, and for how long. The way that companies see that is that the more you support devices, there's investment, because there's regression that you have to maintain. There's development. The code is more complex. Supporting less devices is better in terms of development. Supporting more devices is better in terms of targeting a broader audience. That decision that the business makes has an impact on the lifespan of that hardware. If your company makes a mobile app, that it doesn't support a certain version of hardware. If a user really needs to use your application for any reason, he might be forced to migrate from that particular hardware that they have to a new one, and dispose of that one, so creating a pressure to new devices being created.
One concrete example that we can talk about is in this year, WhatsApp announced that it will stop supporting some old iOS versions. That is about the iPhone 5c. You might ask, who's using iPhone 5c? This is so old, nobody is using anymore. If you are from a country like Brazil, we use WhatsApp for talking to our family. I talk with my mom through WhatsApp. There are several users of WhatsApp in Brazil. I can guarantee you, there are some iPhone 5cs in Brazil, that are still being used. In fact, 500 million units of iPhone 5c were sold. In poor countries where people do not replace hardware so fast, there's still old hardware being used. Here, we have a breakdown in recent years of all the versions of iOS. We can see iOS 10, which relates to the 5c support, is still out there. It's not in a big number, of course, but it is still out there. When that support ends, what does that mean for those users? It might mean that they have to right away dispose of that hardware. The lesson or the message here is that the decisions about this product, backward compatibility, sometimes have a carbon emission factor. What you need to do is be aware of that in order to be able to balance that decision. Is this just about the user reach, or can we extend the lifetime of this application? Can we make this application work not so on top shape, with some service degradation but still work on all the hardware. Those are things that you might have to consider.
Readiness and Energy
The last topic we're going to talk about is our software development practices. One that is very interesting to explore because there's so many things we can do about it. Here is a diagram of the flow of a code change in a modern environment. You write your code. You go through several hops of quality check, test check, lints, trigger builds. If the build passes, it goes over the pipeline and goes deploying to other environments. There are performance tests, security scans. There are several things that happen. All of those were created to provide, not only quality but a response to change, that's why we call readiness. That's why we are ready to change our software as quickly as possible, and guarantee its deployment to production will not break production. What I did here, I put some dots in some of those phases, where I think there's lots of space for us to explore.
When I was working on another project before joining the Cleantech team, our project would have deployments every 2 weeks, and we would build 20 to 28 full pipelines before actually doing in deployment. Some of those steps were deploying to pre-production environments for regression tests that were never used throughout those two weeks, just like a couple days before the release to production, then we went to those environments and actually test the whole application. Now you can ask, from the 28 deployments, why we had 24 deployments in that environment that were not even used. That's one opportunity to optimize the use of resources. Another example here is GitHub published two years ago, about their own pipeline. The reasoning is because they have so many tests, and the pipeline takes so long for long running tests, they created a way to optimize, not only their development velocity, but also the resource usage. They deferred the long running tests. Then they run that later, so the developers could move faster and have a later feedback, if the build broke, they will have to go back and fix the issue on time. They're not trading off quality for the resource usage, they are using some aspects and deferring to use better the resources.
Another technique that you can apply. That one was brought to me by this book, "Green in Software Engineering," when I was reading it. I think if you're from the QA community, you're probably familiar with this concept, which is test suite reduction. Which is, from the set of tests that you have running on the application, you might have some parts of the application that's being tested over again, with the same test data, which is redundant, you don't need that. Test suite reduction is the technique, or several techniques where you try to find those common areas and try to eliminate them. You have the minimum set of tests that guarantee the quality that you need to guarantee the coverage that you need to guarantee, and not more tests that will use CPU cycles and time to test over and over the same part of the application.
We have this Carbon Hack running that is sponsored by Green Software Foundation. The important thing is that there are several projects related to software development on this hackathon, several projects that were proposed. From load balancing with carbon awareness, like choosing the routes according to the footprint or the carbon intensity on the grid, to deployments that can be done with carbon awareness. There are several ideas, and if you have a conversation, you're going to see that there are several opportunities to implement and rethink our tooling in order to make it carbon friendly. The message on this section is to revisit our practices, like what is a common practice today that wasn't put together with that lens of how it's using energy. Now it's time to revisit those practices, and think if there is a way to make it more energy efficient.
Questions and Answers
Cockcroft: Do you have any recommendations for reducing carbon emissions for cloud based software other than build pipeline optimizations.
The Cloud Footprint tool will tell you where the carbon is, and then you go after that. Some people have a bigger QA system and development pipeline than they have in production. Other people, it's mostly production. I think it's all over the place. That's one thing. Then the other thing is just there are some location-based things. If you have any workloads in Asia, or any data archive stored in Asia or something like that, then if you move that to Europe, or the U.S. that will reduce your carbon footprint. Things like that. Trying to find a location or a region that's got less carbon in its energy usage.
Valtas: If you can actually do modifications on your application in a deeper level, you can consider moving to serverless, which is a shared instance, that you're going to take advantage of using one server instead of having a virtual machine dedicated. Chasing, also, idle resources are a good way to lower your emissions.
Cockcroft: If you've got any data in S3, or a similar cloud object storage, you can move it to an archive. AWS Glacier is basically no carbon, once you get the data on there. They don't say it, but you're looking at, what's the carbon footprint of a reel of tape stuck on a shelf somewhere? It doesn't consume carbon. Storage is interesting, because tape is pretty much zero once you've written to it. Spinning disks consume quite a lot of power, even if you're not putting anything on them. One of the optimizations that happened inside Amazon was that they found that there were dead disks amongst the fleet of systems and somebody figured, I'm going to spin down the motors. They just turned off the drive so they stopped spinning it because that was a bad disk, but they left the electronics on so they could see the disk. That saved a lot of power.
Then SSDs, similar to your iPad example, most of the carbon footprint of an SSD or a Solid-State Device like an iPad, is making it. The electricity it uses during its lifetime is much smaller than the electricity used to make the silicon that goes into it. SSDs are totally dominated by the fact that you bought one at all. It doesn't matter how much you use it, it's not going to use that much electricity, so it's all over the place. You can use lifecycle optimization policies and things to push things off of SSDs onto spinning disks or on to tape. Those sorts of things are useful, and just managed services in general. Lambda and serverless, is a good example, but managed services will generally have a higher utilization control plane, which is a lot of the overhead that you can't get down very easily yourself.
What's on the Cloud Carbon Footprint tool itself? Any updates on that? Anything recently that's been added to it? What's going on in terms of development and the various pull requests and things?
Valtas: Two things are happening. One is, recently, we did a release with Mongo as a backend for the carbon footprint. The reason we did that is that we start to face larger installations. The tool was created at first assuming that it could handle data in one go. Now we're using Mongo as a cache layer, basically. That actually opened another possibility, which is what we call server-side filtering. The API now is getting more options so you can slice and dice the data. Another thing that we're working on is to incorporate tagging into your data. Because now you can only see the data by the type of service or by the account or by provider, but most organizations will use tag as a way to separate by project, by department, and other organizations. We are implementing that, which will help if you want to check, what is the carbon footprint of my HR department? You're going to use that tag and you can get that information. Those are things that are coming in.
Cockcroft: Tagging support is really important, because, basically, you're doing a similar job to a lot of the cloud cost optimization tools. You have to end up doing the same slicing and dicing. I've been looking at some of those tools recently, and they're getting pretty sophisticated in their ability to break down what's going on and assign the dollars to a particular team. I think eventually, those products will start adding carbon more often, so that it's integrated with the cost allocation that has at least an outline carbon allocation.
McNally: We've been building out a methodology for on-prem baselining so that the tool can be used in tandem with that to understand what the baseline is now and get what some of the decisions could be, depending on which cloud provider you would want to migrate over to, to get a sense of cost and emissions there. It helps with that initial decision making, and that's something we should be wrapping up in the next month or so, to have a final methodology for that. It's not built out yet with the dashboard component, but we do have a methodology that can be used, and help guide the data that would be needed for making those decisions, which we understand can be one of the biggest hurdles in baselining on-prem.
Cockcroft: AWS now has a list of regions which are more than 95% renewable energy. It's basically all of the U.S., and Europe, and North America, so we've got Canada, all the U.S. regions, including Virginia, which historically has been a high carbon region. They've built so much solar, and wind around it, and batteries nowadays that they've got it down. These numbers were for 2021. If you're outside Europe and the U.S., then you're not on this list. It's on the Central Amazon Sustainability website, a specific long list of the regions. That's much better than what they had before, there was like 5 or 6 regions, quite a long time ago, that they said, these are the green regions. The obvious ones like Paris and Stockholm and London have all been added, along with Dublin, and Frankfurt that were on the list originally. It's an expanded list, and I think as we get to the end of 2022, we'll see what that list looks like for 2022. There will be some updates to it.
As with most of the providers, everybody is working on Asia. Everyone's got the same problem there. It's going to be a while before we get enough green energy in Singapore, or Malaysia, or Indonesia, or Japan, Korea, before we can get them up to 95% or so. Progress is being made, and there's a few more years before, at least the energy side gets that. We're still looking for Scope 3 manufacturing data. We've just pretty much got through all the announcements at AWS re:Invent 2022. I've been looking for it, I haven't seen any updates on the Cloud Carbon Footprint tool. The data coming out of AWS doesn't seem to have been updated. I was hoping that they'd be releasing something. They may have snuck it out without much funfair. I'm still rummaging through trying to figure out what happened with this massive event where there's just such a flood of information. I'm building a blog post on all of the sustainability talks. As I find the videos and watch them, I'm putting it on Mastodon, so if you find me at adrianco@mastodon.social. Gradually getting there. We're seeing that the other cloud providers at their major events, they led a lot more on sustainability. I think we're going to see more over time.
See more presentations with transcripts