Episode 56 - Building Green Software, the one year anniversary with Sarah Hsu

Sarah (00:01)

I'm a strong believer that we, Software Practitioner, should follow suit with what SRE are already doing. We have to treat the environmental metric like any other monitoring metric and use it to drive critical business decisions.

Gaël Duez (00:15)

Hello everyone, welcome to Green IO I'm Gaël Duez and in this podcast we empower responsible technologists to build a greener digital world, one bite at a time. Twice a month, on a Tuesday, our guests from across the globe share insights, tools and alternative approaches enabling people within the tech sector and beyond to boost digital sustainability. And because accessible and transparent information is in the DNA of Green IO. All the references mentioned in this episode, as well as the full transcript, are in the show notes. You can find these notes on your favourite podcast platform and, of course, on our website greenio.tech.

A year ago, Building Green Software was released by O'Reilly. Since Tim Frick's book, Designing for Sustainability, eight years ago, O'Reilly didn't publish anything fully focusing on sustainability. So it's a fair statement that this book was long awaited.

And watching the line during the book signing at Green IO London last year, I guess its launch was a success. But a year is an eternity in IT. This is why I'm delighted to have the last of the Building Green Software's co-authores, who didn't join the show yet, to be with me today, Sarah Hsu, to talk about the trends she witnesses firsthand in the green software engineering field. Based in London, Sarah is a pillar of the Green Software Foundation where she chairs the Principles of Green Software Engineering institution as Site Reliability Engineer. And on top of being an author, she's also a regular speaker at Kubernetes Community Day, LeanAgile and GreenIO conferences. Welcome to GreenIO, Sarah. And first of all, congrats for your Tech Woman 100 Award last year. How does it feel?

Sarah (02:21)

Hi, Gaël I'm so excited to be here. I love, welcome to Green IO spill. You say that all the time. I feel like sometimes I can hear it in my sleep, you know.

Gaël Duez (02:34)

Excellent.

Sarah (02:35)

But anyway, yeah, thank you for asking about the award. Winning it, it did feel great. And while it's fantastic to have my own hard work recognized, and it really is a celebration for everyone who has been part of my journey. It honors the dedication of my incredible teams, my work team, my GSF team, and of course, my book team and it's celebration of the success of all our project. And I guess personally, I think the most important thing that came out of this is that it's a massive, massive kudos to every single person who has invested their time and effort to support me along the way. And that includes you, Gaël things like we met two three years ago at the very, very inception of like green software and green IO.

Gaël Duez (03:30)

I wasn't expecting to be included in this amazing crowd that you gathered around you I'm a bit surprised, but happily surprised. Thanks a lot. And I have to say that it's great because this recognition, it really highlights that sustainability is a teamwork, but it also shed a very positive light on sustainably being a hot topic in the IT industry and I think we need all these positive signs, especially at the moment. So, congratulations again.

Sarah (04:06)

Thank you.

Gaël Duez (04:07)

And without further notice, the I don't know how million dollar question, but actually it could be a Gartner title for one of their study. According to you, what are the main trends that you see in green software since a year ago, since the release of your book?

Sarah (04:29)

Well, how much time do we have? I'm joking.

Gaël Duez (04:32)

Between two to three hours. No joking.

Sarah (04:35)

Hopefully we're not here that long. Well, the space, the green software space has exploded in the past couple of years. Like look at Green IO and the popularity and the engagement has just been amazing. So I guess the first and foremost trend I think is the people, right? The incredible people that we have all met in the past couple of years have been absolutely wonderful.

There really is a real sense of camaraderie. People are here all to learn from each other, to help each other. We are comparing nodes and most importantly, we're celebrating every single little wing within the space. And even though the space really, really has exploded in the past year, we're still in a critical stage of raising awareness among the wider software community. And personally for me, my keynote at Ling Agile, Eddinger Conference last year is one of those moments I probably would never forget. The energy of the crowd that day, it was just incredible. And how appreciative people were of my talk and my time. It really made all those late night and weekend sacrifice worthwhile. So yeah, I think that's the first trend. And it's not strictly technical, but still so important to highlight and hopefully serve as an encouragement to all our listeners out there. We should keep it going. We've got to continue this broken radio energy in every single direction we can to make green software. Not the afterthought, but the first thing everyone discuss in any technical meetings.

