GOTO - The Brightest Minds in Tech

Building Green Software Part 2: Measurement • Sara Bergman

Sara Bergman & GOTO Season 3 Episode 39

This interview was recorded for the GOTO Book Club.
gotopia.tech/bookclub

Read the full transcription of the interview here

Sara Bergman -  Co-Author of "Building Green Software", Senior Software Engineer at Microsoft & Individual Contributor at Green Software Foundation

RESOURCES
oreilly.com/library/view/building-green-software/9781098150617
greensoftware.foundation
ghgprotocol.org
sci-guide.greensoftware.foundation
iso.org/standard/66453.html
cloudcarbonfootprint.org

Sara
@SaraEbergman
github.com/SaraEmilyBergman
linkedin.com/in/sara-bergman1

DESCRIPTION
How will software development and operations have to change to meet the sustainability and green needs of the planet? And what does that imply for development organizations? In this eye-opening book, sustainable software advocates Anne Currie, Sarah Hsu, and Sara Bergman provide a unique overview of this topic—discussing everything from the likely evolution of national grids to the effect those changes will have on the day-to-day lives of developers.

Ideal for everyone from new developers to CTOs, Building Green Software tackles the challenges involved and shows you how to build, host, and operate code in a way that's not only better for the planet, but also cheaper and relatively low-risk for your business. Most hyperscale public cloud providers have already committed to net-zero IT operations by 2030. This book shows you how to get on board.

You'll explore:
• How the energy transition is likely to change hosting on prem and in the cloud—and how your company can prepare
• The fundamental architectural principles of sustainable software development and how to apply them
• How to determine which parts of your system need to change
• The concept of extending hardware longevity and the part that software plays

* Book description: © O'Reilly

RECOMMENDED BOOKS
Anne Currie, Sarah Hsu, & Sara Bergman • Building Green Software
Ioannis Kolaxis • 101 Green Software
Mehdi Khosrow-Pour • Green Computing Strategies for Competitive Advantage and Business Sustainability

Bluesky
Twitter
Instagram
LinkedIn
Facebook

CHANNEL MEMBERSHIP BONUS
Join this channel to get early access to videos & other perks:
https://www.youtube.com/channel/UCs_tLP3AiwYKwdUHpltJPuA/join

Looking for a unique learning experience?
Attend the next GOTO conference near you! Get your ticket: gotopia.tech

SUBSCRIBE TO OUR YOUTUBE CHANNEL - new videos posted daily!

Intro

Hi, my name is Sara Bergman. I am one of the authors of the new O'Reilly book "Building Green Software", which is currently in early release, and today I'll be talking a little bit about one of the chapters that we released in late June on the O'Reilly platform. And this chapter is all about measurements, because some of the very commonly asked questions when talking about green software, especially when you just start dipping your toes into it is, how can I measure it? How do I know my impact? Which part of my software has the biggest impact and, you know, where do I start reducing? So, in this chapter, we really dive deeper into these questions and offer you some opinions on how you can answer them. So, the first part is all about the perfect. What would a perfect carbon score be like for software, how close can you get to perfect data right now, and what would the perfect carbon score or perfect method be for the future?

So, we talk about energy data, carbon intensity data, and embodied data. So, for perfect energy data, you can actually instrument this yourself to a degree, especially if you own your own hardware, which is pretty cool. But doing real-time energy measurements in large-scale systems that span many obstruction layers can be a bit more complicated. It's entirely possible, but for many of us, it might actually be more worthwhile to leave the development costs of energy instrumentation up to someone else entirely.

How to achieve precision in carbon intensity and embodied data measurement

The next is perfect carbon intensity data. And carbon intensity is a metric of how clean or dirty the grid is that you're running your hardware on right now. And this would be a bit trickier to instrument ourselves as it requires some deep knowledge on how the local grid functions, but we are in luck because there are several open-source data providers that actually provides this data to you right now. Some have more static data sets, some have more of a live API situation, but that's pretty good because we can get today already very close to a perfect carbon intensity data score. And this is also the section where we talk a little bit about market-based reductions such as power purchase agreements and offsettings. Market-based reductions, they are an economic tool that is widely used not only by the software industry but by all industries to reduce their carbon totals or their carbon footprints.

