Simplify Developer Namespaces with Multi-tenant Kubernetes with Alessandro Vozza from Kubespaces
Cloud CommuteJune 14, 2024
1
x
16
00:25:2123.22 MB

Simplify Developer Namespaces with Multi-tenant Kubernetes with Alessandro Vozza from Kubespaces

In this episode of simplyblock's Cloud Commute podcast, host Chris Engelbert welcomes Alessandro Vozza, a prominent figure in the Kubernetes and cloud-native community. Alessandro shares his journey from his early days in open-source advocacy to his pivotal role in organizing the DevOps and Kubernetes meetups in Amsterdam.

In this episode of Cloud Commute, Chris and Alessandro discuss:

  • Kubernetes community engagement and CNCF ambassador role
  • Developing namespace-as-a-service for Kubernetes platforms
  • The future of Kubernetes: WebAssembly, AI, and environmental sustainability
  • Building flexible, cloud-agnostic infrastructure for developers

Interested to learn more about the cloud infrastructure stack like storage, security, and Kubernetes? Head to our website (www.simplyblock.io/cloud-commute-podcast) for more episodes, and follow us on LinkedIn (www.linkedin.com/company/simplyblock-io). You can also check out the detailed show notes on Youtube (www.youtube.com/watch?v=5Y8XBTGSSig).

You can find Alessandro Vozza on X @bongo and Linkedin: /alessandrovozza.

About simplyblock:

Simplyblock is an intelligent database storage orchestrator for IO-intensive workloads in Kubernetes, including databases and analytics solutions. It uses smart NVMe caching to speed up read I/O latency and queries. A single system connects local NVMe disks, GP3 volumes, and S3 making it easier to handle storage capacity and performance. With the benefits of thin provisioning, storage tiering, and volume pooling, your database workloads get better performance at lower cost without changes to existing AWS infrastructure.

👉 Get started with simplyblock: https://www.simplyblock.io/buy-now

🏪 simplyblock AWS Marketplace: https://aws.amazon.com/marketplace/seller-profile?id=seller-fzdtuccq3edzm


01:00:00
Yeah, the complexity lies in the

01:00:01
operation, in the

01:00:02
upgrades, the security,

01:00:05
to properly secure a Kubernetes

01:00:06
class, it takes a PhD almost, so

01:00:08
there's a whole sort of

01:00:11
ecosystem that you can do to

01:00:13
secure a cluster. But in

01:00:16
Kubespaces, we

01:00:17
can take care of it,

01:00:18
we can make sure that the clusters

01:00:19
are secure and compliant, while

01:00:22
still offering the freedom to

01:00:26
the developers to deploy what

01:00:27
they need and they like.

01:00:32
You're listening to simplyblock's Cloud Commute Podcast,

01:00:35
your weekly 20 minute

01:00:36
podcast about cloud technologies,

01:00:37
Kubernetes, security,

01:00:39
sustainability, and more.

01:00:41
Hello, everyone. Welcome back to

01:00:42
the next episode of simplyblock's

01:00:44
Cloud Commute podcast. Today,

01:00:46
I have another incredible guest. I

01:00:48
know I say that every time, but

01:00:49
he's really incredible. He's

01:00:51
around in the Kubernetes space for

01:00:53
quite a while. And I think,

01:00:56
Alessandro, the best way is just

01:00:58
introduce yourself. Who are you?

01:01:00
What you've done in the past, and

01:01:02
what are you doing right now?

01:01:04
Thank you for having me. Well,

01:01:07
Alessandro, yes, indeed. I'm

01:01:09
being around for some time in the

01:01:12
cloud-native community. I'm Italian,

01:01:17
from the south of Italy, and I

01:01:18
moved to Amsterdam, where I live

01:01:20
currently about 20 years ago,

01:01:23
to get my PhD in chemistry. And

01:01:25
then after I finish my PhD, that's

01:01:29
my career. So I went through

01:01:31
different phases, always around

01:01:33
open source, of course. I've been

01:01:35
advocate for open source,

01:01:38
and an user of open source since the

