Building Green Software Part 3: Code Efficiency • Anne Currie

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

Read the full transcription of the interview here

Anne Currie - Co-Author of "Building Green Software", Leadership Team at Green Software Foundation & Veteran Software Engineer

RESOURCES
oreilly.com/library/view/building-green-software/9781098150617
greensoftware.foundation

Anne
annecurrie.com
@anne_e_currie

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

RECOMMEDED 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
Lässig, Kersting & Morik • Computational Sustainability
Zbigniew H. Gontar • Smart Grid Analytics for Sustainability and Urbanization
Katsoni & Segarra-Oña • Smart Tourism as a Driver for Culture and Sustainability

Twitter
Instagram
LinkedIn
Facebook

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!

Transcript

Intro

Hello, my name is Anne Currie, and I will be giving you your quick 10-minute introduction to my new book today. This is the third podcast in the series on the book "Building Green Software," which is just being published as we, or pre-published, early release published on the O'Reilly website. So, my name is Anne Currie. I have been in the tech industry for nearly 30 years now, which is quite germane to the topic we'll be talking about today. And I'm part of the leadership team of the Green Software Foundation, which is a Linux foundation for being greener in tech and managing the energy transition. But here today, I'm here to talk about the book that I have currently in the process of writing, along with my two co-authors, Sara Bergman of Microsoft, who you will have heard in the last podcast, and Sarah Hsu at Goldman Sachs, who you will hopefully hear in one of our future podcasts.

The Importance of Code Efficiency in Green Software

But today I'm here to talk about the latest section that we've released, which is Chapter 2 of the book, Code Efficiency. Now, the question that we need to be asking ourselves today and in the talk today is, is code efficiency the key to being green and having efficient and energy transition-aware software? And the trouble is, it's quite a controversial question and a very controversial answer. I'll put it to you. Everybody's been really looking forward to the coefficiency chapter, and I know why because we kind of think code efficiency is absolutely fundamental to cutting down the amount of energy and electricity used by software as it runs.

The Evolution of Software Development Over the Past 30 Years

I got into the green software about seven years ago now, seven or eight years ago now, and it was entirely based on code efficiency. So, my background, and obviously I've been in the second degree for a long time now, since the early '90s. Back then, code had to be really efficient because machines were about a thousand times less effective than they are today, about a thousand times less good in terms of CPU storage, speed of bandwidth, bandwidth availability, and cost. But 30 years of exponential growth really pays off. Thirty years of Moore's law improvements in hardware and computing hardware have meant that we are about a thousand times better now than we were then. And remember these are all changes that happened within one career.

It's not the end of my career. I do not intend on retiring tomorrow. During my career without completely spanning my career, we've seen a thousand-fold increase in the ultimate thing we all run on, which is hardware. So, my interest in green software came from the fact that 30 years ago, we had to be a lot more efficient in the way that we coded because we had so much lower amounts of resources, worse resources to run on. We used to do a lot of things I was extremely familiar with because I used to do them myself to get that increased efficiency. We used to use very low-level languages. So, I was a C Developer, a C Service line developer in those days. So, you're looking at languages that are compiled that run directly on without any kind of intermediation on the hardware.

And what that means is that you've got a lot fewer CPU steps per operation that's made. And yeah, you can run stuff today on a machine nowadays, it is unbelievable. We had nothing like this. And also their bandwidth as well, we had nothing like bandwidth that's available now. And my original thought on being green was, okay, we can do all of those things again. We can go back to using, let's say, modern equivalents of highly productive languages, which Rust is more popular these days, and rightly so. It's a lot safer than C or C++. But it is an equivalent language that's not compiled and that is running directly on the hardware. And it's extremely efficient as well as being a lot safer than C was.

But fundamentally, it's the same concept. You've got a fast, very lightweight language running and you use it to write clever code that kind of accommodates its own multi-threading. One of the things that's very important is effective multi-tenancy if you want to write very efficient code. And back in those days, we used to do it by writing. Actually, even back then, we didn't really write monolith. We wrote something that would be analogous these days to microservices, not as tiny as modern microservices are, but could look like meatier microservices. So, you had a distributed system, but it wasn't quite as small as microservices, but it wasn't as monolithic as a monolith.

