>> Narrator: theCUBE presents KubeCon,
and CloudNativeCon Europe, 2022
brought to you by Red Hat
the Cloud Native Computing Foundation
and its ecosystem partners.
>> Welcome to Valencia, Spain
a KubeCon CloudNativeCon Europe, 2022.
I'm your host, Keith Townsend
along with Paul Guillen senior editor,
enterprise architecture for Silicon Angle.
Paul, we're going to talk to some amazing people this week.
KubeCon, what the energy here,
what would you say about it?
>> I'd say it's reminiscent of the early year,
early stage conferences I've seen with other technologies.
There is a lot of startup activity here,
there's a lot of money in the market
despite the selloff in the stock market lately,
a lot of anticipation that there could be big exits,
there could be big things ahead for these companies,
you don't see that when you go
to the big established conferences
you see just anticipation here
that I don't think you see,
you'll see maybe in a couple of years,
so it's fun to be here right now.
I'm sure it'll be a very different experience
in two or three years.
>> So welcome to our guest Cubila, Bassam Tabbara
the founder and CEO of Upbound, welcome back.
>> Thank you, yeah, pleasure to be on the show again.
>> So Paul, tell us,
we're in this phase of migrations
and moving to cloud native stacks.
Are we another re-platforming generation?
I mean, we've done, the enterprise has done this
you know, time, time again,
and whether it's from Java to .net or .net to Java
or from bare metal to VMs
but are we in another age of re-platforming?
>> You know, it's interesting,
every company has now become a tech company
and every tech company needs to build a very model
you know, modern digital platform
for them to actually run their business.
And if they don't do that
then they'll probably be out of business.
And it is interesting to think about
how companies are platforming and re-platforming.
Like, you know, as you said just
a few years back, you know
we were on people using Cloud Foundry or using Heroku
you hear Heroku a lot or,
you know now it's Cloud Native and Kubernetes
and it it begs the question, you know, is this the end?
That to your point, is this, you know
do we have a, you know, what makes us sure
that this is the, you know, the last platform
or the future proof platform that, that people are building.
>> There's never a last platform, right,
there's always something around the core.
The question is, is Kubernetes Linux, or is it windows?
>> That, that's a good question,
it's more like Linux I think,
you know, you've heard this before
but people talk about Kubernetes as a platform
off platforms, you can use it to build other platforms.
And if you know what you're doing,
you can probably assemble a set of pieces around it
and arrive at something that looks
and can work for your business.
But it requires a ton of talent,
it requires a lot of people that actually can act,
you know know how to put this stick together
to work for your business as it is,
there's not a lot of guidance.
I mean, were, I think we were chatting earlier
about the CSCF landscape
and how there are all these different projects
and companies around it, but they don't come together
in meaningful ways that they act,
the enterprise itself has to figure out
how to bring them together.
Right, and that's the combination
of what they do there organically
or not is their platform, right.
And that changes, it can change over time.
>> Do you think they really do,
they really want to put these things together?
I mean that's not what enterprise is like to do,
they want to find someone who's going to come in
and turnkey do it all for them.
>> Bassam: Yeah and if there were,
this is the things like every week now,
you hear about another platform that says,
this is the new Heroku.
this is the new Cloud Foundry,
this replaces every, you know, some vendor has
and you can see them all around here.
You know, companies that are basically
selling platform solutions that do put them together.
And the problem with it is that you typically outgrow these,
like you are it might solve 80%
of the use cases you care about
but the other 20% are not represented.
And so you end up outgrowing the platform itself, right.
And the choice has been mostly around,
you know do you buy something off the shelf
that solves 80% of your use cases?
Or do you build something on your own?
And then you have to spend all your resources actually,
going through and building all of it.
And that's been the dilemma,
you know, people here talk about this
as a platform dilemma,
but it's been the way for a long time.
Like we go through this cycle every few years
and you know people end up essentially oscillating
between buying something off the,
you know that's off the shelf or building it themselves.
>> So what's the payoff,
if I'm a CIO and I'm looking at the landscape
I don't need to understand,
you know, I don't know what a pod is,
to know that looking at 200 plus projects
in Cloud Native Foundation
and the bevy of of co-located projects
and conferences before they
even the start of this, what's the payoff?
>> Increasing the pace of innovation.
I mean, that literally is when we talk to customers
they all say roughly the same thing.
They want something that works for their business,
they want something that helps them take their,
you know line of business applications to production
in a much quicker way, lets them innovate,
lets them create higher engineers
that don't have to understand everything about every system
but can actually specialize and focus on the
the parts that they sh they care about.
But it's all in the context of,
you know people want to be able to innovate
at a very high pace, otherwise they get disrupted.
>> So I was at the, you know
my favorite part of KubeCon in general
is the hallway track
and talking to people on the ground, doing cool things.
I was talking to a engineer who was able
to take their Java stack,
their net stack and start to create APIs
between and break 'em into microservices,
Now teams are working across from one another
realizing that promise of innovation,
but that was the end point they're there.
>> Bassam: Yeah.
>> As companies are thinking about re-platforming,
where do we start?
I mean, I'm looking at the CNCF,
the map and it's 200 plus projects, where do I start?
>> Do you typically today start with Kubernetes,
and a lot of companies have now deployed Kubernetes
to production as a container orchestrator
whether they're going through a vendor or not
but now you are seeing all the things around it
whether it's CICD
or GitOps that they're looking at, you know
or the starting to build consoles around,
you know, their platforms
or looking at managing more than just containers.
And that's a theme that, you know
we're seeing a lot now,
people want to actually bring this modern stack
to manage not just container workloads,
but start looking at databases and cloud workloads
and everything else that they're doing around it.
Honestly, everybody's trying to do the same thing,
they're trying to arrive at a single point of control
a single, you know, a platform that can do it all,
that they can centralize policy centralized controls
to compliance governance, cost controls
and then expose a self-service experience to developers.
Like they're all trying to build
what we probably call an internal cloud platform.
They don't know,
they talk about it in different ways,
but almost everyone is trying
to build some internal platform
that sits on top of on-premises,
and on top of cloud, depending on their scenarios
>> You make an interesting point
which is that everyone here is
to some extent trying to do the same thing.
And there's fine points of granularity
between now they're approaching it
as you walk around this floor,
do you understand what all of these companies are doing?
>> I'm not sure I understand all of them,
but I do recognize a lot of them, yes.
>> And in terms of your approach,
you use the term control plane.
What is distinctive about your approach?
>> Very good question, so, you know, we end up bound,
we're trying to solve this problem as well,
we're trying to help people build their own platforms
but you know, there's a lot to it,
so let me actually step back,
and talk about the architecture of this.
But if were to look at any cloud platform
let's take the largest one AWS,
if you peek behind the scenes at AWS,
you know it's basically a set of independent services
EC2, S3, databases, et cetera,
that are, you know essentially working on different parts
of, you know like offer completely different pricing
different services, et cetera.
They come together
because they all integrate into a control plane.
It's the thing that serves an API,
it's the thing that gives it all a common feel.
It's where you do access control,
it's where you do billing, metering,
cost control policy, et cetera, right.
And so our realization was if the enterprises
are platforming and re-platforming,
why shouldn't they build their platform
in the same way that the cloud vendors build theirs?
And so we started this project
almost four years ago now three and a 1/2 years,
called cross plane,
which is a essentially an open source control plane
that can become the integration point for all services.
And essentially gives you a universal control plane
for cloud.
>> So you mentioned the idea
of orchestrating or managing stuff other than containers.
As I think about companies that built amazing platforms,
enterprise companies, building amazing applications
on AWS 10 years ago
and they're adopting the AWS control plane.
And now I'm looking at Kubernetes,
is Kubernetes, the way to multi-cloud,
to be able to control those discrete services in a AWS
or a Google cloud, Azure or Oracle Cloud, is that true?
>> We kind of have to tease it parts,
so there are really two parts
to Kubernetes and everybody thinks of Kubernetes
as a container orchestration platform, right,
and you know, there is a sense
that people say if I was to run Kubernetes
on everywhere and can build everything on top of containers
that I get some kind of portability across clouds.
>> Keith: You're right.
>> That I can put things in containers,
and then they magically run,
you know in different environments.
In reality what we've seen is
not everything fits in containers.
It's not going to be, the world is not going to look
like containers on the bottom, everything else is on top.
Instead, what we're going to see is essentially
a set of services that people are using
across the different vendors.
So if you look at like, you could be at AWS shop primarily
but I bet you're using Confluent or Elastic
or Data Breaks or Snowflake or Mongo or other services.
I bet you're using things that are on premises, right,
and so when you look at that
and you say to build my platform as an enterprise,
I have to consume services from multiple vendors.
Even if it's just one major cloud vendor
but I'm consuming services from others.
How do I bring them together
in meaningful ways so that I can,
you know build my platform on top of
the collection of them and offer something
that my developers can consume and self-service on.
That's not just containers.
What's interesting though, is if you look at Kubernetes
and you know, look inside it,
Kubernetes built a control plane,
that's actually quite useful
and applicable outside of container scenarios.
So this whole notion of CRDs and controllers
if you've heard that term, the ability,
you know like there are two parts to Kubernetes
there is a control plane
and then there's the container workloads.
And the control plane is generic,
it could be used literally across,
you know, you can use it to manage things
that are completely outside of container workloads.
And that's what we did with cross mind,
we took the control plane of Kubernetes
and then built bindings providers
that connected to AWS, to Google, to Azure, to DigitalOcean
to all these different environments.
So you can bring the way of managing,
you know, the style of managing that Kubernetes invented
to more than just containers.
You can now manage cloud services, using the same approach
that you are now using with Kubernetes
and using the entire ecosystem of tooling around it.
>> Enterprises have been
under pressure to re-platform for a long time.
It was first go to Unix then
to Linux and virtualize then to move to the cloud,
now, Kubernetes, do you think that this is
the stack that enterprises can finally commit to?
>> I think if you take the orientation
of your deploying a control plane within your enterprise
that is extensible, that enables you to actually connect it
to all the things that are under your domain
that that actually can be a future-proof way
of doing a platform.
And, you know, if you look at the largest cloud platforms
AWS has been around for at least 15 years now
and they really haven't changed the architecture
of AWS significantly.
It's still a control plane
a set of control planes that are managing services.
>> Paul: It's a legacy
>> They've added a lot of services,
they've have a ton of diversity.
They've added so many different things
but the architecture is still a hub and spoke
that they built, right.
And if the enterprise can take the same orientation
put a control plane, let it manage all the things
that are you know, about today,
arrive at a single point of control
have a single point where you can enforce policy,
compliance, cost, controls, et cetera
and then expose a self-service experience
to your developers that actually can become future proof.
>> So we've heard this promise before
the cloud of clouds, basically.
>> Yes.
>> To be able to manage everything,
what we find is the devils in the details.
The being able to say, you know,
a load balancer issuing a command
to deploy a load balancer in AWS is different
than it is in Azure, which is different than it is in GCP.
How do enterprises know
that we can talk to a single control plane to do that?
I mean, that just seems extremely difficult to manage.
>> Oh yeah, the approach is not,
you're not trying to create a lowest common denominator
between clouds, that's a really, really hard problem.
And in fact, you get relegated to just using this,
you know really shallow features of each,
if you're if you're going to do that,
like your, your example of load balancers,
load balancers look completely different
between cloud vendors.
The approach that we kind of advocate
for is that you shouldn't think of them as,
you shouldn't try to unify them in a way that makes them,
you know, there's a global abstraction that says,
oh there's a load balancer
and it somehow magically works across
the different cloud vendors.
I think that's a really, really hard thing
to do as you point out.
However, if you bring them all under a same control plane,
as different as they are, you're able to now apply policies,
you're able to set cost controls.
You're able to expose a self-service experience
on top of them even if they are very different.
And that's, that's something that I think is,
you know been hard to do in the past.
>> So Bassam, we'll love to dig deeper
into this in future segments,
and I'm going to take a look at the product and project
and see where you folks land in this conversation.
From Valencia, Spain,
I'm Keith Townsend along with Paul Guillen
and you're watching theCUBE,
the leader in high tech coverage.
(soft upbeat music)