Gaël Duez (06:20)

And I do agree that I can feel this energy and growing concern and the growing commitment of many responsible technologists, would say, whether they work in design, ops, cloud, you know, obviously software development, et cetera, et cetera. Do you have any other trends on top of this people trend, I would say, then don't worry, I've got plenty of much more technical questions.

Sarah (06:47)

Okay. Yeah. So the second trend, I guess I want to mention is the realization that green software really is not an ivory tower. We're not asking the overstretched engineering team to work on something completely new. The way we see green software is that it integrates seamlessly with software engineering practices. And it really isn't here to disrupt your established workflows. And I guess that nicely leads me to my next trend, GreenOps. I know I feel like we need to make a catchy tune for GreenOps. So yeah, Gaël, maybe that's something you can help us out since green IO opening is so catchy. But GreenOps is getting very catchy and it is the most trendy kid on the block right now. And just so everyone is clear, when we talk about GreenOps, we mean green DevOps, not the fossils. But yeah, guess green DevOps is here to rule us all. So I would say that is the third trend that I've seen for the past year.

Gaël Duez (07:58)

So I would say to wrap it up, first trend, people, large awareness raising movement amongst people working in our Second trend will be, we're not in an ivory tower and we need to connect to every other specialties building amazing software to make it work. third is definitely green DevOps, be more precise. On this one, actually I have a question. Is it a leader or is it a follower of the FinOps movement? And by that I mean that we talked a lot about the mutual reinforcement of GreenOps and FinOps especially for all the tech stack based on cloud and especially public cloud services.

Do you see this reinforcement happening and do you believe that the rise in GreenDevOps has been mostly fueled by the rise in FinOps or are they two separate movements enjoying mutual co-benefits?

Sarah (08:56)

Again, I'm saying in on behalf of myself, I personally think GreenOps extends really naturally from DevOps and FinOps. And I think GreenOps is, can stand on its own weight, but FinOps is just a lot more mature in the space and it's already had amazing framework and not a lot of thought process going out against it. So yeah, I personally think FinOps and GreenOps. They are basically just two sides of the same point and they have the same goal, right? Which is optimization. and I believe that we, we're soft engineers, right? We are inherently lazy people. So why would we want to reinvent the wheels? Why will we not incorporate try and tested practices that the FinOps people has already done for us to achieve this optimization utopia? If you know what I mean. So yeah, I know there are some really strong arguments against using cost as proxy for estimating software's carbon emission. And I tend to agree. However, we really should not overlook the important lessons that FinOps is trying to teach us. Firstly, it's all about accountability, Sustainability is no longer just an ethical headache.

It's every single person's responsibility, from the finance people to legal to operations to HR and of course to us engineers. We all really need to play our part the second point in my opinion is all about transparency. We need that transparency to empower everyone. If the legal guy who sits two rows behind us can't feel that sense of accomplishment, why would there be an incentive to take part, right? And lastly, I think the most important point that FinOps already outlined for us is the knockoff benefits or as we would like to call it in the book, co-benefits.

One of the messages we really, really want to get out there with the book is the core benefits of green software. So yeah, similar to FinOps, achieving cost optimization has loads and loads of knock-on benefits.

Gaël Duez (11:10)

That's very clear. mean, there are technical debates. You mentioned one that cost is not the best proxy for carbon emission, water consumption, etc. I would say that at the beginning of the journey, usually their best friends at some point, they might diverge a bit. That being said, You said you see a very strong trend in the GreenOps movements. Is it more on awareness or do you already see tools and patterns? You mentioned that FinOps is much more mature when it comes to framework and tooling, et cetera, et cetera. Do you see some no brainer techniques or patterns or frameworks being adopted in the GreenOps movement or are we still in a would say searching and exploration mode.

Sarah (12:01)

