(bright music)
>> Narrator: The Cube, presents Kubecon and Cloudnativecon,
year of 2022,
brought to you by Red Hat,
the cloud native computing foundation
and its ecosystem partners.
>> Now what we're opening.
Welcome to Valencia, Spain
in Kubecon
Cloudnativecon, Europe,
2022.
I'm Keith Townsend, along with my host, Paul Gillin,
who is the senior editor for architecture
at Silicon angle, Paul.
>> Keith you've been asking me questions
all these last two days.
Let me ask you one.
You're a traveling man.
You go to a lot of conferences.
What's different about this one.
>> You know what,
we're just talking about that pre-conference,
open source conferences are usually pretty intimate.
This is big.
7,500 people
talking about complex topics,
all in one big area.
And then it's,
I got to say it's overwhelming.
It's way more.
It's not focused on a single company's product or messaging.
It is about a whole ecosystem,
very different show.
>> And certainly some of the best t-shirts I've ever seen.
And our first guest, Jim
has one of the better ones.
>> I mean a bit cockroach come on, right.
>> Jim Walker, principal product evangelist at CockroachDB
and Christian Huning,
tech director of cloud technologies
at Finleap Connect, a financial services company
that's based out of Germany,
now offering services in four countries now.
>> Basically all over Europe.
>> Okay.
>> But we are in three countries with offices.
>> So you're CockroachDB customer
and I got to ask the obvious question.
Databases are hard
and started the company in 2015 CockroachDB,
been a customer since 2019, I understand.
Why take the risk on a four year old database.
I mean that just sounds like a world of risk and trouble.
>> So it was in 2018 when we joined the company back then
and we did this cloud native transformation,
that was our task basically.
We had very limited amount of time
and we were faced with a legacy infrastructure
and we needed something that would run in a cloud native way
and just blend in with everything else we had.
And the idea was to go all in with Kubernetes.
Though early days, a lot of things were alpha better,
and we were running on my sequel back then.
>> Yeah.
>> On a VM, kind of small setup.
And then we were looking for something that
we could just deploy in Kubernetes,
alongside with everything else.
And we had to stack
and we had to duplicate it many times.
So also to maintain that we wanted to do it all the same
like with skid ops and everything
and Cockroach delivered that proposition.
So that was why we evaluate the risk
of relatively early adopting
that solution with the proposition
of having something that's truly cloud native
and really blends in with everything else we do
in the same way
was something we considered,
and then we jumped the leap of faith and
>> The fin leap of faith
>> The fin leap of faith.
Exactly.
And we were not dissatisfied.
>> So talk to me a little bit about the challenges
because when we think of MySQL,
MySQL scales to amazing sizes,
it is the de facto database
for many cloud based architectures.
What problems were you running into with MySQL?
>> We were running into the problem that we essentially,
as a finTech company,
we are regulated
and we have companies, customers
that really value running things
like on-prem, private cloud,
on-prem is a bit of a bad word, maybe.
So it's private cloud, hybrid cloud, private cloud
in our own data centers in Frankfurt.
And we needed to run it in there.
So we wanted to somehow manage that and with,
so all of the managed solution were off the table,
so we couldn't use them.
So we needed something that ran in Kubernetes
because we only wanted to maintain Kubernetes.
We're a small team,
didn't want to use also like full blown VM solution,
of sorts.
So that was that.
And the other thing was,
we needed something that was HA distributable somehow.
So we also looked into other solutions back at the time,
like Vitis, which is also prominent
for having a MySQL compliant interface
and great solution.
We also got into work, but we figured,
this is from the scale,
and from the sheer amount of maintenance it would need,
we couldn't deliver that,
we were too small for that.
So that's where then Cockroach just fitted in nicely
by being able to distribute BHA,
be resilient against failure,
but also be able to scale out
because we had this problem
with a single MySQL deployment to not really,
as it grew, as the data amounts grew,
we had trouble to operatively keep that under control.
>> So Jim,
every time someone comes to me and says,
I have a new database,
I think we don't need it,
yet another database.
>> Right.
>> What problem,
or how does CockroachDB go about solving
the types of problems that Christian had?
>> Yeah. I mean, Christian laid out why it exists.
I mean, look guys, building a database isn't easy.
If it was easy,
we'd have a database for every application,
but you know,
Michael Stonebraker, kind of godfather of all database
says it himself,
it takes seven, eight years for a database
to fully gestate to be something
that's like enterprise ready
and kind of, be relied upon.
We've been billing for about seven, eight years.
I mean, I'm thankful for people like Christian
to join us early on
to help us kind of like troubleshoot
and go through some things.
We're building a database,
it's not easy.
You're right.
But building a distributor system is also not easy.
And so for us,
if you look at what's going on
in just infrastructure in general,
what's happening in Kubernetes,
like this whole space is Kubernetes.
It's all about automation.
How do I automate scale?
How do I automate resilience out of the entire equation
of what we're actually doing?
I don't want to have to think about active passive systems.
I don't want to think about sharding a database.
Sure you can scale MySQL.
You know, how many people it takes to run
three or four shards of MySQL database.
That's not automation.
And I tell you what,
this world right now
with the advances in data
how hard it is to find people
who actually understand infrastructure to hire them.
This is why this automation is happening,
because our systems are more complex.
So we started from the very beginning to be something
that was very different.
This is a cloud native database.
This is built with the same exact principles
that are in Kubernetes.
In fact, like Kubernetes it's kind of a spawn of borg,
the back end of Google.
We are inspired by Spanner.
I mean, this started by three engineers
that worked at Google,
are frustrated, they didn't have the tools,
they had at Google.
So they built something that was,
outside of Google.
And how do we give that kind of Google like infrastructure
for everybody.
And that's, the advent of Cockroach
and kind of why we're doing, what we're doing.
>> As your database has matured,
you're now beginning a transition
or you're in a transition to a serverless version.
How are you doing that without disrupting the experience
for existing customers?
And why go serverless at all?
>> Yeah, it's interesting.
So, you know, serverless was,
it was kind of a an R&D project for us.
And when we first started on a path,
because I think you know,
ultimately what we would love to do for the database
is let's not even think about database, Keith.
Like, I don't want to think about the database.
What we're building too is,
we want a SQL API in the cloud.
That's it.
I don't want to think about scale.
I don't want to think about upgrades.
I literally like. that stuff should just go away.
That's what we need, right.
As developers, I don't want to think about isolation levels
or like, you know, give me DML
and I want to be able to communicate.
And for us the realization of that vision is like,
if we're going to put a database on the planet for everybody
to actually use it,
we have to be really, really efficient.
And serverless,
which I believe really should be infrastructure less
because I don't think we should be thinking
of just about service.
We got to think about,
how do I take the context of regions out of this thing?
How do I take the context of cloud providers
out of what we're talking about?
Let's just not think about that.
Let's just code against something.
Serverless was the answer.
Now we've been building for about a year and a half.
We launched a serverless version of Cockroach last October
and we did it so that everybody in the public
could have a free version of a database.
And that's what serverless allows us to do.
It's all consumption based up to certain limits
and then you pay.
But I think ultimately,
and we spoke a little bit about this at the very beginning.
I think as ISVs, people who are building software today
the serverless vision gets really interesting
because I think what's on the mind of the CTO is,
how do I drive down my cost to the cloud provider?
And if we can basically, drive down costs
through either making things multi-tenant
and super efficient,
and then optimizing how much compute we use,
spinning things down to zero and back up and auto scaling
these sort of things in our software.
We can start to make changes in the way
that people are thinking about spend
with the cloud provider.
And ultimately we did that, so we could do things for free.
>> So, Jim, I think I disagree Christian,
I'm sorry, Jim.
I think I disagree with you just a little bit.
Christian, I think the biggest challenge facing CTOs
are people.
>> True. >> Getting the people to worry
about cost and spend and implementation.
So as you hear the concepts of CoachDB moving
to a serverless model,
and you're a large customer
how does that make you think
or react to your people side
of your resources?
>> Well, I can say that from the people side of resources
luckily Cockroach is our least problem.
So it just kind of,
we always said, it's an operator stream
because that was the part that just worked for us, so.
>> And it's worked as you have scaled it?
without you having ...
>> Yeah. I mean, we use it in a bit of a,
we do not really scale out like the Cockroach,
like really large.
It's like, more that we use it with the enterprise features
of encryption in the stack
and our customers then demand.
If they do so,
we have the Zas offering
and we also do like dedicated stacks.
So by having a fully cloud native solution
on top of Kubernetes, as the foundational layer
we can just use that
and stamp it out and deploy it.
>> How does that translate into services you can provide
your customers?
Are there services you can provide customers
that you couldn't have,
if you were running, say, MySQL?
>> No, what we do is,
we run this,
so the SAS offering runs in our hybrid private cloud.
And the other thing that we offer is that
we run the entire stack at a cloud provider
of their choosing.
So if they are an AWS, they give us an AWS account,
we put it in there.
Theoretically, we could then also talk about
using the serverless variant, if they like so,
but it's not strictly required for us.
>> So Christian, talk to me about that provisioning process
because if I had a MySQL deployment before
I can imagine how putting that
into a cloud native type of repeatable
CICD pipeline or Ansible script
that could be difficult.
Talk to me about that.
How CockroachDB enables you to create
new onboarding experiences for your customers?
>> So what we do is,
we use helm charts all over the place
as probably everybody else.
And then each application team has their parts of services,
they've packaged them to helm charts,
they've wrapped us in a super chart
that gets wrapped into the super, super chart
for the entire stack.
And then at the right place,
somewhere in between Cockroach is added,
where it's a dependency.
And as they just offer a helm chart
that's as easy as it gets.
And then what the teams do is
they have an inner job,
that once you deploy all that, it would spin up.
And as soon as Cockroach is ready
it's just the same reconcile loop as everything.
It will then provision users,
set up database schema,
do all that.
And initialize, initial data sets
that might be required for a new setup.
So with that setup,
we can spin up a new cluster
and then deploy that stack chart in there.
And it takes some time.
And then it's done.
>> So talk to me about life cycle management.
Because when I have one database, I have one schema.
When I have a lot of databases
I have a lot of different schemas.
How do you keep your stack consistent across customers?
>> That is basically part of the same story.
We have get offs all over the place.
So we have this repository,
we see the super helm chart versions
and we maintain like minus three versions
and ensure that we update the customers
and keep them up to date.
It's part of the contract sometimes,
down to the schedule of the customer at times.
And Cockroach nicely supports also,
these updates with these migrations in the background,
the schema migrations in the background.
So we use in our case,
in that integration SQL alchemy,
which is also nicely supported.
So there was also part of the story
from MySQL to Postgres,
was supported by the ORM, these kind of things.
So the skill approach together with the ease of helm charts
and the background migrations of the schema
is a very seamless upgrade operations.
Before that we had to have downtime.
>> That's right, you could have online schema changes.
Upgrading the database uses the same concept
of rolling upgrades that you have in Kubernetes.
It's just cloud native.
It just fits that same context, I think.
>> Christian: It became a no-brainer.
>> Yeah. >> Yeah.
>> Jim, you mentioned the idea of a SQL API in the cloud,
that's really interesting.
Why does such a thing not exist?
>> Because it's really difficult to build.
You know, SQL API, what does that mean?
Like, okay.
What I'm going to,
where does that endpoint live?
Is there one in California
one on the east coast, one in Europe, one in Asia?
Okay. And I'm asking that endpoint for data.
Where does that data live?
Can you control where data lives on the planet?
Because ultimately what we're fighting in software today
in a lot of these situations is the speed of light.
And so how do you intelligently place data on this planet?
So that, you know,
when you're asking for data,
when you're maybe home,
it's a different latency
than when you're here in Valencia.
Does that data follow and move you?
These are really, really difficult problems to solve.
And I think that we're at that layer of,
we're at this moment in time in software engineering,
we're solving some really interesting, interesting things
cause we are budding against this speed of light problem.
And ultimately that's one of the biggest challenges.
But underneath, it has to have all this automation
like the ease at which we can scale this database
like the always on resilient,
the way that we can upgrade the entire thing
with just rolling upgrades.
The cloud native concepts is really what's enabling us
to do things at global scale it's automation.
>> Let's alk about that speed of light in global scale.
There's no better conference for speed of light, for scale,
than Kubecon.
Any predictions coming out of the show?
>> It's less a prediction for me
and more of an observation, you guys.
Like look at two years ago,
when we were here in Barcelona at QCon EU,
it was a lot of hype.
It's a lot of hype,
a lot of people walking around,
curious, fascinated,
this is reality.
The conversations that I'm having with people today,
there's a reality.
There's people really doing,
they're becoming cloud native.
And to me,
I think what we're going to see over the next
two to three years is
people start to adopt this kind of distributed mindset.
And it permeates not just within infrastructure
but it goes up into the stack.
We'll start to see much more developers using, Go
and these kind of the threaded languages,
because I think that distributed mindset,
if it starts at the chip
all the way to the fingertip of the person clicking
and you're distributed everywhere in between.
It is extremely powerful.
And I think that's what Finleap,
I mean, that's exactly what the team is doing.
And I think there's a lot of value
and a lot of power in that.
>> Jim, Christian, thank you so much for coming on the Cube
and sharing your story.
You know what we're past the hype cycle of Kubernetes,
I agree.
I was a nonbeliever in Kubernetes two, three years ago.
It was mostly hype.
We're looking at customers from Microsoft,
Finleap
and competitors doing amazing things with this platform
and cloud native in general.
Stay tuned for more coverage of Kubecon
from Valencia, Spain.
I'm Keith Townsend,
along with Paul Gillin
and you're watching the Cube,
the leader in high tech coverage.
(bright music)