Hey everyone, my name is Patrick Q and if you're interested in
sustainable software, this episode is for you.
Or actually, you should be interested because something
doesn't add up. Out of all the cloud resources
that have been provisioned, we only utilize about 20%, which is
insane. Joining me today sharing his
knowledge is Brendan Camp, founding engineer over at
Resync. And I love his tagline
everywhere. Conscious coding, less carbon.
Enjoy. There's a lot of terms that pop
up nowadays with regards to sustainable software or
sustainable tech, even green tech.
When I say sustainable tech, what does it mean to you
specifically? I think for me personally, I
don't know, I don't know if this was in the Netherlands, but in
South Africa growing up, we had this like little song that goes
like reduce, reuse, recycle. I think the tech industry has
been growing substantially in the last, I mean 50-60 years,
right? And it's evermore growing, it's
scaling. And I think the big
understanding is that there's a lot of wastage, right?
This is in terms of like your server usage, your like the
software that's being built, the power consumption of data
centres. So for me sustainable software
is designing your software in such a way to make the best uses
of the resources that are provided for it.
This also could be just not writing the software if it's not
like adding the value that you actually if it's not adding
value, right? I would say that's like a very
high level and I'm happy to jump into any of the like caveats of
that. But if looking at it, I think at
the moment we don't have sustainable software, right?
I think there's a couple of small like pockets of it jumping
up here and there. But in majority terms, we're
running these behemoth systems that could be 1/4 of the size if
we really wanted them to be. But there's no money in that, or
there's not as much money in that as in scaling your
software, right? Yeah.
And when you're saying it's not sustainable, is it then because
it has a lot of aspects, right? It's how you run it, like the
infrastructure side of it. It could be the software, how
you write it, how you accommodate for it, what
language you use even. Yeah, I think I mean the, I mean
the language thing is always the first thing that pops up writes
is like, oh, Python is 370 times less efficient than C, right?
In the end, I don't think that matters that much, does it?
I think that's the last thing to look at, right?
It's like, I mean, if you want to write your code in C and you
love C, go for it. If you want to do it in Python,
I mean big Python fan. I write most of my stuff in Go
just because that's the I. Like Go.
I mean that that that's kind of the tool of my, I would say my
generation of software, right? It's like you, you had the older
people doing Java and C and then Python kind of came in and then
Go arrived. And especially with like cloud
native Go is kind of your go to tool.
So that's what I do most of my work in now.
But across all of these, there's ways to optimize any of them,
right? Like Python, looking at the
pilot compiler, like Cython and all of this, you can reduce the
impact of it quite substantially.
I think the when we talking about writing software and how
to write sustainable software, it's more along the lines of, I
would say, profiling your software.
So for instance, I always use this example just because it's
such a good example. But in computer science, before
I dropped out of university, we did a big O notation, right?
Which I'm assuming you've heard of it, right?
And for me, I was like, I'm never going to use this, right?
Like I write software, it works, I'm happy.
And then I started at my current company, Resync, and we started
looking into, all right, how do you optimize your software for
sustainability? And one of the first things I
looked into was big O notation, right?
Let's take different algorithms, let's profile them, let's see
what the impact is. And just changing an algorithm,
you can have like a 90% increase in efficiency of your software.
Now, that also does mean that you have to understand a lot of
these algorithms and it does become more complex the more
optimized your algorithms do get.
And I'm not saying like just go through your entire application
and try and optimize every function and make it more
efficient. But what I would say is have a
look at the hot pause of your software.
Like what part of your software run the most?
If you're looking at an API, right?
Like what end point is getting hit the most, right?
Let's take that. Let's see if we can maybe
profile it using whatever tool you, you or you want.
And once you get an understanding of where the
bottlenecks in that hot path are, try just optimizing that.
And you'll probably find if you optimize one or two hot paths
into any software and leave the rest completely alone, you're
probably looking at like 50 to 60% of your overhead of that
software running like reduced. So it's these kinds of concepts
of just try and not think of. Well, the only thing, how do I
even say this? All right, sorry, my English
does fall down a bit sometimes even though I'm a native
speaker, but you would never guess.
Essentially, try and use these techniques and use optimal
software as one of the foundations of writing software
rights. I mean, most of the cases you're
like feature release, business value, like these are the
primary drivers of software, right?
And if you look at any teams nowadays, they're just churning
out features, right? And there's a lot of business
pressure to do this as fast as possible.
What I've found is that if you learn the techniques to write
more efficient code, which does take a little bit of energy and
not everybody has this opportunity.
But if you just take a little bit of time to learn that and
then you start implementing this in the features that you're
releasing, your code does seem to just work a little bit
smoother, does seem to just you're able to ride it a bit
faster. But it's that upfront investment
that a lot of companies or people aren't doing and.
I mean, what I would wonder is, is it worth it?
Because if I that I can look at these Hot pockets and I can
optimize it, but down the line, I don't know how much of an
impact I'm making just by virtue of those optimizations, right?
Usually when I'm on the cloud, I can look at costs, but that
doesn't usually translate as much into my emission output, my
carbon footprint at the end of the day.
And then also, I mean, especially within go, like you
optimize for the person that reads it right at the end of the
day. So you can make things more
complex by optimizing it, but you might just miss out on then
make it more readable. Yeah, that's a hard trade off.
Well, I kind of disagree with this.
I am a firm believer that beautifully written code is
generally optimal. OK, So what what I understand of
code is that it was like a lot of coding languages were written
by people to simplify the layer below it, right?
So we're abstracting away from like assembly to C or from C to
Python, right? Because people don't want to
deal with memory. So they throw something on top
of it called Python so they don't have to deal with memory,
right. But the people that both those
that abstraction layer of coding language, they're consistently
thinking of how to simplify, right?
So often times when you have really nice readable code,
right? And not all the time, there are
definitely exceptions in this case, but when you have nice
readable code, it's generally also the optimal way to write
it. So if you look at open source
projects now, Kubernetes, right, I mean a large amount of the
day, the code base is difficult to get into.
But once you understand the patterns around it, and that's
all readability is, is writers like understand the patterns of
a language or understanding the patterns of a code base or a
concepts, right? Once you understand those high
level patterns, going through the code base starts becoming
easier and easier. And in this case, I would argue
that readability, right? And I would also argue
Kubernetes is pretty optimized for its size, like in usage.
Well, most of it, right? There's obviously some bits that
they're still trying to optimize, but in most cases a
lot of it is written for having the smallest footprint possible
for the value that it provides. Yeah, from that lens, it made me
think of like nested if loops or for loops, basically cyclomatic
complexity. And I've always had linkers that
say, OK, you can't do this, this is just hot garbage basically
because we we run into a point where the complexity's so high
that the linkages complaints and you have to make a change.
And at the end of the day, when I then restructure my code, I do
see a difference in readability and it's also probably more
optimized. Or I try and find out, OK, can I
actually use a map here? Do I need to nest all these for
loops actually to get to where I need to be?
And at the end of the day, yeah, that does make it readable.
Yeah, I've my, my, my colleague, we were, we were actually
discussing this exact topic the other day.
And she said when she looks at good code, she doesn't know what
makes a good code. But you can immediately see it,
right? You start reading through us and
you're like, this is good code, right?
And I think it's just a combination of all these small
things like not having like F for loops, like nested down that
your brain. I, I don't know, have you ever
read that book Thinking fast and slow, right.
I mean. I haven't read it, but I've
heard many things. About it, yeah, well, it comes
down to that, right? It's like your right brain picks
up patterns and at your right. And I, again, I haven't done a
lot of research into if this is correct or not, so forgive me if
it's wrong. But this understanding of your
right brain being able to very quickly pick up things and give
you a gut feeling. It's not necessarily a gut
feeling. It's just your right brain
identifying things far quicker than your left brain can and
going through a code base. And you get this gut feeling of
this is terrible or this is great is one of the first
indicators that I generally use to see or write.
Is there something to do here? Is there something to fix here
to optimize here? There's obviously darn other
things that you can then go and go look into, but reading
readability and having the ability to like quickly
understand code, my gut feel is almost immediately that this
actually looks pretty good, that maybe there's a lot less to
optimize here than previously thought, right?
Interesting. I think Go is just a really good
example of when because there's not many tools to do the same
thing in Go, right? If you go to Scala or Python, I
can do the same thing in Python And probably write it down in a
few lines, or I can make a beautiful one liner and then
it's a It's very subjective on what is more elegant and what
might be more efficient. If the one liner is more
efficient at the end of the day, do I then go for readability or
do I go for that one liner? That's where my thought was, OK,
is it worth it 'cause with go? Yeah, I I can't think of many
examples where breaking it down, making it more readable doesn't
also make it more efficient. Yeah, well, I think unless
you're so let's move to Python, right.
I think I mean my my first back end engineering job was Python
And I fell in love with Python. I just love the semantics of it.
I love the they have the Zen of Python.
I don't know if you've read that.
So if you go in Python, like the Python CLI, if you just go
import this, it prints out this poem or yeah, I think it's a
poem called the Xenopython. And it's like explicit is better
than implicit. Like all these like small little
things to like kind of guide you on how to write better Python.
Highly recommend trying it out. And I think the idea with Python
is that when it comes down to it, those one liners versus the
three liners or four liners, like you're talking about like a
split of a nanosecond difference in a lot of cases, right?
And in that case, definitely go for readability.
There's not like we're not going to split heads over the those
kinds of small, small increases in performance, right?
I think the big problems come in is when you're starting to use
like a greedy algorithm versus AI don't know something like a,
a tree tree based algorithm, right, where you're trying to
brute force something instead of like working it out
mathematically. In those cases where your
consumption is like 100% more than like, yeah, readability,
you can make a good algorithm readable, but having those
separate approaches to the same problem is where I think your
optimization really starts coming down to like splitting
hairs, right. So, yeah, especially in Python.
My so I, I had a colleague back in the day who always used to
say, write your Python as if the next person to read it is an axe
murderer who knows where you live.
OK. And that always stuck with me
because you're always like sitting there, like, all right,
the next person needs to be able to jump into this and they've
got to love me for writing this, right?
Oh, in that way, I didn't get it at first.
Yeah, yeah. Because if they hate me and they
know where I live. I'm in trouble, right?
So, yeah, but if we like, if we want to kind of move away from
the coding language side of things because I, I think like
again, I think your code is the last place to look for
sustainability impacts, right. My colleague Gabby and I just
did a talk in at Cubecon where we were, we did like quite a lot
of research into infrastructure side of things.
And regardless of what you're running on AVM, it seems that
the standard for VM utilisation is like I think 20% worldwide
average. That's horrible.
Right. Yeah.
And this isn't one company that says this, this is IBM, this is
researchers from universities. Like there's so much data out
there saying that our servers are underutilised, right?
And the reason being from my perspective is the last, I mean,
since the cloud started, we've had the scale mindset, right?
I mean, we've all heard the cloud is infinitely scalable or
not. We've all heard like it's a
hardware problem, right? It's not a software problem if
we have a server that consumes energy that's emitting
emissions, that that specific server took emissions to create,
you know, the embodied side of things.
And we're only utilising it at 20% for four, four years or six
years or whatever your provider does and then throwing it away.
You've only got 20% of the value out of that server for its
lifetime, right? And I don't suggest running all
your servers at 100% utilisation, probably not going
to give you the performance that you want.
Yeah, but 20? Come on.
Yeah, right. And this is so embedded in our
thinking that if you look at any like demo apps out there or if
you look at any of the, I don't know, you home install
something, right? And you look at the requests and
limits that have been provided on there.
Generally everything's over provisioned.
Everything's requesting much more, much more CPU than it
needs, much more memory than it needs because we have this
feeling of all right, if it's if we ask for more and it doesn't
use, it is much better than if we ask for less and it goes over
that and it like we get performance hits, right.
And I get that from the retail side, like if it's Christmas
period, you're going to hit peaks you'll never hit
otherwise. Yeah, 100% but then don't
provision for Christmas every day of the year.
That's fair. And I think the, we just
recently a Dutch company, I'm not sure if I'm allowed to
mention them, but it was such a cool perspective for us because
we got to go in there and look at their systems and apply all
this knowledge that we've been researching for so long.
And immediately the big thing we found was they have scheduled
workloads that have like these peaks once a day, right?
So for an hour a day, they use 80% utilization of the server.
The rest of the day it's sitting on like 20%, right.
But they've provisioned their server for that one peak.
That's an hour, right? And we went through and we had a
look at a whole bunch of other things.
But the idea that if you just take that one job and like
isolate it, give it its own resources, don't like put in a
Kubernetes cluster with everything else that you have to
keep scaled up. We could reduce their
infrastructure by about 40 to 50%, which was equivalent to we
even did like their missions math and it was like something
stupid like 500 kilograms of CO2 a month that they were saving by
just splitting this one thing out.
Well, who who needs to help there?
Because I think this is interesting.
I told you before, I'm working at ING and ING is trying to be
at the forefront of financing people's path to net zero.
And for me, you have this cloud provider which gives these suite
of tools available and you have the people that use it, right.
And if they use it in the wrong way, they also pay for it.
And at the end of the day, if they have enough money, they
don't care. 20% utilization. We we optimize for a peak,
doesn't really matter if the cloud then similar to what a
bank can do says OK, you have 20% utilization, we put a
penalty on that and you pay more.
Do you think that would help then users be more optimal with
how they utilize it? Because right now there's no
incentive other than the cost they already pay.
And obviously like sustainability mindset.
So, so I, I think one of the questions you sent me was like,
what's a contrary contrarian belief that you have?
So I'm just going to use this as that now.
I believe that a lot of these hyperscalers are damaging the
industry because like you say, the incentives they have is
money and usage, right? They really don't care around
the 20% utilization. They're my, my wife's company.
She was like telling me how like they got credits for AWS.
So their money, like their cost for running on AWS was like €50
for like a year. And what all the engineers did
is they went crazy and they just started provisioning things and
like use everything, like really scale everything up.
And once the credits end, it jumped like 10,000 fold.
Yeah. And everything was designed
around the system. So you can't just go, OK, let's
roll everything back because you're making money off of this
now. So you kind of just have to sit
and the credits that they gave you versus now what you're
paying, obviously they're going to get the better deal out of
that. That you.
My mother always said nothing in life's free, right?
So, and I think that cloud providers specifically because
their incentive is there to make money and also because they
don't, they don't want to be seen as people whose incentive
is to make money, right? They're starting to actively do
very shady marketing things. So one thing that came to light
recently is this whole idea of like, they're pushing their own
sustainability dashboards and their own sustainability
metrics, right it. Should be a good thing though,
yeah, yeah. Great thing.
Transparency is key, I 100% agree with it.
Then you go down this like rabbit hole of carbon
accounting, right, and you get this idea that you get two ways
of reporting emissions. You get location based emission
reporting and you get market based emissions reporting.
So when a hyperscaler has a data centre and they're, they say
this is 100% green data centre, right?
There's a very good chance that that data centre is running 90%
coal, right, and 10% renewables. But what they have done is
they've invested in planting trees somewhere or they've
invested in a, a wind farm or a solar farm somewhere.
And because of some accounting, that now means that they can
shift those accounting credits onto that data center and reduce
that 10% renewable energy to to or increase it from 10% to 100%
green. They call that offsetting no?
Yeah, Yeah. It's carbon offsetting.
But then you look at when you're going through what region, what
data centre should I choose because I want to be clean.
I, I as a individual believe that I can make an impact and I
want my decisions to reflect that.
I will go and choose that data centre because of the marketing
material that's been given to me saying that it's a green data
centre, right? Obviously because I'm trying to
do my best. So my question then comes in is,
is that not hyperscalers being incentivized to do more of this,
right, to planting more trees so that they can keep running their
dirty data centre and then kind of like tricking people into
using that data centre? And I don't believe it's any
individuals. Like, I don't think there's
people sitting at the top going, yeah, we're going to, you know,
pull the wool of these people's eyes.
But I do think when the incentive is to make as money as
cheap as possible, right, which is the current thing.
And I don't think a lot of times governments are very against
this. It's economy, right?
The more money you have in your country.
I mean, ASML is a good example of this in the Netherlands,
right? The more money you have in the
country, the more your economy thrives.
And governments aren't really going to do anything too extreme
with data centres. Because tech brings in a lot of
money into countries, right? Huge tech companies are great
for workforces. They're really great for
promoting, I don't know, people coming into your country with
skill sets. They're dumping a lot into
infrastructure so that they can support, you know, their
employees, their offices, their data centers, etcetera.
So it's really great for a country, but it's not
necessarily great for the environment.
And that again is another conflicting view.
But what? What else can they do?
Then offset it? Because that's, that's kind of
how they can, right? Other than otherwise, they
wouldn't have data centres to operate on if they don't have
actual renewable energy for the whole operations.
So I don't know. It's interesting because one of
the hyperscalers, and I'm also not going to call them out just
because. There's not that many.
One of the big three does location based emission
calculations, which is where you can't take into account any
offsets, right? So they'll give you the actual
amount of emissions that their data centres are putting into
the air. And I mean, you can go Google
who this is, it's all over the Internet.
But they, I think this is the approach to do it right, just
because be transparent. If this I'm a big believer in if
you want to tell me that this data centre is 90% coal and 10%
renewable, tell me that I'm not going to be upset with you,
right? But then let's come up with a
game plan to actually change the emission factors of that data
centre. So shout out to the leaf cloud,
to Deep Green, to all these new distributed data centres, I
think they're called, where they're putting data centres in
things like hotels in, I think Deep Green does swimming pools
in the UK. And what they do is they put
like a small data centre underneath the pool and they try
and use as renewable energy mix as possible, right?
And then they take the water from the pool and they use the
water with this oil that they have to cool the servers and it
heats the public swimming pools. Oh, really?
So it reduces the energy, the energy bill of that public
swimming pool quite considerably.
I think deep green like keeps shouting something like £85,000
worth of electricity a month or a year, I'm not sure.
I don't know how big those pools are.
But that's really cool, actually.
Yeah, that's incredible. But let's do more of this,
right? Where, OK, we need to use energy
for computing, right? Like nobody's arguing and
nobody's saying turn off every server in the world, right?
I don't think that's. That's also not a solution.
That's not a solution, right? We still need to grow, and we
still need to maybe not grow as quickly, but we still need to.
I forget the word now. Just we need to move to net
zero. Yeah, we need to move, right.
But at the same time, let's do more of these innovations where
we're taking other parts of society and we're reducing the
the impact of those parts of society and then we're only
consuming a small part of that impact, right.
So overall, it's a net positive. Is it neck positive neck, yeah,
yeah. Contribution, right.
Even though it's not 100% green, we're still reducing the
emissions of something else in society.
And I love this. And I think that more and more
we're going to see this because I don't foresee that.
I mean there's also the social side of data centers as big as
like Google, Microsoft and AWS have like people don't like
having them in their cities, right.
I think there was AI mean it's in the US and crazy things
happen there apparently, but one of the data centers in the US
has water rights over the citizens in the town that it's
built. OK, what does that mean?
So essentially what that means is if there's a drought, the
data center has more rights of the water than the citizens.
That's. Crazy.
Right. So they'll divert the water to
the data centre over the people of that city, right.
And again, you can read the article.
I, I'll maybe try and find it and send it to you.
But this is what's happening in our world, is there's such a big
social impact for these monstrous data centres that may
be doing the smaller distributed way is possibly going to have a
better impact on the surrounding areas, right?
And also trying to do it in a way that we're trying to add to
the Earth and not like reduce it.
But yeah, I think that's like the big thing with data sensors
at the moment is they're just not, they're still trying to
grow. And I just don't think there's
space to grow anymore. I think the, I love the example
that you gave when it comes to out-of-the-box thinking like
using the heat and heating up a swimming pool is, is genius.
The plant a tree is the most default that any company can do.
It's always, it's always plant a tree somewhere.
But yeah, if there is a city and all of a sudden they there's a
drought and the data center has the water, right?
So the citizens don't get water. Like even if there's super
crucial maybe medical systems running on the servers of that
data center, then still it's not like we can probably think of a
better solution to accommodate for this.
Yeah. And I also think you're now
running into the same problem that AI has, right, is who's at
fault when these things happen, when people thought, I'm not
going to say die because I mean, it's a possibility.
I mean, I come from Africa. We had, we've had quite
considerable droughts. People do die in these
circumstances. But when people start dying,
who's at fault? Is it the governments that gave
the rights? Is it the data centre?
Is it like you can't really put it on anybody individually,
right? So when AI 'cause when they have
an accident, who's at fault, right?
Same kind of concept. But we need to move away from
these grey areas and just have a all right, human life over
expansion, right? And like, let's still grow,
let's still grow our economies. Let's still do all the things
that we can to innovate and let's change the world and let's
make the world a better place. But let's not reduce human life
to as a cost, as a cost of that, right?
And different countries seem to have different views on this.
And for me, it's a very black and white thing.
And again, that comes in with perspective, right?
What we're talking about earlier, I don't think you can
understand how other people think unless you've walked in
their shoes and you've lived their life.
But I do think that we need to move towards this more
compassionate way of living, of human life, animal life.
I mean big animal advocate over growth.
Yeah, Yeah. I mean, you touched on AI and I
think that's an interesting roller coaster because all of a
sudden, if you look at, I think I saw an article of Azure and
their carbon footprint, it was actually down trending over the
years. And then I had a significant
uptrend and people were like, well, what happened?
Yeah, we have new models available and all of a sudden
they cost a lot more computing power than their trajectory and
targets previously. And especially if we're in the
slippery slope where it's already hard to get the carbon
footprint down, you get a new technology.
And as that gets more accessible, and we're definitely
on that trend, the more accessible it becomes, the more
powerful. Also, the impact will be more
significant than when it comes to the things we haven't got
gotten up to par basically, especially than data centres,
compute and carbon footprint. Yeah.
I think it's, I mean, then we
shouldn't talk about software in and of its own in isolation, but
actually, yeah, cost and optimization and I think I don't
see any other way other than changing some kind of incentive
structure basically. Well, the EU is trying to do
this right at the moment. There's the Paris agreement that
in 20-50 everything in in alignment with net zero.
I don't know if you've seen the fit 455.
So that's essentially, and I'm not big on parliamentary
documents, but my understanding is it's they're they're
incentivising to reduce carbon emissions.
All companies need to reduce carbon, their carbon emissions
by 55% by 2030, right? Which is phenomenal.
And then on top of this absolutely amazing initiative,
they also throw in a cool, we're also banning greenwashing,
right? You can no longer tell me that
your product is eco friendly without data backing it up that
you have to make transparent to me.
And I think people aren't going to really realize ramifications
of this until like a year or two from now where you have these
massive companies that we thought were doing everything in
their power to protect the planet.
The data starts coming out and saying, all right, but that was
all marketing. That was all.
Some very smart marketer spinning a tail for us and.
Is that greenwashing in essence? I would, I would say
greenwashing is this idea of making yourself out to be doing
things for the climate crisis, for Earth, for social justice
initiatives in order to make yourself more attractive to your
customers so that you have an edge over other companies,
right. I mean, there's probably a very
specific definition. That's my definition.
But my understanding is you there's a whole bunch of wording
that companies in Europe have to start removing from their
websites, as they should. Yeah, without data.
So. I mean, we have that in physical
products, right? You can't say it has some
ingredients or it's going to burn your fat like no other if
it doesn't actually do that. And even if it does, I still
don't think you can do that. I think the the big one coming
out is like terms like net zero and eco friendly are pretty much
going to be like not allowed. Oh really?
Yeah, I think those are the big ones 'cause you're either net
positive or net negative, right? And if you want to state that
you are net. Zero.
Net 0, you're really going to have to provide all the
information on how you calculated that and how you got
to that point by law, by European law, and that's a lot
of work for companies to do. Yeah, yeah.
I mean, from ING, we're helping companies do that, right.
And it's really cool because there, if there is then all of a
sudden an incentive structure by financing a company's path to
net zero, it doesn't just, they can't just say, yeah, we're
there or yeah, these are our numbers.
It's there's a whole auditing process and there's a
certificate that comes out of that that proves validity of
those numbers. And I think that that kind of
proves a robustness of an incentive structure that can
actually help companies achieve that, which I think is really
cool. Yeah, I'm excited for this.
And I think, I mean, this is also why my company has, I mean,
why we started was this idea of this is coming, right?
It's not necessarily in the Americas or anywhere else but
Europe at the moment, but it's coming.
And just with how GDP are completely changed, how data was
handled by majority of the world, this is for me the next
step in, you know, the climate crisis is all right.
If you want to work within Europe, if you want to do
business with European companies, you have to adhere to
these incentives. So that means even if you're a
company in America, if you want to scale globally, you're going
to have to adhere to the same incentives that European
companies are going to have to do.
And that impact is? That's massive, massive because
it's, it's really funny you mentioned market based
emissions, location based emissions.
Those are all scope too. That's kind of the, I think the
output of your production scope one is like, OK, what is your
core and what is the emission output there?
And scope 3 is everything else. So if I do a transaction with
you, then your scope one and two emissions, all of us can fit in
my scope 3 emissions. So then this cascading effect of
looking at emissions, scope 1-2 and three, three being probably
the biggest for companies that do transactions.
For example, ING has scope 3, which is massive because it's
anyone they do a financing deal with.
Which means that if ING wants to reduce their carbon footprint in
at 0, all of the companies they have business with also need to
be on that same path now. Which is exactly what ING as a
bank wants, Which is why they're doing this financing path to net
0. Otherwise they can't do it for
their own sake either. Well, it's also, I mean, this is
also part of the new laws is you have to start reporting on your
scope threes, right? And in order for me to report on
my scope threes, that means companies that I use or people
that I'm in business with have to start reporting, giving me
that information, right? And it's this big knock on
effect of we're potentially going to start actually seeing
the impact of business on Earth. And it's going to be something
that is audited. It's going to be something this
it's really going to be something to actually start
getting transparency of where we are at.
Because I feel like at the moment, nobody actually knows
because everybody's just, yeah, we're in a slightly worse place
than we were 50 years ago, right?
We see cool, the earth is heating.
You have different people's opinions on this.
And I think that having actual data and saying, all right, this
is current emissions, that business in Europe and European
partners is emitting, let's reduce that by 55%.
I can almost guarantee if we achieve that, which again,
that's up for debate, whether or not, yeah, whether or not we do
it. But if we do achieve that, I can
almost guarantee that we're going to start seeing some kind
of positive effects on the environment.
And this is what the end goal is, right?
No matter how much accounting, no matter how much like juggling
or money or everything, at the end, that's the goal.
We want to start trying to figure out how we can survive
for another 100 years as a species, 200 years as a species.
And then it like if I look at the physical product life cycle
or for example renewable energy, it's really hard to go from
specific energy source. And like when we're talking
about physical things. And then you give the example of
software being just like the same as not switching off the
lights, right? Having only 20% utilization but
optimizing and paying in in general for 100% is insane to me
because that seems like a very small ask of someone of
organizations or even incentivized from cloud
providers to then optimize for usage and that's just not being
done yet. I feel like that's where it
should start, right? It's as easy as turning off the
lights. I feel, I feel like going to a
company and being like, please can you save this money that
you're currently spending? Like that should be a no
brainer, right? Especially the larger companies.
I mean, if you're a start up and you're just kind of like getting
into it and you don't really have capacity or time to kind of
do this. Cool.
Understood. You're not a skill yet.
Yeah, you're not having the impact of big companies.
Yeah, exactly right. But the bigger companies, if
they go in and they're like, let's reduce, actually, this is
this is pretty cool. So we had my one colleague and
the our CTO forget all the titles in a small company.
They worked at Adidas for a bit to do cost saving, right.
And it was purely cost saving like nothing around emissions,
but it was just a let's go and let's see how we can reduce
right now. That's a big system that's
arguably one of the biggest e-commerce systems in the world.
And in some cases they were able to reduce systems by about 30%,
right? The savings on that alone, Can
you imagine? Like, I mean, I don't know what
their bill is. If you have like a €5 million
bill a month right from AWS or from your private data centre
and you get a 30% saving on Saturday month, that's
astronomical, right? And the cost for doing that was
nowhere near that for one month. So maybe just having a look at
these things now. And then also being able to
track your emissions like this is also another rabbit hole to
go down. But tracking emissions is
difficult. If you start tracking your
emissions now and then start doing cost cutting exercises, I
would almost bet that you would see some kind of reduction in
emissions. Right.
Absolutely. Not always like there are
caveats around emissions versus costs, especially when you start
looking at like performance and things, but most certainly in
the large majority of the time you will start seeing a bit of a
a downhill flounce on your emissions.
So. And cost is a great incentive.
People love money somehow, so yeah, yeah.
Interesting. But why so I get it from a
knowledge perspective, right, But Fintech was or Finn OPS was
a term which was more so booming a couple of years back.
There are still these incentives or these companies which are not
optimized. If you're saying that we can
still reduce 30% and in relative terms, for me 30% is already
high. But when you then look at the
absolutes when it's 1.5 million, like it's insane.
Basically. Why do organizations not have
the expertise in house to do so? Is cloud still like this new
kind of untangible thing? Do cloud providers not like give
enough insight into what usage is?
Because that's kind of counter incentivized I guess.
Yeah, I'm not 100% sure what it is.
If we look at the consulting that we've done, we've gone into
I I think the craziest thing in all my years of consulting is
whenever you go into a company to consult, you tell them
everything they already know, but it's a different voice.
So they listen this time. Oh, really?
Right. That's a hard fix.
Yeah, it's, it's weird. But like in most instances when
you're talking with engineers and you go, yeah, the server is
underutilized, like let's do something like let's brainstorm
how we can better utilize the server.
They're like, we know it's underutilized.
We know what the problems are. They know their systems, right?
It's just they never given time to do these things.
Yeah, no priority. It's not a priority, right,
because and all these things slowly add up.
But business, I would argue the non-technical side of business,
they don't understand these concepts and they're the people
pushing, right. So you'll often find that the
business side or feature feature value, value, business value and
engineering or the technical side battle to communicate, you
know, legacy systems overhead these kind of technical debt
effectively in terms of business value, right.
And I think that's primarily what I see as the biggest
problem in tech is a lot of, well, one of the biggest
problems, not the biggest problems is that if I have a
tech lead who can't communicate what business value you will get
by tackling that technical debt that you have or technically
tackling that under utilization or etcetera, etcetera.
Business isn't going to give you the ability to do that.
They're not going to empower you, right?
What you generally find is your systems grow until they start
costing too much money. And then then business will jump
in and be like, all right, this is getting out of hand.
We need to slow this down. Then you get permission to start
optimizing, but it's until you get there, business doesn't care
because their focus is on running the business and adding
business value and they don't understand the technical aspects
of it. That's what I found.
So yeah, soon as I go went into this recent consulting gig that
we did, they, we sat there, asked questions for a full day
just yeah, how do you do this? How do you do that?
What's the setup, what's the architecture, etcetera.
And by the end of it, we were like, all right, well, you know,
the the problems are quite clear.
And they're like, yeah, well, you know.
That's the worst. Yeah, that's the worst.
We fully understand this. And then you go like, all right,
so let's chat about solutions, right?
And obviously from a consultant, just because of how you approach
things, you might provide tools that they can use to facilitate
them to a solution. But often times I find that the
solutions come from within the company, right?
And you're just there facilitating them getting to a
solution. And this is no different in this
case with utilization issues is you have, they know what to do,
they know what the problem is. And then as a consultant, you're
sitting there. All right, cool, let's give you
a tool to solve this to business.
So business understands the business value and next thing
you know, they have permission, they have the funding, they have
the backing from business to do it.
And that's happened time and time again over my career as I'm
just there to kind of be a go between between the sea level
people or management level people and the engineers so that
the engineers because for some reason a lot of times people
don't trust their engineers to like.
That's a sad, yeah, sad reality, I guess.
Yeah. I mean, it does show the need
that kind of this communication bridge is apparently necessary
because especially if the I thought it was more of a, let's
say, lack of expertise or lack of knowledge, because that's how
it was when in OPS was kind of booming, right?
Everyone got their hands in cloud technology and started
playing around and all of a sudden, indeed, you get this
bill. And it's like, OK, where does it
come from? But now with cloud providers
giving more insight and more expertise, it makes sense then
that that knowledge is more widespread and then engineers
actually know. OK, Yeah, this is it.
But if then this organizational shift doesn't happen and it's
always new, rather than optimize and actually look at costs, then
even when you come in and advise it's like a one time thing and
then probably it still grows and expands and that is a then it's
not really a tech problem anymore.
That's one of a people problem. I.
Feel like all problems. Are people problems?
That's right. I think that's fair.
I mean, also with this knowledge then I hope that that shift just
happens and it needs more time. Like I am an optimist and that
would be my hope. But I, I also like you also said
something now it's like like when Finn OPS started booming,
there was this big skill shortage, right?
I think a lot of people underestimate the curiosity of
people. And I think when a new problem
arises and there's so great example Kubernetes, right, I
think I started cubing using cube like 0.9 release, right
where we were playing around with it at a customer and nobody
knew anything. Right.
Yeah, and like they were like Ingress, all right, What's an
Ingress? All right, Like drawing it out,
trying to figure out like how the whole this thing works,
right. Didn't understand.
You actually need an Ingress controller for the Ingress and
all these like little components.
And you're like, you slowly learn, right?
That was 20. Gosh, I can't even remember.
It was like early 2010 to 2015. I think some somewhere,
somewhere, somewhere around there.
You look at the skill sets now, right?
I go to any company. Yeah, people know they got it,
they got it. They understand it, they've
worked with it. They've had resources, they have
the Internet, they've learnt, right.
But a lot of people still have that mindset of, oh, there's
like a skills shortage in this area.
No, your people know about it. They understand it.
They just need to be empowered to implement it because you're
telling them they don't know. So they feel like they don't
know, right? And I think that that's what
will probably happen in this case as well, is we will start
building these skill sets to better optimize these systems
because there's a need. And being able to communicate, I
think is another skill that's also starting to become quite
common in tech. If you look at what's this job
title now? Dev Rel.
Dev Advocacy.
Dev advocacy. This is the corner point of
communication and tech skills, right?
It's like teaching people and being able to communicate
effectively, different tech stacks, etcetera.
It's growing. There's a lot of people that are
able to do this. I mean, 20 years ago this was
unheard of, right? And so.
It was more under the radar. It fit into like tech
evangelist. Yeah, yeah.
And So what you have is you have a need for this and people will
fill it, right? And I feel like the need for
optimized emission sensitive systems is coming and people
will grow to it, right? I I believe anyway.
Same here, man. Same here.
Yeah, I love this conversation, man.
It's been very interesting hearing from your experiences,
your knowledge as well. And I think this, I mean, right
now, it's sustainability is kind of always a hot topic, but kind
of always not really. I think definitely within tech,
just by virtue of being more aware and hopefully also cloud
parties incentivising it more, we are gaining more awareness
and with awareness comes at the end also actions.
So I think it's really great. Before we round off, is there
anything you still want to share?
Maybe just a shout out to my colleague Gabby.
It's been interesting and it's been fun.
And if you do want to learn any more about this, we have a blog
at resync.com and I've also got my green coder dot IO.
Send them to me, I'll put them in the description.
All right, fantastic. But yeah, and also I would love
feedback or experience, like if you reach out on LinkedIn and
you have a question or you have an experience that you want to
share specifically in the sustainable software
environment. It's still new, so I'm still
learning and I'd love to hear more people talking about their
experiences. So yeah, that pretty much covers
it. Love it.
Yeah, I love it. Shout out to Gabby as well.
All right, I'm gonna round it off here.
Thank you so much for listening. All Brandon's socials will be in
the description below, plus some additional resources.
So thanks again and we'll see you in the next time.