I think, yes, a lot of the things are already being adopted in the grown-up space, but people just don't realize they're already doing it, if that makes sense. I'll give you an example, right, like automation. Like automation has been everyone's best sidekick for people from SREs to devops to engineers to testers, automation is there to allow us to continue to the bandwidth to innovate, to work on exciting business problems, right? And automation is not just a way to achieve in DevOps. Automation also have loads of other co-benefits when you think about it through the GreenOps perspective.

Gaël Duez (12:50)

I would say that I see these adoptions and especially in automation, getting a lot of interest. I'm still concerned about the gap between willingness and action. Which leads me to this very related question. In the chapter on operational efficiency, was it monitoring? I don't remember, but that's okay. You mentioned that reliability engineer and sustainably advocate should be best friends. And Wilco, who's a regular listener of the show and I were discussing about it. And his question was a very pragmatic question that he wanted to ask you. Where are sustainable site reliability operational practices hitting a roadblock? And what should be the key focus to drive them forward in 2025?

Sarah (13:40)

Right, so I guess the biggest roadblock, not just for SRE or sustainable advocates or anyone really, is the measurement piece. We really can't improve what we can't measure. I guess speaking as an SRE, we really, really need that standardized real-time metric across the board. We SREs have like perfected production monitoring in the last 10 years. So if the sustainable people really have this metric ready for SREs, we can then just throw this metric over the fence and have them start treating it like one of the golden signals. the four golden signals of production and monitoring, or as I would like to call them similarly in the book. the fore horseman of matrix based monitoring, a latency traffic error and saturation. So, so yeah, what that means is that we SREs use them alone with the concepts of SLO and SLI, service level objectives and service level indicators to serve our clients. And I'm hoping, I'm really hoping that everyone who's in the software business can agree with me that everything we do, really everything we do comes down to our clients, right?

It really is measuring, but we really shouldn't be inventing the world of how we should treat this real time metric. We really should be using the concepts of SLOs and SLIs and aeroboject to drive the actual needs of what our client wants. Right? For example, I can go on and on and on. Sorry.

Gaël Duez (15:05)

But I'd love to listen to your example.

Sarah (15:25)

Okay, so for example, if any of those fancy new feature we talked about is going to disrupt one of SLOs, then why are we really even pushing out the new features? We should be looking at how to stay true to our promises to our clients based on the service level agreements and service level objective that we have established already with them. And moreover, if for the past months we have had many late night incidents, should we really be pushing out new features? Shouldn't we be focusing on fixing the reliability and the resilience of our website? Again, using the concepts of SLO and our project to make business decisions. And sometimes I think engineers. Forget the enormous complexity that comes with supporting a four nine services. And if you really want to strive for a four nine services, and in this context of four nine of availability, I means a system being operationally available 99.99 of the time, which means that a maximum of 52.56 minutes of downtime per year. And what that means, per month is you only get to have 4.38 minutes of downtime per month. And downtime here, what we mean is we don't just mean the time we might have spent solving an incident, but also any time when the system is not working. For example, some people might have CI-CD set up to do automated upgrade security patches, or they are not allowed to do continuous rollout, so they need to have rollout schedules so yeah, I am really, really, I'm a strong believer that we, Software Practitioner, should follow suit with what SRE are already doing. We have to treat the environmental metric like any other monitoring metric and use it to drive critical business decisions. Why are we pushing our new feature? It's just going to massively drive up our product's rate of carbon emission, right? So yeah, I really should stop, otherwise I can go on and on and on. But really long story short, believe, site reliability engineering principles are pretty sustainable already as lay out a set of disciplines that keep us honest in delivering what our clients truly want.

Gaël Duez (17:47)