And they are pretty cool, and they are definitely worth talking about, but for a perfect carbon score, we think that they should not be included simply because they muddy the picture a bit. It makes it harder to understand if your reduction was due to an actual change that you did, or if it was because you got a better market-based reduction approach. The third and final part of the perfect score is perfect embodied carbon data. So, how much carbon was emitted when the hardware that your software is running on was created? And here, we are once again left out to our providers to tell us, well, how much carbon did they spend making that server or phone, or whatever it is that your software is running on. Of course, we also have a vision for the future, and what the future of perfect monitoring would be, and we think that's real-time carbon monitoring that has sufficient granularity in time, location, and software components.

If we had that out of the box, it would allow more software teams to shift their focus from measuring to actually reducing, which is the end goal, of course. So, that was a bit about the perfect.

Current methodologies and practical software assessment

Now let's talk about the good enough because for several reasons, the perfect is not here yet for all of these data points, and the perfect might not even be possible for all types of software. So, in the good enough section, we talk about proxies that you can use for things like cost, performance, energy, or hardware because we should not let perfect stand in the way of carbon reductions.

The next section is about current methodologies because luckily, we are not the first ones to actually ponder these questions. There have come a lot of smart people before us who've done a lot of thinking into this which is great. So, in this section, we go over the current existing methodology, so namely the Greenhouse Gas Protocol, the Green Software Foundation's software, carbon intensity specification the SCI, and the ISO 14064 standard. The Greenhouse Gas Protocol is pretty well known. It's the one that divides your carbon footprint into scope one, two, and three. You've probably heard of it. They allow both market and location-based energy data, and it's a widely used standard across enterprises, not only in our sector but in all sectors. So, it's really good for a lot of things, but it wasn't really built for software, which makes it not ideal for software.

I'm gonna explain a bit more about what we mean when we say that in this chapter. On the other hand, the Green Software Foundation's SCI score was built for software, and it's not a total, but it's a rate of carbon emissions per what we call functional unit, where a functional unit describes how your software scales. So, that can be per user, per device, API call, anything that sort of makes sense to you, and the SCI score, they take energy location-based, so not market-based, only location-based carbon intensity, and embodied carbon into account.

Exploring the path to future sustainability and bridging metrics to action

Lastly, we have the ISO 14064-1 standard, and that's actually built on the Greenhouse Gas Protocol standard, but the division of emissions is a little different whereas the Greenhouse Gas Protocol uses the scope one, two, and three, the ISO standard has direct and indirect emissions instead. What is cool about ISO standards though is that you can get certified by a third-party certification body, which can be great for auditability if that's something that's important to your organization.

And like I said, we are not the first people to think about this, and we're not the first people to build something on this either. So, we have a chapter or not a chapter, but a section in this chapter about tooling. So, all three major public cloud providers, AWS, Azure, and Google, have their own carbon emission tooling, so we have an overview over what those tools provide to you, as well as the open-sourced cloud carbon footprint tool, which is sponsored by Thoughtworks. Of course, not everyone runs software in the cloud, so we also have a short overview of the client-side tooling. The takeaways from this chapter is that, well, it's quite heavy on information about the current state of the industry when it comes to both tooling and standards. And the great thing here is that our industry is in such a better place than it was just a few years ago.

A lot of these standards and toolings, did not exist just a few years ago. So, we're very excited to see where our industry will continue to move, and hopefully, we'll get closer and closer to that perfect real-time carbon monitoring. We also hope that you, our readers, by the end of this chapter have a better understanding of what you can do to measure your emissions, and where you can get help to do the same because you're not alone in this.

Outro

And whatever solution you end up using, we hope that you really approach your software measurements with curiosity, and let them be a conversation starter for your team, or for your organization. But they shouldn't be the end goal. You should let your measurements be the companion to carbon reductions, which is actually the end goal. So, thanks for listening, and I really hope you like this chapter.