01:01:40
beginning of my, since I could lay

01:01:43
my hands on a keyboard.

01:01:46
That led me to various places, of

01:01:49
course, and various projects. So I

01:01:51
started running the DevOps

01:01:53
meetup in Amsterdam back in the

01:01:56
day, 10, 11 years ago. Then from

01:01:59
there, I moved to the OpenStack,

01:02:00
project and running the OpenStack

01:02:02
community. And, but when I

01:02:05
discovered

01:02:05
Kubernetes, and what will

01:02:08
become the Cloud Native Computing

01:02:10
Foundation, I started running the

01:02:12
local meetup. And that

01:02:15
was kind of a turning point for

01:02:17
me. I really embraced the

01:02:19
community and embraced the project

01:02:21
and started working on the things.

01:02:23
So basically what I do is to

01:02:25
organize the meetup and organize

01:02:27
the KCDs, the Kubernetes Community

01:02:29
Days in Amsterdam, in Utrecht, in

01:02:32
the country. That kind

01:02:35
of led me through a natural

01:02:39
process to be a CNCF

01:02:42
Ambassador, which are

01:02:44
people that represent

01:02:47
or are so enthusiastic about the

01:02:50
way the Cloud Native Computing

01:02:51
Foundation works and the community

01:02:53
that are naturally elected to be

01:02:57
the face or the ambassadors for

01:03:00
the project, for the mission.

01:03:03
At this moment, I still do that.

01:03:05
It's my honor and pleasure to

01:03:07
serve the community, to create, to

01:03:10
to run monthly meetups and KCDs

01:03:13
and help other communities thrive

01:03:16
as well. So the lesson learned

01:03:19
in the Netherlands, in the meetups

01:03:21
and in the conferences, we try to

01:03:24
spread them as much as

01:03:25
possible. We are always available

01:03:26
for other communities to help them

01:03:31
thrive as well. So

01:03:32
that's been me in a nutshell. So all

01:03:35
about community. I always say I'm

01:03:39
an average programmer, I'm an

01:03:42
average engineer, but what I

01:03:44
really shine is to organize these

01:03:47
events and to get the

01:03:49
people together. I get the kick

01:03:51
out of a successful event where

01:03:54
people form connection and

01:03:57
grow together. So that's what

01:03:59
drives me in my very core. I like

01:04:03
how you put this.

01:04:05
You really shine in

01:04:07
bringing engagement to the

01:04:08
community, helping people to shine

01:04:10
themselves, to grow themselves.

01:04:12
I think that is a big part of

01:04:14
being a developer

01:04:15
advocate or in the developer

01:04:17
relations space in general. You

01:04:19
love this sharing of information,

01:04:21
helping other people to get the

01:04:24
most out of it.

01:04:27
Actually, I used be, or I still

01:04:32
do play the bass, electric bass

01:04:35
and double bass.

01:04:37
And the bass player

01:04:38
stays in the back next to the

01:04:40
drummer and he creates the

01:04:44
condition so the other

01:04:46
members of the band shine. So the

01:04:48
guitar player usually stays in

01:04:52
front, the bass player is the guy

01:04:54
that stays back and is happy to

01:04:56
create the foundations and cover

01:05:01
the music to really shine.

01:05:04
And that's maybe my nature. So

01:05:06
maybe it reflects from the fact

01:05:08
that I always

01:05:09
love playing the bass

01:05:11
and be that guy in a band.

01:05:14
I love that. That's a great analogy. I

01:05:17
never thought about that,

01:05:18
but that is just brilliant. And I

01:05:21
actually did the same thing in the

01:05:22
past, so there may be some

01:05:24
truth to that. So we met a few

01:05:29
weeks ago in Amsterdam, actually

01:05:31
at AWS Summit Amsterdam.

01:05:35
And I invited you because I

01:05:38
thought you're still with the

01:05:39
previous company, but you're doing

01:05:40
something new right now. So before

01:05:44
that, you were with

01:05:45
Solo.io, an API gateway,

01:05:49
networking, whatever kind of