It's just that. Let me think a bit. I think it's really, really enlightening the parallel that you make. And that's for sure that with the SRE framework and all this tool, the SLI, the SLO, could even go to the SLA, et  et we could copy past sort of this methodology or incorporate within it the environmental impact metrics. What I see two pitfalls at the moment is the first one. There is no such direct business consequences of not respecting an SLO when it comes to environmental impacts, at least until now and until we have got some serious regulations regarding carbon emissions or other environmental impacts, which are unfortunately not happening that much at the moment. Now, it could still be the case if there are some very strong internal commitment or if some company had very committed stakeholders requiring to meet a certain carbon budget, a certain water budget, etc. But my point is for the general company, the feedback loop is not as strong when we discuss environmental impacts than when we discuss reliability, site reliability impacts. That will be my comment number one. And please feel free to comment. What I would just add also on top of it is that, and you're going to hate me for this, do we always need 99.99 % of reliability to sell vegetables? If a simple cohort analysis will show that 99.99 % of our customers are sleeping because we are very focused on a single area for eight hours a day and they never visit a website. And I'm a bit provocative here, but I see your point. also see that sustainable leach should also help challenging what should be our SLO. And the dogma that I've been following thoroughly when I was CTO, like 99.99%. And I remember these dashboards and I remember this hard discussion with product managers wanting to push new features, et cetera. So it's really ringing a bell, 100 % resonating with my past experiences, what you've described. However, if I were to be in the same reading room today, I think I will challenge much more the SLO and maybe make it a bit more subtile, sorry for this poor use of word, by agreeing that SLO should be adjusted for time for certain categories of customers, because that will also dramatically help to reduce the system footprint. So that will be my comment number one and my comment number two. And feel free to disagree entirely with these two comments.

Sarah (20:41)

Okay. So the, so the first comment is that, because there's no strong sense to come to, be compliant with the SLOs that people set out for the green software metric or something that people will not be as willing to like uphold what promises they've made. Is that, I getting that correctly?

Gaël Duez (21:06)

Absolutely, absolutely.

Sarah (21:07)

Yeah, you know what, like… I think sometimes SRE principles are more than just a technical set of problems that we're trying to solve. They are more of a cultural problem as well. And it really is trying to solve cultural problem between teams, how to get teams to work together, how to get everyone to understand that reliability of a system is our one true goal, right?

That is not just so for self-ingenious who are just pushing our features, they need to understand how difficult is it to support their own features, right? So I think SRE is a great set of disciplines, but people sometimes forgot to look at the other side, which is a massive cultural problem, right? Like having people to buy in on this of principle is not that easy.

Sarah (22:00)

And I think that can be said about having people to buying on green software slightly as well. But I just think it's so important to put a message out there that we are ready to treat this important metric as one of the signals that SRC already tracking. And we already have this framework of SLO census lie and error budget to really consider how reliable and how reliable not even just in the sense of availability and resilience, but how reliable we are with the promise to our clients of how much carbon our thing should be emitting. So I think it's a lot easier to say than done. And when we talk about SRE, a lot of the time people forgot the culture side of the clash people have when they start bringing SRE principles. So yeah, I do agree with what you just said. It's really hard for people to stay compliant without the regulations. But the message we want to get out there from the book is that there is this framework. It's being tried and tested. It's working. And we should now reinvent. I think that's the message. And then I think for the second question, right, is about the wheel.

Like you want a full night services, but just for the eight hours that your customers are maybe awake. But I think that's not how availability work because availability is soft, like average for months. So for example, like you, you are building an internal web app and, and then the, the, the user of those internal web app lives in, I don't know, in Singapore, right?

Do you really need those web app running when those people has come home? And then you would take the average of all availability, not just the eight hours they're working, but then the time they're not working. So I think that just means you really are not aiming for four nine services. is, I really feel like people use four nine as a badge of honor to say, hey, my service for nine is so complex we really shouldn't be using four nights as a badge of honor. Like you really need to figure out exactly what's needed for your clients, not like what you want to do, right? Similar to like the whole embodied carbon argument, people...

Gaël Duez (24:27)

Absolutely.

Sarah (24:32)

Want to use the latest and greatest technology to build a mobile app. But do you really need that though? Like if you're just having, I don't know, like a news reading website, you don't need the latest chips or the latest technology to run that kind of app. So, so yeah, I think it's all about compromise and trade-offs and, and it is hard for engineers because it is a lot of fun to work on the latest stuff. Yeah.

Gaël Duez (24:56)