And the reason why is, is because you wanted to try to emulate multi-tenancy. So, something that happens these days in data centers, if you're in the cloud, something like that, you will be using VMs or even containers to get multi-tenancy. So, you've got multiple different clients running multiple different systems on top of the same hardware. And the reason why that is good is that you'll have some things that are currently quiet and other things that are busy, by sharing the same hardware and being careful about how you balance up. So what's running on that hardware? You can aim to get really, really good machine utilization. And back in those days, machine utilization was absolutely key. We had such rubbish machines, that we needed to make sure that they weren't ever sitting around waiting on operating system calls, for example.

We had kind of famed multi-tenancy that came with multithread, and it was great. It worked really, really well. I mean, it really was a thousand times better than what we get these days. And my original thought was, if we had a thousand times more efficiency in data centers these days, then the software industry would be a leader in the energy transition. We wouldn't be moving the dial when it came to using electricity. These days we're about the same as most other industries. In data centers, we use about 2% to 3% of the electricity used on the planet across all sectors. But if you factor in hardware and end-user devices, we're more like 12% or 10% to 12% according to Greenpeace.

But if we just look at data centers, then if we could drop that a thousandfold, then we're out. We don't need to worry about it anymore. We are completely done. So, my original thoughts, the reason why I got into green was from my background in code efficiency. But we are not in the world that we were in 30 years ago. We are in a very, very different world. And I went in, you know, all guns blazing on green software, although we didn't call it green software. I didn't call it green software back then. I called it sustainable software or coding for the energy transition, which is not something I'm allowed to call the book because, frankly, it's not very catchy. But it's all the same idea. How do we code in a green sustainable way that's energy transition aware? I was thinking, great, what we'll do is we'll write everything in C.

Then I started to do some work with customers, some work with businesses, and some work with engineers about what people actually wanted to do and what was likely to land as a message. The trouble is that rewriting everything in C or rewriting everything in a multi-threaded kind of cut somewhere between a microservice and a monolithic way, it's really hard. It's really, really hard. Back in the '90s, it took us ages to do anything, and it was very hard to change software. It's really hard to evolve software. And so, most of the thousand-fold increase in machine productivity between then and now went not into making everything run faster on smaller and smaller machines. You know full well that's not what we did with it. What we did with it instead is we improved developer productivity. So, we put in loads of layers, isolation layers that made it easier as a developer, but not just made our lives easier.

It made it faster, it made it safer, it made it more secure if you are using it all correctly. And that wasn't crazy, you know, because actually, the world has become different in the past 30 years. Expectations are very high that we move faster, we do iterate, and we do get product features out in minutes, not years, as it used to be in the early '90s. And nobody wants to go back to that world. So, if you start selling code efficiency to your business, or more generally, you're gonna run into that straightaway, but nobody quite rightly wants to go back to that world. A lot of those things didn't really scale in the way that we need these days. It couldn't be made secure in the way that we need these days, and it couldn't react and get better and evolve in those days in the way that it can now.

Balancing Code Efficiency with Developer Productivity

So, we need code efficiency, but we also need to keep all of those improvements that we got in the past 30 years. If we don't get both, we are never gonna sell code efficiency. You are never gonna sell code efficiency to your business if it's like, oh, yeah, but we'll massively slow down our development cycles because you'd go out of business. So, we've gotta find a way of squaring that and getting both of them at once. And I'm very sad because I really went into this in the hope that I could just tell everybody to rewrite everything in C, and we'd be done. And a lot of people wanna hear that. There are loads of us out there who would really love to rewrite all our code in C, but for the more sane amongst us because we don't wanna go back to that world. Much as I enjoyed in the time, I was much younger. That's not the world that we can go back to. We need to be secure, we need to be fast. So, we need to find a way of both getting, but code deficiency is still really important. So how do we do both? How do we get that thousand-fold increase in productivity, in machine productivity without taking a thousand-ful decrease in developer productivity?

Aligning Code Efficiency with Modern Software Development