01:05:51
thing. But you're doing your own

01:05:53
thing. So tell us about it.

01:05:56
Yeah. So it was a great year doing

01:05:59
DevRel and so much

01:06:02
fun going and speaking

01:06:05
service mesh, which is something

01:06:07
that I really

01:06:08
believe it's going to,

01:06:10
it's something that everybody

01:06:11
needs, but I know it's a

01:06:13
controversial, but

01:06:15
it's something that I really, you

01:06:17
got to believe in it. You know,

01:06:18
when you are a developer advocate,

01:06:20
when you represent a company or

01:06:22
community, the passion is

01:06:24
important. You cannot have passion

01:06:26
for something you don't believe

01:06:27
in, for something that you don't

01:06:30
completely embrace. And that was

01:06:33
great. And we had so much fun for

01:06:34
about a year or a bit more. But

01:06:36
then I decided that I'm too

01:06:39
young to settle, as always, like

01:06:41
I'm only 48, come on, I have a

01:06:44
good 10 years of engineering

01:06:48
work to do. So I decided that I

01:06:51
wanted to work on something else,

01:06:53
on something mine, more, more

01:06:55
mine, more, more an idea that I

01:06:57
had, and I want to see develop.

01:06:59
A gap in the market and a real

01:07:05
need for developers to have a

01:07:08
flexible environment,

01:07:10
environments to deploy their

01:07:12
applications. So fulfilling the

01:07:14
promises of platform engineering

01:07:17
as a self-service platform to

01:07:19
deploy applications. So the idea

01:07:21
goes around the

01:07:23
namespace. What is a

01:07:24
namespace? Of course, it's what

01:07:26
the unit of deployment in

01:07:29
Kubernetes really, it's this

01:07:32
magical place where developers can

01:07:35
be free and can deploy their

01:07:38
application without the

01:07:40
control within the guard rails of

01:07:43
whatever the system means, the

01:07:45
cluster administrator sets.

01:07:47
But developers really love

01:07:50
freedom. So developers don't want

01:07:52
to have to interact even with the

01:07:55
sysops or sysadmins. In fact,

01:07:58
developers love Heroku. So Heroku,

01:08:01
I think, is the hallmark of

01:08:03
developer experience where you

01:08:05
just can deploy whatever you want,

01:08:09
all your code, all your

01:08:10
applications in a place and it's

01:08:12
automatically exposed and you can

01:08:15
manage by yourself

01:08:17
everything about your application.

01:08:20
I want to reproduce that. I want

01:08:23
to get inspired by that

01:08:25
particular developer experience.

01:08:27
But because I love Kubernetes, of

01:08:30
course, and because I really

01:08:33
believe that the Kubernetes APIs

01:08:35
are the cornerstone, the golden

01:08:40
standards of

01:08:41
cloud-native application

01:08:43
deployment. So I want to offer the

01:08:47
same experience but

01:08:48
through the Kubernetes API.

01:08:50
So how you do that, and that's, of

01:08:52
course, like this evolving

01:08:54
product, me and a bunch of people

01:08:57
are still working on, define

01:08:59
exactly what does it mean and how

01:09:02
it's going to

01:09:03
work. But the idea is

01:09:04
that we offer namespace as a

01:09:06
service. What really matters to

01:09:08
developers is not

01:09:09
the clusters, is not

01:09:11
the VMs or the networks or all the

01:09:13
necessary evil that you need to

01:09:16
run namespaces. But what

01:09:18
really matters is the namespace,

01:09:19
is a place where they can deploy

01:09:22
their application. So what if we

01:09:24
could offer the best of both

01:09:26
worlds, kind of like the promises

01:09:30
of serverless computing, right? So

01:09:33
you are unburdened by

01:09:35
infrastructure. Of course, there

01:09:37
is infrastructure somewhere,

01:09:39
the cloud is just somebody else's

01:09:42
computer, right? So it's not in

01:09:43
magic, but it feels like magic

01:09:47
because the clever arrangement of

01:09:51
servers in a way that you don't

01:09:53
see them, but