Absolutely. And it's part of the cultural game, I fully agree. Now, just going through all this very interesting straight of thoughts around SRE, implementing this SRE framework, tested and reliable, as you said, requires to be able to monitor and to monitor, there is also the question of to observe and observability. So my first question would be did you notice any significant improvements in monitoring the environmental impacts of the code in production? Because this monitoring is a prerequisite to implement all this SRE framework that you've mentioned before. And you touched upon this point earlier in the episode. So what are the trends regarding monitoring at the moment? And maybe you want to add observability. mean, answer it the way you want.

Sarah (25:51)

So yeah, I think we have made good progress, really, really good progress in this space. Even though, again, I already said, we still don't have that standardized real-time carbon metrics, right? Well, we are seeing more and more projects popping up around in the cloud-native space, in the Kubernetes space. Now we have Kepler, which use EBPF to work out the real-time power consumption for Kubernetes workload. You're probably thinking, yeah, but… Power consumption doesn't take into account the carbon intensity of the sources, right? So again, we are making progress, but not to where we want to be yet. But it's great to see those progress. And of course, I have to mention SCI right? We have now SCI being recognized as an ISO standard, not just universities are teaching about them, but a researcher team in Germany has now extended OpenTelemetry Java agent to generate SCI score automatically, which is really, really neat.

And yeah, so I think we have seen significant improvements in the space and the second sort of like the second tale of the questions about observability. So yeah, I guess like, again, I should spend the better half of an hour to talk about how great monitoring is, but the world has now slowly moved on to observability. And so should we slightly? And right before we get too excited, let's take a step back and then let's discuss what is the difference between monitoring and observability. And to borrow the phrase, all you used earlier, this is a million dollar question that every SRE has been brewing over for the past couple of years. So yeah, it's very nerve wracking, but yeah.

Gaël Duez (27:48)

We're gonna get rich!

Sarah (27:53)

Anyway, hopefully I don't get it wrong trying to explain what the differences are. So as we all know, microservices architectures are our favorite frenemies. They have not just brought us incredible agility and speed to push out new features, new way for the team to work as a team to collaborate, but they've also made our system rather complicated. If anyone at home can look up something called the Romsfield Metrics, it's basically a framework not initially designed for software engineering or software operations, but a paradigm that has been broadly applied in different fields across various So the framework can help us get a better grip on our understanding of uncertainty and certainty when we are making decisions rise of four quadrants basically divided into like knowns, knowns, knowns, unknowns, unknowns, etc. So yeah, so traditional monitoring is really, really good at helping us figure out a set of problems, knowns and unknowns, which is quite mouthful, but I'll give you an example. If we have a monolithic application experiencing performance issue, we are probably know which hand of metrics that we need to instrument and monitor. And for example, it could be a CPU problem. And what that means is we then need to set up a plot of graph, maybe set up an alert, monitor the CPU usage of applications to make sure our system never become overwhelmed. And well, probably everyone can agree that the issue of an overwatt CPU is very well established problem that many people have already faced before. So generally speaking– It's a relatively painless bug to solve because CPU usage is a metric. We already know how to monitor and the problem itself is well-astooned. However, bugs can become very, very tricky really quickly as we move through the quadrants to problems that are known as unknowns and unknowns.

Think of it this way, right? If you're a mobile developer, and what kind of metrics and dashboard do you need to set up to detect an issue that only affects the Pixel 7a in Taiwan, right? And you as a mobile developer, you probably don't just support one generation of the phone, but you support the past five generations and maybe different flavor of Android phones as well, right? And Taiwan, it's just one small country. There are so many other countries that you have to support. So again, traditional monitoring does need a bit of spruce up as it's really, really hard to predict what could have gone wrong and where things might have gone wrong. And you guys know how much I love making analogies. My favorite analogy for debugging an unknown problem is to think of it as a murder mystery without any clues So yeah, what is observability?

Observability originated from something called the control theory. Specifically, we define it as a measure of how well the internal state of a software system can be understood from its external outputs. So the way we can think of it is that observability will not just help us identify that something has gone wrong, but where and why something has gone wrong. So in green software terms, we want all this. We want to be able to pinpoint exactly where in our system maybe is a process that has violated our green promises to our clients, right? And we don't also just want to know why, we want to know where and how so we can fix it.

