Building a Time Series Database in the Cloud - Steven Sklar from QuestDB
Cloud CommuteApril 12, 2024
1
x
7
00:23:3921.66 MB

Building a Time Series Database in the Cloud - Steven Sklar from QuestDB

Steven Sklar from QuestDB, a company producing a time series database for large IoT, metrics, observability and other time-component data sets, talks about how they implemented their database offering, from building their own operator to how storage is handled.

For questions, you can reach Steven at:

If you want to learn more about QuestDB:

The Cloud Commute Podcast is presented by simplyblock (https://www.simplyblock.io)


01:00:00
I think one thing that I've

01:00:01
been seeing over the past few

01:00:03
years that I find very interesting

01:00:06
is this move away from cloud and

01:00:09
back into your own data

01:00:10
center.

01:00:12
I think having

01:00:13
control over your data

01:00:15
is something that's incredibly

01:00:17
important to basically everyone

01:00:20
now.

01:00:21
And I think it's to find a happy

01:00:24
medium as a DevOps

01:00:26
engineer between all

01:00:29
the wonderful cloud APIs

01:00:32
that you can use and

01:00:33
going in the server room

01:00:36
and kind of hooking things up.

01:00:38
There's probably a

01:00:39
happy medium there somewhere

01:00:40
that I think is an

01:00:42
area that is going to start

01:00:44
growing in the future.

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

01:00:51
your weekly 20 minute

01:00:52
podcast about cloud technologies,

01:00:54
Kubernetes, security,

01:00:55
sustainability, and more.

01:00:57
Hello, everyone.

01:00:57
Welcome back to another episode of

01:00:59
simpleblock's Cloud Commute

01:01:00
Podcast.

01:01:01
Today, I'm joined by

01:01:02
Steven Sklar from QuestDB.

01:01:06
He was recommended by a really

01:01:07
good friend and an old coworker

01:01:10
who's also at QuestDB.

01:01:12
So hello, Steven,

01:01:14
and good to have you.

01:01:16
Thank you.

01:01:17
It's really a pleasure to be here,

01:01:19
and I'm looking

01:01:20
forward to our chat.

01:01:21
All right, cool.

01:01:22
So maybe just start

01:01:24
with a quick introduction.

01:01:26
I mean, we already know your name,

01:01:27
and I hope I

01:01:28
pronounced that correct.

01:01:29
But what else is

01:01:30
to talk about you?

01:01:32
Sure.

01:01:32
So I kind of have a

01:01:33
nontraditional background.

01:01:35
I started with a degree in

01:01:37
economics and finance

01:01:38
and worked on Wall

01:01:39
Street for a little bit.

01:01:40
I like to say in most of my

01:01:42
conference talks

01:01:43
on the first slide that my first

01:01:45
programming language was

01:01:46
actually Excel VBA, which I do

01:01:50
still have a soft spot for.

01:01:54
And I found myself

01:01:55
on a bond trading desk

01:01:58
and kind of reached

01:01:59
the boundaries of Excel

01:02:01
and started working in

01:02:02
C# and SQL Server,

01:02:04
realized I liked that a lot more

01:02:06
than just kind of talking

01:02:07
to people on the

01:02:08
phone and negotiating

01:02:09
over various

01:02:10
mortgage bonds and things.

01:02:12
So I moved into the IT realm and

01:02:16
software development

01:02:17
and been developing

01:02:19
software ever since.

01:02:20
So I moved on from C# into

01:02:24
the Python world,

01:02:26
moved on from finance

01:02:27
into the startup world,

01:02:28
and I currently am QuestDB, as you

01:02:31
mentioned earlier.

01:02:33
Right.

01:02:33
So maybe you can say a

01:02:35
few words about QuestDB.

01:02:37
What is it?

01:02:38
What does it do?

01:02:39
And why do people want to use it?

01:02:43
Sure.

01:02:44
QuestDB is a time

01:02:45
series database with a focus

01:02:47
on high performance.

01:02:48
And I like to think

01:02:50
ease of usability.

01:02:52
So we can ingest up to like

01:02:54
millions of rows per second

01:02:55
on some benchmarks,

01:02:56
which is just completely

01:02:59
mind-blowing to me.

01:03:01
It's actually

01:03:01
written primarily in Java,

01:03:04
which doesn't

01:03:05
necessarily go hand in hand with

01:03:06
high performance, but we've rewritten

01:03:09
most of the standard library to

01:03:11
avoid memory allocation.

01:03:13
So I know it actually truly is

01:03:14
high performance.

01:03:16
We've actually been

01:03:16
introducing Rust as well

01:03:18
into the code base.

01:03:20
You can query the

01:03:20
database using plain old SQL.

01:03:23
And it really fits

01:03:25
into several use cases,

01:03:28
like financial tick by tick data

01:03:30
and sensor data.

01:03:32
I have one going on

01:03:34
in my house right now,

01:03:35
collecting all of my smart home

01:03:36
stuff from Home Assistant.

01:03:40
And I mean, yes, I've been here

01:03:42
for around a year and a half,

01:03:45
I want to say.

01:03:46
And it's been a great ride.

01:03:48
Cool.

01:03:49
So you mentioned time series.

01:03:51
And I'm aware what time series are

01:03:53
because I've been at a

01:03:54
competitor before that.

01:03:57
So Jaromir and I, we did slightly

01:03:58
different directions,

01:04:00
but we both ended up in

01:04:01
the time series world.

01:04:02
But for the audience, that may not

01:04:05
be perfectly aware

01:04:06
what time series are.

01:04:07
You already

01:04:07
mentioned like tick data

01:04:09
from the financial background.

01:04:11
You also mentioned like Home

01:04:13
Assistant and IoT data,

01:04:15
which is great because I'm doing

01:04:16
the same thing for me.

01:04:18
It's most like energy

01:04:19
consumption and stuff.

01:04:21
But maybe you have

01:04:21
some more examples.

01:04:24
Sure.

01:04:25
Kind of a canonical one is

01:04:27
monitoring and metrics.

01:04:29
So any kind of data, I think that

01:04:32
has a time component.

01:04:34
Because it's-- and I think you

01:04:36
need a specialized database.

01:04:38
A lot of people ask, well, why not

01:04:39
just use Postgres

01:04:40
or any of the common databases?

01:04:44
And you could, but you're probably

01:04:46
not going to scale.

01:04:48
And you're going to hit a point

01:04:48
where your queries are just

01:04:51
not performing.

01:04:53
And time series

01:04:54
databases, in many cases,

01:04:56
ours in particular as

01:04:57
well, I can speak to,

01:04:59
is a columnar database.

01:05:01
So it stores data

01:05:01
in a different format

01:05:02
than you normally would see in a

01:05:05
traditional database.

01:05:07
And that makes querying and

01:05:09
actually ingesting data

01:05:12
from a wide range of

01:05:13
sources much more efficient.

01:05:16
And you kind of

01:05:17
like to think of it as,

01:05:18
I don't want to put myself on the

01:05:19
spot and do mental math.

01:05:21
But imagine if you

01:05:22
have 10 devices that

01:05:25
are sending information to your

01:05:26
database more than a second.

01:05:28
It's not that big of a deal.

01:05:30
But maybe, let's say,

01:05:31
you scale and you end up

01:05:33
with a million devices.

01:05:35
All of a sudden, you're dealing

01:05:36
with tremendous amounts of data

01:05:37
going into your database

01:05:38
that you need to manage.

01:05:40
And that's a

01:05:41
different problem, I think,

01:05:42
than your typical

01:05:43
relational database.

01:05:45
Right.

01:05:46
And I think you

01:05:47
brought up a good example.

01:05:48
Most of the time when

01:05:49
we talk about devices--

01:05:51
as I said, I'm coming from a kind

01:05:53
of similar background--

01:05:55
it's not like a device just sends

01:05:57
you a single data point.

01:05:58
When we talk about connected cars,

01:06:00
they actually send thousands to

01:06:04
100 of data,

01:06:07
position information,

01:06:10
all kinds of metrics

01:06:11
about the car

01:06:12
itself, the electronics,

01:06:14
and all that kind of stuff.

01:06:15
And that comes down to quite a

01:06:18
massive amount of data.

01:06:20
So yeah, I agree with you.

01:06:22
An actual time series

01:06:24
database is super important.

01:06:27
You mentioned columnar storage.

01:06:29
Maybe you can say a

01:06:31
few words about how

01:06:32
that is different from, I guess,

01:06:34
your Excel sheet.

01:06:36
[LAUGHTER]

01:06:38
Sure.

01:06:39
Well, I guess--

01:06:41
I don't know if I can

01:06:42
necessarily compare it

01:06:43
to my Excel

01:06:44
spreadsheet, since that's

01:06:45
its own weird XML

01:06:47
format, of course.

01:06:48
Right.

01:06:49
Fair.

01:06:50
But columnar data, I guess, in

01:06:52
different than, let's say,

01:06:54
tabular data in

01:06:55
your typical database

01:06:56
is tabular data is stored in

01:06:58
generally the table format,

01:07:00
where all of your columns and rows

01:07:04
are kind of stored

01:07:04
together versus

01:07:06
columnar in a data store,

01:07:07
each column is its

01:07:08
own separate file.

01:07:10
And that kind of makes

01:07:13
it more efficient when

01:07:14
you're working in

01:07:14
a time component,

01:07:17
because time is

01:07:18
generally your index.

01:07:20
You're not really indexing on a

01:07:22
lot of kind of like primary key

01:07:23
type things.

01:07:25
You're really just

01:07:26
mostly indexing on time,

01:07:27
like what happened

01:07:28
at this point in time

01:07:29
or over this time period.

01:07:32
Because of that, we're able to

01:07:34
optimize the storage model

01:07:36
to allow faster querying and also

01:07:39
ingestion as well.

01:07:41
And just for clarity,

01:07:42
I'm not a core developer.

01:07:44
I'm more of a cloud guy, so I hope

01:07:46
I got those details right.

01:07:48
I think you get the gist of it.

01:07:52
But for QuestDB,

01:07:54
that means it still

01:07:56
looks like a

01:07:56
tabular kind of database.

01:07:59
So you still have

01:08:00
your typical tables,

01:08:01
but the individual columns are

01:08:04
stored separately.

01:08:05
Is that correct?

01:08:06
Correct.

01:08:07
OK, cool.

01:08:09
So you said you're a cloud guy.

01:08:13
But as far as I know, you can

01:08:15
install QuestDB locally, on-prem.

01:08:18
You can install it into

01:08:19
your own private cloud.

01:08:20
I think there is

01:08:21
the QuestDB cloud,

01:08:23
which is the hosted platform.

01:08:24
Well, not I guess.

01:08:25
I know that it is.

01:08:27
So maybe what is

01:08:29
special about that?

01:08:30
Does it have special features?

01:08:32
Or is that mostly

01:08:34
about the convenience

01:08:35
of getting the managed database

01:08:37
and getting rid of all the work

01:08:39
you have to do when you run your

01:08:42
own database, which

01:08:43
can be complicated.

01:08:44
Absolutely.

01:08:46
So actually, both.

01:08:49
Obviously, you don't have to

01:08:50
manage it, and that's great.

01:08:51
You can leave it to the experts.

01:08:53
That's worth already the price of

01:08:55
admission, I think.

01:08:58
Additionally, we have the

01:08:59
enterprise, the QuestDB

01:09:00
enterprise, which has

01:09:02
additional features.

01:09:05
And all of those features, like

01:09:07
role-based authentication

01:09:09
and replication that's

01:09:11
coming soon and compression

01:09:14
of your data on disk,

01:09:16
those are all things

01:09:17
that you get

01:09:17
automatically through the cloud.

01:09:20
OK, so that means I have to buy

01:09:22
QuestDB enterprise

01:09:23
when I want to have

01:09:24
those features on prem,

01:09:25
but I get them on

01:09:26
the cloud right away.

01:09:28
Correct.

01:09:29
OK, cool.

01:09:31
And correct me if

01:09:32
I'm wrong, but I think

01:09:33
from a client perspective, it uses

01:09:35
the Postgres protocol.

01:09:37
So any Postgres client is a

01:09:40
QuestDB client, basically.

01:09:41
Absolutely, 100%.

01:09:43
All right, so that means as an

01:09:44
application developer,

01:09:45
it's super simple.

01:09:47
I'll basically drop in QuestDB

01:09:49
instead of Postgres

01:09:50
or anything else.

01:09:51
Cool.

01:09:52
So yeah, let's talk a little bit

01:09:54
about the cloud then.

01:09:56
Maybe you can elaborate a little

01:09:57
bit on the stack

01:09:58
you're running on.

01:09:59
I'm not sure how much

01:10:00
you can actually say,

01:10:01
but anything you can

01:10:02
share will probably

01:10:03
be beneficial to everyone.

01:10:06
Oh, yeah, no problem.

01:10:08
So we run on AWS.

01:10:10
We run on Kubernetes.

01:10:13
And we also-- I guess one thing

01:10:16
that I'm particularly proud of

01:10:17
is an operator that I

01:10:20
wrote to orchestrate

01:10:22
all these databases.

01:10:24
So our model, which is not

01:10:26
necessarily your bread

01:10:28
and butter Kubernetes deployment,

01:10:29
is actually a single-tenant model.

01:10:32
So we have one

01:10:32
database per instance.

01:10:35
And when you're

01:10:37
running Kubernetes,

01:10:37
you kind of think, why

01:10:38
do you care about what

01:10:40
nodes you're running on?

01:10:42
Shouldn't all that

01:10:42
be abstracted away?

01:10:44
And I would agree.

01:10:46
We primarily use Kubernetes for

01:10:48
its orchestration.

01:10:49
But we want to avoid the noisy

01:10:51
neighbor problem.

01:10:52
We want to make it easy for users

01:10:54
to change instances and

01:10:58
instance types quickly.

01:10:59
We want users to be able to shut

01:11:01
down their database.

01:11:01
And we still have the volume.

01:11:04
So all these things, we could

01:11:05
orchestrate them directly

01:11:06
through Kubernetes.

01:11:07
But we decided to use

01:11:10
single-tenant nodes for that.

01:11:13
Right, right.

01:11:14
So let me see.

01:11:17
So that means you're using

01:11:18
Kubernetes, as you said,

01:11:19
mostly for

01:11:20
orchestration, which means

01:11:22
it's more like if the database for

01:11:23
some reason goes down

01:11:24
or you have to have a maintenance

01:11:26
or you want to upgrade.

01:11:28
It's more about the convenience of

01:11:30
having something managing

01:11:32
that instead of

01:11:32
doing it manually, right?

01:11:34
Exactly.

01:11:36
And so I think we

01:11:39
really thought, OK--

01:11:41
and this is a little

01:11:42
bit before my time,

01:11:43
but you could always

01:11:47
roll your own cluster.

01:11:49
But there's so many things that

01:11:51
are baked into Kubernetes

01:11:52
these days, like monitoring and

01:11:55
logs and metrics

01:11:57
and networking and DNS and all

01:12:00
these things that don't

01:12:04
necessarily want to

01:12:05
spend all my time on.

01:12:07
I want to build a product.

01:12:09
And by using Kubernetes and

01:12:11
leveraging those components,

01:12:13
we were able to build the cloud

01:12:15
incredibly quickly,

01:12:17
get us up and

01:12:19
running, and then now

01:12:20
expand upon it in the future.

01:12:22
And that's why, again, I mentioned

01:12:24
the operator earlier.

01:12:25
That was not

01:12:26
originally part of the cloud.

01:12:28
The cloud still has in a more

01:12:31
limited capacity

01:12:32
what we call a provisioner.

01:12:34
So basically, if you're

01:12:37
interacting with the cloud

01:12:40
and you make a new database,

01:12:42
basically send a message

01:12:44
to a queue, and that

01:12:45
message will be picked up

01:12:46
by a provisioner.

01:12:47
And previously, that

01:12:48
provisioner would say, OK,

01:12:50
you want a database.

01:12:51
Let's make a stateful set.

01:12:53
Let's make a persistent volume.

01:12:55
Let's make these

01:12:55
networking policies.

01:12:57
Let's do all of these things.

01:12:59
If there's an

01:12:59
error, we can roll back.

01:13:01
And we have retries.

01:13:02
So it's fairly sophisticated.

01:13:06
But we ended up moving towards

01:13:08
this operator model, which

01:13:10
instead of the

01:13:11
provisioner managing

01:13:12
each of these

01:13:12
individual components,

01:13:15
it just manages

01:13:15
one QuestDB resource.

01:13:19
And our operator now handles all

01:13:21
of those other little things.

01:13:23
So I think that's

01:13:24
much more flexible for us

01:13:27
in terms of, A, simplifying the

01:13:29
provisioner code,

01:13:30
and also by adding new features

01:13:34
instead of having

01:13:35
to work in this

01:13:36
ever-growing web of Python.

01:13:41
Now, it's really just adding a

01:13:43
snippet here and there

01:13:46
to our reconciliation

01:13:47
inside of everything.

01:13:50
Right.

01:13:51
You mentioned that the database is

01:13:52
mostly written in Java.

01:13:53
Most operators are written in Go.

01:13:55
So what about your operator?

01:13:57
Is it Java?

01:14:00
It's Go.

01:14:01
It's Go.

01:14:02
That's fair.

01:14:03
To be honest, I think

01:14:03
the vast majority is.

01:14:07
So you mentioned AWS.

01:14:09
But I think that was you mostly

01:14:11
talking about QuestDB Cloud,

01:14:12
right?

01:14:14
I think from a user's perspective,

01:14:17
do I use a helm chart or do I also

01:14:19
use the operator

01:14:20
to install it myself?

01:14:22
Yes.

01:14:23
So the operator is actually only

01:14:24
limited to the cloud

01:14:26
because it's built

01:14:27
specifically to manage

01:14:28
our own infrastructure with our

01:14:30
own assumptions.

01:14:31
We do have a helm chart and an

01:14:33
open source image on Docker Hub.

01:14:36
So I've used that plenty of more

01:14:39
times than I can count.

01:14:41
Ok, fair enough.

01:14:42
So you basically support all

01:14:44
cloud environments,

01:14:44
all on-premise.

01:14:46
But when you go for QuestDB Cloud,

01:14:48
that is AWS, which I

01:14:49
think is a fair decision.

01:14:51
It is the biggest

01:14:52
environment by far.

01:14:56
So from a storage

01:14:58
engine perspective,

01:14:59
how much can you share?

01:15:02
Can you talk about

01:15:04
some fancy details?

01:15:07
Like what kind of

01:15:07
storage do you use?

01:15:08
Do you use the local NVMe storage

01:15:11
attached to the virtual machine

01:15:13
or EBS volumes?

01:15:15
Yeah.

01:15:16
So in our cloud, we have both

01:15:18
actually NVMe and EBS.

01:15:23
Most customers end up using EBS.

01:15:25
And honestly, EBS is

01:15:27
simpler to provision.

01:15:30
But I do want to actually talk

01:15:32
about some cool stuff

01:15:32
that we've done with compression.

01:15:36
Because we actually never

01:15:37
implemented our own compression

01:15:38
algorithm.

01:15:39
We're running on top of ZFS and

01:15:41
using their compression algorithm.

01:15:44
OK, yeah, cool.

01:15:45
Yes.

01:15:46
And we've actually-- there's an

01:15:48
issue about data corruption,

01:15:50
potentially, using

01:15:52
mmap on ZFS, or rather

01:15:55
a combination of mmap and

01:15:56
traditional sys calls,

01:15:58
the pwrite and preads.

01:16:00
And what we do is

01:16:01
actually identify

01:16:04
when we're running on ZFS and then

01:16:06
decide to only use mmap

01:16:08
calls to avoid this issue.

01:16:11
And I think what we've done is

01:16:14
pretty cool also

01:16:15
on the storage side of

01:16:16
orchestrating this whole thing.

01:16:18
Because ZFS has its

01:16:20
own notion of snapshots,

01:16:21
its own notion of replication, its

01:16:23
own notion of ZPools.

01:16:26
And to simplify

01:16:27
things, again, because we're

01:16:29
running this kind of--

01:16:31
I don't necessarily

01:16:31
want to say antiquated,

01:16:33
but we're running a

01:16:34
single-tenant model, which

01:16:35
might not be in vogue these days.

01:16:38
What we actually do is we create

01:16:39
one ZPool per volume

01:16:41
and throw our QuestDB on the

01:16:43
ZPool, enable compression.

01:16:45
And we've written our

01:16:46
own CSI storage driver

01:16:48
that sits in the middle of

01:16:50
Kubernetes and other cloud

01:16:52
providers so that we're able to

01:16:54
pass calls onto the cloud

01:16:56
providers if, let's say, we need

01:16:58
to create or delete

01:16:59
a volume using the

01:17:01
cloud provider API.

01:17:03
But when it comes to mounting

01:17:03
specific ZFS and running

01:17:06
ZFS-related commands, we actually

01:17:09
take control of that

01:17:10
and perform that

01:17:12
in our own driver.

01:17:14
I don't know when this

01:17:15
is going to be released,

01:17:15
but I'm actually talking about

01:17:17
this in Atlanta next week.

01:17:19
No.

01:17:21
Next week is a little bit early.

01:17:24
[LAUGHTER]

01:17:25
Currently, I'm doing a

01:17:27
couple of recordings,

01:17:29
building a little

01:17:29
bit of a pipeline.

01:17:30
Because of conferences, same thing

01:17:32
will be in Paris

01:17:34
for KubeCon next week.

01:17:37
So there is a little bit.

01:17:38
No, I don't know the exact date.

01:17:41
I think it's in

01:17:41
three or four weeks.

01:17:43
So it's a little bit out.

01:17:45
But I guess your

01:17:46
talk may be recorded.

01:17:48
And public by then.

01:17:50
So if that is the

01:17:51
case, I'm happy to--

01:17:52
if you drop it over and I put it

01:17:54
into the show notes,

01:17:55
people will love that.

01:17:57
So you said when you run on, or

01:18:00
when you detect that you run

01:18:01
on ZFS, you use mmap.

01:18:03
So you basically map

01:18:04
the file into memory.

01:18:06
And you change the memory

01:18:08
positions directly.

01:18:10
And then you fsync it.

01:18:11
Or how does it work?

01:18:12
How do I have to think about that?

01:18:14
Oh, boy.

01:18:15
OK.

01:18:16
This is getting a little out of my--

01:18:18
So you always use mmap regardless.

01:18:21
But the issue is when you combine

01:18:23
mmap with

01:18:24
traditional sys calls on ZFS.

01:18:27
And so what we do is we basically

01:18:30
turn off those other sys

01:18:32
calls and only use mmap

01:18:33
when we're writing to our files.

01:18:37
In terms of the specifics of when

01:18:39
we sync and things like that, I

01:18:40
wish I could answer it

01:18:42
right off of the bat.

01:18:44
That's totally fine.

01:18:46
So just to sneak in a little

01:18:50
shameless plug here,

01:18:54
we should totally

01:18:55
look into getting

01:18:57
QuestDB running on simplyblock.

01:18:59
I think that could be a really

01:19:00
interesting thing.

01:19:02
Because you mentioned ZFS, it's

01:19:04
basically ZFS on steroids.

01:19:07
[LAUGHTER]

01:19:07
If you want to call it that.

01:19:09
If you can put

01:19:11
something higher on ZFS,

01:19:15
it's a very, very high bar.

01:19:18
ZFS from my perspective, I mean,

01:19:20
I'm running a ZFS file

01:19:23
server in the basement.

01:19:24
It's saved me a couple of times

01:19:27
with broken hard disk.

01:19:29
It's just an

01:19:30
incredible piece of technology.

01:19:32
I agree with that.

01:19:33
And it's interesting because I've

01:19:35
seen a lot of people running

01:19:38
database on ZFS.

01:19:39
And ZFS is all about reliability.

01:19:41
It's not necessarily about the

01:19:43
highest performance.

01:19:44
So it's interesting you

01:19:45
choose ZFS and you say,

01:19:47
that's perfect and

01:19:48
works great for us.

01:19:52
So because we're

01:19:53
almost running out of time,

01:19:55
as I said earlier, 20

01:19:56
minutes is super short.

01:19:58
When you look at

01:20:00
cloud and databases

01:20:02
and the world as a whole, whatever

01:20:04
you want to talk about,

01:20:06
what do you think

01:20:06
is the next big trend

01:20:09
or the current big trend?

01:20:11
What is coming?

01:20:12
What do you think

01:20:12
would be really cool?

01:20:15
Yeah.

01:20:16
So I guess I'm not going to talk

01:20:18
about the existential crisis

01:20:20
I'm having with

01:20:21
Devin and the AI bots

01:20:23
because it's just a little

01:20:25
depressing for me right now.

01:20:27
But I think one thing that I've

01:20:30
been seeing over the past few

01:20:31
years that I find very interesting

01:20:35
is this move away from cloud and

01:20:37
back into your own data

01:20:39
center.

01:20:40
I think having

01:20:41
control over your data

01:20:43
is something that's incredibly

01:20:45
important to basically everyone

01:20:48
now.

01:20:49
And I think it's to find a happy

01:20:52
medium as a DevOps

01:20:54
engineer between all

01:20:57
the wonderful cloud APIs

01:21:00
that you can use and

01:21:01
going in the server room

01:21:04
and kind of hooking things up.

01:21:07
There's probably a

01:21:07
happy medium there somewhere

01:21:08
that I think is an

01:21:10
area that is going to start

01:21:12
growing in the future.

01:21:14
You see a lot of on-prem

01:21:16
Kubernetes type things,

01:21:17
Kubernetes on edge maybe.

01:21:20
And for me, it presents a lot of

01:21:23
interesting challenges

01:21:24
because I spent most

01:21:28
of my career in startups

01:21:30
working on the

01:21:31
cloud and understanding

01:21:32
the fundamentals of

01:21:34
not just the cloud APIs

01:21:36
but operating systems

01:21:38
and hardware a little bit.

01:21:40
And so kind of figuring out where

01:21:44
to draw that line in terms of what

01:21:48
knowledge is transferable

01:21:49
to this new paradigm

01:21:51
will be interesting.

01:21:53
And I think that's a

01:21:55
new trend that I've

01:21:56
been focused on at least over the

01:21:58
past couple of months.

01:21:59
That is interesting that you

01:22:01
mentioned that because it

01:22:03
is kind of that.

01:22:05
When cloud became

01:22:06
big, everyone wanted

01:22:07
to move to the cloud because it

01:22:08
was like "cheaper" in air quotes.

01:22:12
And I think-- well, the

01:22:13
next step was serverless

01:22:15
because it is yet even

01:22:17
cheaper, which we all

01:22:18
know is not necessarily true.

01:22:21
And I see kind of the same thing.

01:22:24
Now people realize that not every

01:22:27
workload actually works

01:22:29
perfectly or is a

01:22:30
great fit for the cloud

01:22:31
and people slowly

01:22:33
start moving back

01:22:34
or at least going back to not

01:22:37
necessarily cloud instance

01:22:39
but co-located

01:22:42
servers or virtual machines,

01:22:44
like plain virtual machines and

01:22:46
just taking those

01:22:47
for the workloads that do not need

01:22:50
to be super scalable

01:22:53
or super elastic.

01:22:55
Well, thank you very much.

01:22:57
That was very delightful.

01:23:00
It was a pleasure having you.

01:23:02
Thank you.

01:23:03
Oh, yeah, I

01:23:04
enjoyed the conversation.

01:23:05
It was great.

01:23:06
Thank you very much.

01:23:07
I do my best.

01:23:11
No, it was-- as I

01:23:11
said, it was really good.

01:23:13
Thank you for being

01:23:14
here and for the audience.

01:23:16
I hope to--

01:23:18
well, not see you, but hear you

01:23:19
next time, next week.

01:23:22
Thank you very much.

01:23:23
Thank you.

01:23:24
Take care.

01:23:26
The cloud commute podcast is sponsored by

01:23:28
simplyblock your own elastic

01:23:29
block storage engine for the cloud.

01:23:31
Get higher IOPS and low predictable

01:23:33
latency while bringing down your

01:23:35
total cost of ownership.

01:23:36
www.simplyblock.io