01:09:54
they are still there.

01:09:56
So imagine a clusterless

01:09:57
Kubernetes. The experience of

01:09:59
Kubernetes, the API really,

01:10:01
so all the APIs that you learn to

01:10:05
love and embrace without the

01:10:09
burden of infrastructure.

01:10:10
So that's the core idea.

01:10:13
So that means it's slightly different from

01:10:15
those app platforms like

01:10:18
Fargate or what's the Azure and

01:10:22
GCP ones, CloudRun and whatever.

01:10:26
So it's slightly different,

01:10:28
right? Because you're still having

01:10:30
everything Kubernetes offers you.

01:10:32
You still have your CRDs

01:10:33
or your resource definitions, but

01:10:37
you don't have to manage

01:10:39
Kubernetes on its own because it's

01:10:41
basically a hosted platform. Is that correct?

01:10:44
Yeah. So those

01:10:45
platforms, of course, they are

01:10:47
meant to run in single individual

01:10:49
application pods, but they don't

01:10:53
feel like Kubernetes.

01:10:54
I don't understand. For me,

01:10:57
because I love it so much, I think

01:10:59
developers, I think we have a,

01:11:04
developers love to learn also new

01:11:07
things. So developers will love to

01:11:09
have a Kubernetes cluster

01:11:11
where they can do what they like,

01:11:13
but without the burden of managing

01:11:16
it. But this CloudRun and ACI

01:11:19
and Fargate, they are great tools,

01:11:21
of course, and you can use them to

01:11:24
put together some infrastructure,

01:11:27
but they're still limiting in what

01:11:30
you can deploy. So you can deploy

01:11:33
this single container, but it's

01:11:37
not a full fledged

01:11:39
Kubernetes cluster. And

01:11:42
I think it's still tripling in a

01:11:45
way that you don't have the full

01:11:47
API at your disposal,

01:11:49
but you have to go through this

01:11:51
extra API layer. It's a bespoke

01:11:54
API, so you got to

01:11:56
learn CloudRun,

01:11:57
you got to learn ACI, you got to

01:11:58
learn Fargate, but they are not

01:12:02
compatible to each other.

01:12:04
They are very cloud specific, but

01:12:09
a Kubernetes API is cloud

01:12:11
agnostic, and that's

01:12:12
what I want to build.

01:12:14
What we seek to build is to have a

01:12:16
single place where you can deploy

01:12:18
in every cloud, in every region,

01:12:21
in some multi region, multi Cloud,

01:12:23
but through the same API layer,

01:12:25
which is the pure and simple Kubernetes API.

01:12:29
I can see there's

01:12:31
two groups of people, the ones

01:12:33
that say, just hide all the

01:12:35
complexity from Kubernetes. And

01:12:37
you're kind of on the other side,

01:12:39
I wouldn't say going all the way,

01:12:42
like you want the complexity, but

01:12:44
you want the feature set, the

01:12:46
possibilities that Kubernetes

01:12:48
still offers you without the

01:12:50
complexity of operating it. That's my feeling.

01:12:53
Yeah, the complexity lies in the

01:12:55
operation, in the

01:12:56
upgrades, the security,

01:12:58
to properly secure a Kubernetes

01:12:59
class, it takes a PhD almost, so

01:13:02
there's a whole sort of

01:13:05
ecosystem that you can do to

01:13:06
secure a cluster. But in

01:13:10
Kubespaces, we

01:13:11
can take care of it,

01:13:12
we can make sure that the clusters

01:13:13
are secure and compliant, while

01:13:16
still offering the freedom to

01:13:19
the developers to deploy what they need and

01:13:21
they like. I think we

01:13:24
underestimate the

01:13:25
developers, so they

01:13:27
love to tinker with the platform,

01:13:34
so they love freedom, they don't

01:13:37
want the burden, even to

01:13:39
interact with the operation team.

01:13:41
And so the very proposal here is

01:13:43
that you don't need an operation

01:13:45
team, you don't need a platform

01:13:46
engineering team, it's all part of

01:13:48
the platform that we offer.