So this emerging topic is again another set of like thinking and principles that serve as a really good exercise for us to start thinking about how exactly will we fit into the space, if that makes sense. And again, why are we reinventing the wheels?

Gaël Duez (31:55)

In me, again, as you say, and it makes me think that this is a big, rabbit hole and I really want to dive into it, but I cannot because you're not supposed to do too long podcast episode and because otherwise my boss wouldn't be happy, my shareholders wouldn't be happy, my advertising companies wouldn't be happy. But the good news is I don't care. I've got an answer of these. So let's ask the question. connecting when you mentioned observability and sustainability, it was really, really connecting two dots in my mind regarding the unknown and the unknown unknown, which is exactly the issue we've got with the carbon intensity of most of the electricity grid. I the question is not we want to monitor most of the time. If you look at electricity maps, and sorry, you can have the same with what time. I'm not advocating for one solution or the other. What strikes me all the time is how much unknown we've got. And even when you zoom in most of the time, it's in many, many countries, it's still country level So when we are trying to take decisions, with an SRE framework, for instance, as you mentioned, we are facing a lot of unknown. And you can even go further with the unknown of the embedded carbon, because with the supply chains today, it's really wild guess to assess what is a true amount of carbon or water or rare resources that are embedded in any piece of equipment. And every time that someone actually does it chemically, to reverse engineering the composition of an IT equipment, they discover new things which add the impacts. And I had beautiful examples recently where people were like, product carbon footprint is so far away from what we are experiencing in our lab. But anyway, sorry, I'm rambling. My turn to be too talkative. My point is, it's very, very interesting to embrace all of this. Observability approach because in the sustainability world, we know that we don't know that much. Now, my question, because there is a question, is do you believe that we sort of embrace fully this observability approach and onboard it within this SRE framework that you mentioned before? Or do you believe that because this is a nascent area, and sustainability, carbon awareness, water awareness, resource awareness are also nascent areas or topics. Adding the two of them will create way too much complexity and people will sort of reject it like it's not mature enough, come back in 10 years when things will be clearer, more structured, easier to use. That's a one million dollar question. Another one. We're going to get very rich at the end of this episode.

Sarah (34:59)

Haha. Why not? Again, I, don't know, speaking, speaking as someone who does write code every day in enterprise setting. what's really important for me as an engineer is that there, there definitely should be space and time for deviation, right? That you can't always be following like I know other people hate the word best practices but you can't always be following what someone at a completely different organization say the best practices is right. We need to allow time and space for people what best practices mean for them in their context and I agree that while everything is very convoluted there's too many unknowns, unknowns not just in necessary world in the observability space, we figuring out what's going on with our systems. But like, again, you were saying like, the carbon awareness, water awareness and all that. But it's just so important that we just keep tap on each other. Right? Because I personally don't see observability take a backseat. Like it's going to be how production systems are being run in the future. And then sustainability, I mean, we're on a podcast called Green IO is going to stay, right? So how do we make sure two disciplines that maybe things very, Orthogonal, orthogonal but move up at the same time, right? Like we should still be orthogonal, but we should not be more than orthogonal, if that makes sense. Like we just have to keep tap because it is two separate issues, but there's a lot of overlap and then synergy to share. But it's just important to know why two fields of engineering, these two fields of engineering will have to coexist in the near future. And it's time to make sure we keep tap on each other. Right. And hopefully, observability can influence how green self-engineering field evolved and vice versa. I don't know whether that's the answer you look for.

Gaël Duez (37:11)

I was not looking for any specific answer. I'm really enjoying the conversation. It might be a bit conceptual, but for whoever has coded I think it will ring some bell. Now you mentioned, and I want to have just a bit of time to talk about the book, but I've got one last question related to exactly what you mentioned right now, which is the Green Software Engineering principle. We had a discussion on the trends and the future tools and framework that should be used. I mentioned in introduction that you are actually the chair of the principles of Green Software Engineering Committee. Can you tell us, because we do love insider information, that we can trade yet for another million? So could you tell us more about the new area where you focusing and maybe some changes that you foresee in this principles?

Sarah (38:09)