We have to align those two. And the more I've been looking into it, the more that my co-authors and I have been looking into it, and the more we've been thinking, we need to align it with open-source, the cloud, and modern services. It really, when it comes to code efficiency, we need to make this a buy or a select choice rather than a build choice. If we can buy or select push our suppliers to create efficient software, we could just buy it and they can keep improving it under their feet. Because although it's massively bad for developer productivity, that doesn't matter so much. If you are selling code that's going to thousands and thousands of users, it's worth putting in that investment to get efficient code.

So, as a customer, which we all more or less are, I think that most of the folk who are listening in on this podcast today will be consumers more than producers. With producers, I'm talking about people who have thousands or hopefully millions of users, but multimillion end users fundamentally of the underlying software that we need to make efficient. And if that is the case, then it's really well worth your while putting in the time and energy to make that code efficient. And it does require enormous amounts of time and energy. And as a consumer, which we are here at this point, if we can be putting pressure on our suppliers to put that work in, then we get so much more bang for our buck. So, for example, it is an example, most of us, it's not worth rewriting your code in Rust or Go because even doing that is a hell of a lot of work.

These days, often quite unnecessary. The Python compiler, now there are now compilers for Python available that will compile your Python down to C or even machine code. So, there are people at the platform level who are working on making it so you don't have to rewrite your code in C or Rust in order to make it efficient. You can keep using these high-level, relatively easy-to-use languages where you get great developer productivity, but still get the code efficiency improvements. But you need to pick those platforms that are moving in that direction and where you can just rely on and lean on the platform to develop the code efficiency for you. So, for example, say you are somebody who does choose to write Go code, which is really quite an efficient language.

It's not quite as good as C or Rust. But it's really quite an efficient language. Even if you choose that, you're better off putting pressure on the engineers behind Go, the community behind Go, to make sure that it is efficient. So, for example, you can write as efficient Go as you like, but if the standard libraries in Go are inefficient, then you've wasted your time. You are much better off putting pressure on the Go developer, and on the Go community to make sure that the standard libraries are efficient so that what you write on top inherits that efficiency. That is a much, much more...that's an effect, that's an action that moves the dial when it comes to being green. Just writing your code in Go without putting pressure on the platform, the environment that you're working in to be green under your feet, and to continue to make it green under your feet is a much less effective action.

It's the whole thing about, you know if you want to go vegan, that's totally fine, but it's not going to change the world unless you are some kind of massive influencer who's going to make a million people go vegan because they're great, you know, fill your beets, go green, go vegan. There's no problem with that. But if you just do it on your own, it makes you feel better. That doesn't change the world. It isn't going to get us where we need to be. What we need to be looking at is actions that are gonna affect thousands of people. And in the software industry, the actions that are gonna affect thousands of people are where we persuade our suppliers to be greener. Not where generally, where we are greener ourselves unless we are a supplier, in which case, yeah, definitely go green.

But if you are not a large set-scale supplier of software industry code, where you need to be putting your pressure on is on your suppliers. And it's easy. It's easy. So much easier than rewriting your code in C, I can assure you, is that get on the phone to your AWS supplier or whoever you are getting your platforms from and say, "I really care about this. What are you doing? How are you doing? This is how I'm gonna be making my platform decisions in the future. I wanna see action, I wanna see commitment." 

Putting Pressure on Suppliers for Code Efficiency

That's how you move things. That's how you change things. I really wish it wasn't the case. I really wish I could be saying, "Gotta rewrite all your code," because I love that kind of thing.

And that is, you know, it gives me a flashback to my youth. But unfortunately, that is not really the way that we are going to change things. We really, really need to be putting pressure on as consumers, as users of software, rather than rebuilding all our code. I really enjoyed the chapter. I really enjoyed writing this chapter of "Building Green Software." Although for me, it was heartbreaking, I enjoyed writing it. It forced me to rethink all my inbuilt desire to go back to those days of multithreading but really, really, really difficult to write languages that were close to the operating system. We're not used to debug assembler back in those days. Just don't do it. It takes ages.