01:13:50
And you don't even need an account

01:13:52
in Azure or AWS, you can select

01:13:55
which cloud and which

01:13:59
region to deploy to completely

01:14:01
seamlessly and without limits.

01:14:06
Okay, so that means

01:14:07
you can select, okay, I need a

01:14:09
Kubernetes cluster namespace,

01:14:11
whatever you want

01:14:12
to call it, in Azure,

01:14:14
in Frankfurt or in Western Europe,

01:14:16
whatever they call it. Okay, so.

01:14:19
Yeah, it is still a thing,

01:14:23
so people don't want to be in

01:14:24
clouds that don't trust, so if you

01:14:27
don't want to be in Azure,

01:14:28
you should not be forced to. So we

01:14:32
offer several infrastructure

01:14:34
pieces, clusters, even if the word

01:14:37
cluster doesn't even here

01:14:40
anywhere, because it's by design,

01:14:42
we don't want people to think

01:14:44
in terms of clusters, we want

01:14:46
people to think in terms of

01:14:47
namespaces and

01:14:49
specifically tenants,

01:14:50
which are just a collection of

01:14:51
namespaces, right? So it's a one

01:14:54
namespace is not going to cut it,

01:14:56
of course, you want to have

01:14:57
multiple to assign to your teams,

01:15:00
to group them in environments like

01:15:02
that, prod or test, and then

01:15:05
assign them to your team, to your

01:15:07
teams, so they can deploy and

01:15:10
they're fun with their namespaces and tenants.

01:15:13
Yeah, I think there's

01:15:15
one other thing which is

01:15:16
also important when you select a

01:15:18
cloud and stuff, you may have

01:15:19
other applications

01:15:20
or other services

01:15:21
already in place, and you just

01:15:23
want to make sure that you have

01:15:24
the lowest latency, you don't have

01:15:26
to pay for throughput, and stuff

01:15:28
like that. Something that I always

01:15:30
find complicated with

01:15:31
hosted database platforms, to be

01:15:33
honest, because you have to have

01:15:35
them in the same region somehow.

01:15:38
Yeah, that's also political

01:15:40
reason, right? Or commercial

01:15:42
reason that prevents you from that.

01:15:43
Fair, fair. They're supposed to be

01:15:47
people that love

01:15:47
Microsoft for everything.

01:15:51
I love Microsoft, of course, been

01:15:53
there for seven years. I'm not a

01:15:55
fanboy, maybe I am a little, but

01:15:57
that's all right.

01:16:02
Everybody, that's why the world is

01:16:04
a beautiful place. Everybody is

01:16:06
entitled to ease of their opinion,

01:16:08
and that's all right.

01:16:10
I think Microsoft did a great job with the

01:16:13
cloud, and in general, a lot of

01:16:16
the changes they did over the last

01:16:17
couple of decades, like the last

01:16:19
two decades, I think there are

01:16:20
still the teams like the Office

01:16:21
and the Windows team, which are

01:16:23
probably very enterprise-y still,

01:16:24
but all of the other ones. For me

01:16:27
specifically, the Java team at

01:16:28
Microsoft, they're all doing a

01:16:30
great job, and they seem to be

01:16:32
much easier and

01:16:34
much more community

01:16:35
driven than the others.

01:16:37
I was so lucky because I was there, so I

01:16:41
saw it with my own eyes,

01:16:44
the unfolding of this war machine

01:16:47
of Microsoft. There was this

01:16:49
tension of beating Amazon at

01:16:52
their own game. Seven years ago,

01:16:56
we had this mission of really,

01:16:58
really demonstrating that

01:17:00
Microsoft was serious about open

01:17:02
source, about cloud, and it paid

01:17:05
off, and they definitely

01:17:09
put Microsoft back on the map. I'm

01:17:13
proud and very, very grateful to

01:17:16
be here. You have been there,

01:17:18
Microsoft joining the Linux

01:17:19
Foundation, the Cloud Native

01:17:20
Computing Foundation really

01:17:22
being serious about

01:17:23
Cloud Native, and now it works. I