Okay, I'll try to be short, sorry. I do just want to say that it's principle green software engine, just principle green software. anyway, so some of the area we're focusing on. I'm pretty sure you probably have heard about green software patterns. So Leah Matthew, who I work very closely with is now one of the coaches for the patterns. A loan was Francisco. And they're both amazing. I love working with them. Really great to see them thriving in Green Software Foundation. Anyway, what I'm trying to say is, principles and patterns have always been a very tightly working group and where we meet very regularly to talk about principles and patterns. And principles, after we published version one, sort of come to like a natural end. We still answer to loads of questions. We now have loads of different translations to different languages. We have French, we have Dutch, we have Italian. I think we also have Spanish, Chinese and Japanese. It's absolutely incredible to see the commitment from not just GSF, but then the wider community on translating the principles, principles of So we're sort of like at the tail end of like where the project is for the moment, but now all our energy is on patterns. And I don't want to spend too much time talking about patterns. I'm hoping maybe like, Gaël, you can invite Leah and Francisco to talk about patterns when they reach like a natural milestone. But right now the main focus is about patterns. And you're probably thinking, you keep saying the word patterns, what is green software patterns? So patterns are set up of like vendor and tool agnostic best practices that people can do when they are trying to achieve green software principles.

So that's sort of how I see patterns. They are a set of best practices from a persona sort of view and how to achieve the three Holy Trinity's of Greens of Virginia, which is carbon efficiency, electricity efficiency and hardware efficiency and carbon aware. sort of was happening with principles and patterns.

Gaël Duez (40:00)

Hardware efficiency. A true focus on pattern. And fun fact, before you actually mentioned it, I was taking notes and the note was Leah plus second semester 2025. I guess. So you say. I guess that we are really aligned here that once the work is finalized enough, they will be more than welcome to be on the show. And that's crystal clear that you focus on pattern. Maybe it's time to leave or wrap it all. Honestly, I think I could spend another hour discussing with you, there are also… much smaller second part of this episode or at least a few questions I wanted to ask directly related to the book. So if you don't mind, we will move on and I'd like to ask you five questions, but I've got a very hard challenge for you. Are you ready to tackle it?

Sarah (41:11)

Yes, and I do think we shouldn't have the poor class too long. So I'll speak quicker and I'll shorten my answers. And if we think a question's not working out, let's just can it.

Gaël Duez (41:15)

Ha ha ha ha. So the challenge is one sentence answer. You can do it. So I don't have the options to put some music like, and I'm a terrible singer, so I won't do this. But a few questions I wanted to ask you about the book, because also brings valuable information about

Sarah (41:25)

Okay, wow. I can do it, I can do it.

Gaël Duez (41:49)

its reception and what it says about the current trend in green software. But my first question is, well, you the first feedback is commercial success. So can I ask you how many copies were sold or distributed?

Sarah (42:02)

So unfortunately, I actually don't know. But what I can tell you is that the book has now been translated into Spanish and it's in process of being translated to both simplified and traditional Chinese. So, know, sorry, mom, you still need to read my book.

Gaël Duez (42:20)

Well, that's usually a positive sign because you don't start translations if it's a flop.

Sarah (42:27)

Yes, and there's also, why is it called? An audio book version as well. Forgot to mention that.

Gaël Duez (42:34)

Okay, so if someone from O'Reilly listens to this episode, we would love to get the figures, especially if they're really good, but I know that they're not bad because I've seen the, you know, as I say, the line and people queuing up to get a book signing and yeah, a lot of traction around, but that was okay. That was me being very curious. My second question, which chapters are most suited for a version two? According to you and maybe your co-author if you started to discuss it.

Sarah (43:01)

We haven't, so this is from me and I apologize to Anand and Zara. But probably I would say again, monitoring chapter, because a lot has happened. We now have like real time EVPF way of getting power metric for Kubernetes workload. So there's a lot of interesting space to explore out there. And measurement, because it can definitely do a bit of sprues up. It's already a great chapter, but a lot has happened in this phase. And I guess again, GreenOps right? I think we got to do what FinOps are doing. We need to have the formalized principles and framework written down in a way that's like bite-sized. People can just use it. So I think that's probably the three chapters I think could really do with some spruce up if we're going to do a V2.