It takes ages, and you will get fired. So, we need to find you a way of working that is less...that is both more effective, good for your business, and less likely to get you fired, which is don't rewrite all your code in C. Slows everything, even Rust slows everything down massively. Unless you are actually writing open-source software that you expect to be used on a massive scale. Even if you do, interestingly, two of the examples that came out when I was researching this chapter were from somebody who had tons of money, was expecting massive scale, and still didn't do the optimization until really late on in the day. And I think this really tells you quite a lot. So, one example is, you'll have heard, earlier this year, there was a lot of fuss over it coming out that Amazon Prime Video used to run on serverless but has been now moved to something which is quite like the description that I was just giving about you.

It's not full microservices, it's not a monolith, it's somewhere a little bit in between. It's like we used to do when you were writing your own code that was kind of essentially provided your own multi-tenancy by using multi-threading and a moderate degree of microservice and distributed systems. And they'd done that and they said, "Well, this is great. Now that we know that Amazon Prime Video is massively successful and needs incredible scale, we are willing to put this investment in to do this." And everybody went, "Oh, serverless is terrible because it's..." You know, they've had to move away from serverless to get massive multi-tenancy and massive scale. And yeah, you will probably, but still they had huge amounts of money to throw at it, and they still didn't start on that. They started using Service, which is a pretty decent way of getting multi-tenancy without having to put enormous amounts of personal engineering efforts into do it.

Amazon, with something that they were absolutely betting on and had been betting on for years, didn't start by being super efficient. They started by concentrating on developer productivity, which is serverless, and then saying, "Well, that was good enough to get to what to this stage, and then we'll do the actual investment, which was similar to what we used to do in the '90s to get to the next stage," but not until this year, which is amazing, isn't it? The other example is Teams, Microsoft Teams during the pandemic, they needed more machines, but they couldn't get their hands on more machines. So, they decided, "Oh, well, how can we free up some of the wasted resources in our existing system?" So, they started to do quite a lot of the stuff that we used to do during the '90s.

So rather than having, for example, storing all their data in text, text, would've never have used text in the '90s. In their databases, they moved over to binary and coding. And that was what we used to do. Everything was binary. It was awful. It was impossible to debug everything. We all got quite used to being able to just read binary-coded messages. But anyway, thank goodness those days are gone. But anyways, Microsoft, now those days are back, they have gone back to using binary and coding to store data so that they need much, much less hardware to store the data that they're saving. And they had to, they were forced to do it because Teams was going bananas and they just didn't have the hardware to do it.

It was like being back in the '90s and apparently, it was terrible. It was really unpleasant experience, but they did achieve it. It can be done. But even Microsoft and Amazon, on products that they've been betting on for years and had enormous scale, they didn't do this investment that took quite late on. And I think that's, it breaks my heart, but fundamentally it is the lesson we need to be taking away from this. How do we do green? How do we do code efficiency without having to do those things ourselves? And the answer is we need to buy it. We need to put the pressure on our suppliers to give it to us. Whether those suppliers are Amazon, it's very easy to put pressure on Amazon. Just talk to your Amazon rep.

Same with Azure, actually. Talk to your Azure rep. Open-source communities, start raising issues. Start saying, "Well, how do I measure this? Is this good enough? Are these libraries good enough? Are these standard libraries good enough?" That's the first thing to be tested and really is a good measurement. Our last chapter was on measurements, but one of the easiest ways to just do some quick measurements on whether a standard library is good enough is just straight-up performance. Is it fast enough? Is it fast or is it slow? If it's slow, raise a bug about it because we absolutely need these things to be, these underlying technologies, these platforms to be code efficient. And that is where unfortunately we need to be putting our attention and applying our pressure.

Now, if you want actual things that you can do, the building part of buy and build, that will be not in the next chapter that's coming out, but in the chapter after that, operational efficiency because when it comes to operational efficiency, there's tons of stuff that you need to do yourself to improve efficiency. But code efficiency, really, unless you are a platform, you need to be putting pressure on platforms.

Outro

So, I know I feel sad, I would really have liked it if I'd just been able to tell you about how to, you know, tune your for-loops better. But really the answer is don't tune your for-loops better. Just put pressure on your suppliers to improve your compilers so that your code will be automatically tuned under your feet. And then just you write your code in a way that is compliant. Is it how your platform expects? And what your compiler will be optimizing optimally, if you know what I mean. So, good to talk to you and I'm sure that I will be back and speaking to you again about the operational efficiency in a couple of months' time.