01:17:29
agree. The Post-Balmer era is

01:17:32
definitely a different

01:17:34
world for Microsoft. All right,

01:17:35
let's get back to Kubespaces,

01:17:38
because looking at the time, we're

01:17:39
at 17. You said it's, I think it's

01:17:47
a shared resource. You see the

01:17:48
Kubernetes as a multi-tenant

01:17:50
application, so how does isolation

01:17:52
work between customers? Because I

01:17:54
think that is probably a good

01:17:56
question for a lot of

01:17:57
security-concerned people.

01:17:59
Yeah, so of course, in the first

01:18:01
iteration would

01:18:02
be a pure play SaaS where

01:18:05
you have shared tenants. I mean, it's an

01:18:08
infrastructure share among

01:18:09
customers. That's

01:18:11
by design the first iteration.

01:18:13
There will be more, probably where

01:18:14
we can offer dedicated clusters to

01:18:18
specific customers. But in the

01:18:21
beginning, it will be based on a

01:18:23
mix of technologies between big

01:18:24
cluster and fireecracker, which

01:18:27
ensure better isolation of your

01:18:31
workload. So it is indeed one

01:18:34
piece of infrastructure where you

01:18:35
can, where multiple customers will

01:18:38
throw their application,

01:18:39
but you won't be able to see each

01:18:41
other. Everybody gets his own API

01:18:44
endpoint for Kubernetes API,

01:18:46
so you will not be able. RBAC

01:18:50
is great, and it

01:18:51
works, of course, and it's

01:18:52
an arcane magic thing and it's

01:18:57
arcane knowledge. Of course, to

01:18:58
properly do RBAC is quite

01:19:00
difficult. So instead of risking

01:19:03
to make a mistake in some cluster

01:19:07
role or role, and then

01:19:09
everybody can see everything, you

01:19:11
better have isolation between

01:19:13
tenants. And that comes with

01:19:16
a popular project like big

01:19:17
cluster, which has been already

01:19:21
around for five years. So that's

01:19:23
some knowledge there already. And

01:19:27
even an other layer of isolation,

01:19:30
things like katacontainer

01:19:32
and firecracker, they provide

01:19:34
much better isolation at the

01:19:37
container runtime level.

01:19:39
So even if you escape from the

01:19:42
container, from the jail of the

01:19:45
container, you only can see

01:19:46
very limited view of the world and

01:19:48
you cannot see the rest of the

01:19:50
infrastructure. So that's the idea

01:19:53
of isolating workloads between

01:19:57
customers. You could find, of

01:20:00
course, flaws in

01:20:01
it, but we will take

01:20:03
care of it and we will have all

01:20:04
the monitoring in place to do. To

01:20:07
prevent it, it's a

01:20:09
learning experience.

01:20:10
We want to prove to ourselves

01:20:14
first and to

01:20:15
customers that we can do this.

01:20:17
Right. Okay. For the sake of time,

01:20:21
a very, very... Well, I think

01:20:24
because you're still building this

01:20:26
thing out, it may be very

01:20:28
interesting for you to talk about

01:20:29
that. I think right

01:20:30
now it's most like

01:20:31
a one person thing. So if you're

01:20:35
looking for somebody to help with

01:20:37
that, now is your time to ask for people.

01:20:39
Yeah. If the ideas

01:20:41
resonate and you want to build a

01:20:42
product together,

01:20:45
I do need backend engineers,

01:20:47
front-end engineers, or just

01:20:49
enthusiastic people

01:20:50
that believe in idea.

01:20:52
It's my first shot at building a

01:20:54
product or building a startup. Of

01:20:55
course, I've been building

01:20:57
other businesses before,

01:21:00
consulting and even a coworking

01:21:02
space called Cloud Pirates.

01:21:05
But now I want to take a shot at

01:21:08
building a product and see how it

01:21:11
goes. The idea is sound.

01:21:13
There's some real need in the

01:21:17
market. So it's just a matter of

01:21:18
building it, build something that

01:21:22
people want. So don't start from

01:21:24
your ideas, but just listen to