Gaël Duez (43:51)

Thanks lot for you, very direct and honest answer. And my last question will be, what's next?

Sarah (43:57)

I am going to make the same joke again. sorry, everyone who's already heard this joke. But what I'm doing next is I'm continue my tour as a rock star talking, signing and hopefully singing about all the good work Anne Sarah and I did for the book.

Gaël Duez (44:15)

Ha ha ha

Sarah (44:19)

So yeah, personally, I will be at QCon London early April on the sustainability track. And then I'm heading off to Devol XX in London in May. And most excitingly, hopefully go to in October in Copenhagen with Zara. This will be third time meeting Zara in real life. So it's very, very exciting. So yeah, that's probably what's next for me.

Gaël Duez (44:38)

Woohoo!

Sarah (44:47)

And yeah, I spent a little bit more time in the how to get SCI into the outer space is probably something I would like to do as well.

Gaël Duez (44:56)

Hmm. Yeah, got it. Congratulations for joining QCon And I must admit that I'm pretty proud because in QCon this year, QCon London, I will have, as far as I know already, two of my former guests speaking because Ludy Akue is also deliver talk about sustainability in IT. So I take it as a very positive sign and I'm very happy with it.

And among all this great news of you talking and being able to push the message and to raise it onto the asm among crazy crowds of fans yelling at you and sending flowers on stage.

Is there any positive piece of news that you'd like to share to close this episode?

Sarah (45:48)

I guess, I actually, don't know. I feel very being put on the spot, but I guess the most positive thing is that, I guess like a quick thank you. I know it's so cheesy. We have enough cheesiness already, but it is a good, a great thank you to every single person I've met in the past year to talk about Green Software to talk about the book and the energy, the synergy and like, and I think you said,

Gaël Duez (45:51)

You don't have to you don't have

Sarah (46:15)

Something, I can't remember exactly the word you said earlier, but what's so great about like, we know climate problems are hitting us hard in the face and the world is on fire. We're getting flooding every other day. But then the positive energy that everyone has to say, if we just get our ducks in a row, we can solve this problem. And that is my feeling that I got from everyone. And it's amazing. It's just amazing. And that's something. I think is a great news that I'm hoping we're hoping to encourage anyone right to get into the green software space. And yeah, it's one of the most amazing space you will feel so welcome. So so yeah, it's that does that count as a good news?

Gaël Duez (46:59)

very good news to close the episode. And once again, thanks a lot for joining. Thanks a lot for joining this episode. Thanks a lot for joining several Green IO conference. all the great work that you're doing looking forward to seeing you again later this year.

Sarah (47:14)

Thank you, No worries

Gaël Duez (47:16)

Thank you for listening to this Green IO episode. If you enjoyed it, please take 30 seconds to give us 5 stars on Apple Podcast or Spotify. I know, it's not easy to find a feature on these apps, but it's worth it. One single rating on a podcast platform equals 1000 likes on YouTube. Maybe this is why they made it a challenge to use, but I trust you to succeed. Sharing this episode on social media or directly with other software practitioners seems also good idea to provide them with inspiration on GreenOps, SRE, observability and the likes. You got the point, being an independent media, we rely mostly on you to spread the word to more responsible technologists. 

In our next episode, I will welcome Boris Kamazayoshikov to debrief all the announcements made about sustainability at the Paris AI Action Summit, starting with the release of the AI Energy Score. Stay tuned. 

By the way, we decided to open our Slack workspace to our listeners willing to get involved in the making and the promotion of the Green IO Podcast and its newsletter. The link is in the show notes and you're more than welcome to join. And one last thing. Visit greenio.tech to check the next conferences we organize. Singapore is in one week and its full agenda is now available. New York is in one week and many speakers have been disclosed. As usual, you can get a free ticket to any Greenio conferences using the voucher GREENIOVIP. Just make sure to have one before the 100 free tickets are all gone. I'm looking forward to meeting you there to help you, fellow responsible technologists, build a greener digital world.