01:21:26
what people tell you to build

01:21:29
and see how it goes. So yeah, I'll

01:21:33
be very happy to talk about it and

01:21:35
to accept other people's ideas.

01:21:38
Perfect. Last question, something

01:21:40
I always have to ask people. What

01:21:42
do you think will be the next

01:21:44
big thing in Kubernetes? Is it the

01:21:46
namespace as a service or do you

01:21:48
see anything else as well?

01:21:49
If I knew, of course, in the last

01:21:56
KubeCon in Paris, of course,

01:21:59
the trends are clear, this AI,

01:22:02
this feeding into AI, but also

01:22:05
helping AI thrive from Cloud

01:22:08
Native. So this

01:22:09
dual relationship with

01:22:11
the Gen AI and the new trends in

01:22:14
computing, which is very

01:22:16
important. But of

01:22:17
course, if you ask people,

01:22:18
there will be WebAssembly on the

01:22:20
horizon, not replacing containers,

01:22:23
but definitely become a

01:22:25
thing. And so there are trends.

01:22:30
And that's great about this

01:22:31
community and this

01:22:32
technologist that

01:22:34
is never boring. So there's always

01:22:36
something new to learn. And I'm

01:22:38
personally trying to learn every

01:22:40
day. And if it's not WebAssembly,

01:22:42
it's something else, but trying to

01:22:46
stay updated. This is fun.

01:22:49
And challenge your convention,

01:22:52
your knowledge every day. So this

01:22:54
idea from Microsoft that I

01:22:56
learned about growth mindset, what

01:22:59
you should know now is never

01:23:01
enough if you think ahead. And

01:23:05
it's a beautiful thing to see. So

01:23:08
it's something that keeps me every

01:23:12
day. Now I'm learning a lot of

01:23:14
on-premise as well. These are also

01:23:16
trying to move workloads back to

01:23:19
the data centers. There are

01:23:22
reasons for it. And one trend is

01:23:24
actually one very important one.

01:23:26
And I want to shout out to the

01:23:28
people in the Netherlands also

01:23:30
working on it is green computing

01:23:32
or environmental sustainability

01:23:34
of software and infrastructure. So

01:23:37
within the CNCF, there is the

01:23:39
Technical Advisory Group

01:23:41
environmental sustainability,

01:23:42
which we're collaborating with. We

01:23:44
are running the environmental

01:23:46
sustainability week in October. So

01:23:49
worldwide events all around

01:23:51
getting the

01:23:54
software we all love and

01:23:56
care to run greener and leaner and

01:23:59
less carbon intense. And this is

01:24:03
not just our community,

01:24:07
but it's the old planet involved.

01:24:09
Or at least should be concerned

01:24:11
for everybody concerned about

01:24:13
the future of us. And I mean, I

01:24:17
have a few kids, so I have five

01:24:20
kids. So it's

01:24:21
something that concerns

01:24:22
me a lot to leave a better place

01:24:25
than I found it.

01:24:26
I think that is a

01:24:28
beautiful last statement,

01:24:30
because we're running out of time.

01:24:31
But in case you haven't seen the

01:24:33
first episode of a podcast,

01:24:35
that may be something for you

01:24:36
because we actually talked to Rich

01:24:38
Kenny from Interact and they work

01:24:44
on data center sustainability,

01:24:45
kind of doing the same thing on a

01:24:47
hardware level. Really, really

01:24:48
interesting stuff. All right.

01:24:50
Thank you very much. It was a

01:24:52
pleasure having you.

01:24:55
And for the audience,

01:24:57
next week, same time, same place.

01:25:01
And I hope you're

01:25:02
listening again. Thank you.

01:25:04
Thank you so much for having me.

01:25:06
You're welcome.

01:25:08
The cloud commute podcast is sponsored by

01:25:10
simplyblock your own elastic

01:25:12
block storage engine for the cloud.

01:25:14
Get higher IOPS and low predictable

01:25:15
latency while bringing down your

01:25:17
total cost of ownership.

01:25:18
www.simplyblock.io