(ethereal music)
- Clayton, in the aftermath of
KubeCon + CloudNativeCon Europe,
there's been a lot of development
so I'm looking forward to have the opportunity
to talk through some of the developments with you.
- It's a pleasure to talk to you as well,
it's been interesting going through the lifecycle of
Kubernetes from the very earliest,
I was one of the early contributors to Kubernetes,
and there was a lot of excitement as you capitalize on
containers and containers themselves were really exciting
because they're just way faster than VMs.
And really that's all that mattered to that early crowd.
And you went through this cycle of,
"what are the patterns and principles
that we wanna build on?"
One of the really interesting things,
there's always been a strong thread to,
as people make more bets on Kubernetes
as more vendors get involved as people
pivot their strategies, or the kind of,
it becomes a question that you could ask, well,
what is your container strategy?
Or how are you approaching Hybrid Cloud?
Or how are you gonna deal with multi-Cloud?
It's been interesting how some of these themes have really
emerged of you can't overlook the little details.
You have to stay really focused on
what you're getting out of Kubernetes.
And I think the most successful organizations I've seen,
whether they were big complex tech companies
getting on really early,
or whether they're maybe more conservative
organizations that are still trying to do big consolidation,
they've all had that theme
of if the ecosystem isn't there yet, you still have to,
you have to have a technology approach that can,
solve that problem for you and I've really,
I've noticed that that same principle I think,
is that it's getting to a point where most of the options
and most of the things that we need
can still be found and integrated.
And the question is, are you ready for that transition?
Are you ready to do that integration yourself?
Do you have the right skills to make that possible?
- I heard an interview with Joe Beda,
one of the founders, of course, of Kubernetes
saying that this was by design.
We want it to be as minimal as possible.
And one of the core of what we needed to be done
to prove out the capability of the
technology with the expectation
that the community was going to provide this over time.
And it seems to me,
where we are on a scale of one to 10, it's hard to say,
if we crossed the halfway mark, it's hard to say,
but I believe that enterprises that are eager
to take advantage of some of this new technology,
I'm hearing them start to adopt,
starting to move towards production.
And they're coming up on these various considerations
that mainstream applications require,
these storage data, recovery resiliency, and so forth.
The ability to stand up to audit
security seems to be other critical capabilities
that Kubernetes, however its consumed
is gonna have to provide.
- And it's an interesting way of describing it
cause a lot of the early mindset was,
understanding what is achievable
and what a community can achieve,
what an ecosystem needs to achieve.
And Kubernetes was very minimal
and still is today in a sense,
it's a place where those abstractions
can sort themselves out, but someone has to commit to it.
And I think this is really the role of over time
increasingly there's a lot of things in the stack
that aren't Kubernetes that have to work well together.
There's a lot of,
I think implicit standardization,
people who use Kubernetes provides
and in my experience,
it really is up to the distributions and the vendors
to try to find some set of technology that works
that's supportable over the long run.
One of the things that I wanna see
Kubernetes as an ecosystem do,
is I wanna see more opportunities for standardization
to fill in those gaps and for people to be able to have that
expectation that, yeah, it works consistently,
today that tends to be a one or two
vendor kind of approach.
And there's definitely a lot more that could be done.
And I think most people have an incentive to see that happen
because for every step,
for every organization working with a vendor on Kubernetes,
plus what's surrounded, there are tens or,
hundreds is maybe an exaggeration,
of people who are building it themselves
and are gonna get burned at some point,
whether that's lifecycle skills
or the stuff we mentioned before,
the realities of change in an open ecosystem
are there's a lot of pace that you have to keep up with
and it's easy to fall behind.
- Even the most users of Kubernetes supporters
would acknowledge that it is complex.
The counter is, is that it's worth it.
That the dynamism that comes with this way of working
this organization, it harmonizes mainstream IT
with the scale and productivity has continued
with their Cloud providers for some time.
That seems true at the highest level,
but there's still going to be a gap between
acknowledging that and making that actually
operational in real time.
You've got corporations today that still are running very
important CICS systems from IBM, transactional applications.
You've got people running networks
that are not easily adapted to the Cloud
in any kind of scalable way.
You've got people with a substantial
ERP type implementations
which don't seem to be moving anytime soon.
So I think really the challenge for the Kubernetes community
is to find a way to have something meaningful
to say across this and say,
whether it's going to be addressed in the near term
or whether it's gonna be addressed over time,
what is the story about how to get there?
Because I think it's easy for people to kind of squint
and see five years down the line,
you can see what the transformation might look like,
but the navigating from here to there is quite complex.
- One of the interesting things
that I think led to Kubernetes was, in the early,
in the mid 2000s leading into the first half of the 2010s,
that effort around platform as a service,
looking to standardize application deployment,
application rollout, application life cycle,
many organizations,
many of the large successful organizations
had approaches already to deal with some of this,
whether that's large scale Linux,
the technology has been around for a while
LDAP and Kerberos provided
standard workload identity across big fleets.
I feel it was all the Kubernetes
is kind of in the Goldilocks zone,
which is, it's neither too hot nor too cold,
it's neither too big nor too small.
Everybody can look at it and see a big chunk of wind
and just having one or a few approaches
really is what that's the,
it doesn't have to be the best technology.
It just has to be a technology
that everybody works together on
which, like Linux, smooths out that,
you can find a big pool of people who are reasonably
familiar versus seeing it vulcanized
into 10 or 20 different approaches.
So I think Kubernetes needs to keep bringing in ideas,
but I do think we're kind of at that point of Kubernetes
starting to, as we look at the second stage,
a lot of the concepts work really well,
but some of the abstractions and some of the stuff,
are maybe too detailed.
Most organizations that I know of who are deploying
Kubernetes are building layers on top of Kubernetes,
whether that's a CICD layer,
whether that's an existing layer.
So some of the large organizations that already have these
technologies fit Kubernetes into their existing application
life cycle, many of which are very sophisticated,
very mature, and that layer on top of Kubernetes,
I think is actually a really interesting area where
Kubernetes wasn't intended to really be too specific
to a particular set of machines.
But in practice today, if you build,
if you choose one vendors service and then try to run it on
a different vendor services, not all the APIs are the same.
So I think Kubernetes will kind of evolve both as an
ecosystem and as the ecosystem on top of Kubernetes,
so that you'll start to see some of that convergence.
And then I do think new technologies have to be integrated.
This is the, more than anything else,
we're not gonna keep it,
we're not gonna stop inventing new ideas,
new ways of packaging software service is a great example.
I don't even think we've really scratched the surface
of what it means to bring small amounts of code
into close contact with data and services and enterprise IT.
And so that transformation,
probably won't work exactly
as another component in Kubernetes,
but can absolutely part of that ecosystem
and drive some requirements around multicluster,
consolidation of workloads.
What happens when you wanna work,
move a workload between clouds?
What happens when you wanna keep dependencies
and bring your workloads close to where your data lives.
Because data gravity is very real organizational
force that will shape,
how people deploy and how people adopt cloud.
- Clayton one thing I noticed about the CNCF case studies,
there were 88 last I looked,
almost all of them are technology companies
or SaaS providers or online commerce or big banks.
We talked about, CERN is a special case.
I think the community could do a lot better
at illustrating where Kubernetes can work
in production for companies that are not more in the cloud
that are not internet creative
and actually have been around for some time
and kind of do day to day work,
whether it's manufacturing, insurance,
financing, you name it.
- The boring stories,
because I think Kelsey's right, is what's boring,
is things just working and you make reasonable choices
and you're conservative in your approach
and you have a good relationship with the community
and one or more vendors.
And when those stories get told,
they're usually, "I modernize my infrastructure
where I was able to accomplish this modest project,"
or "I reduced my costs."
I agree, I think we often focus on the cool part
in the ecosystem and many other vendors,
from the players that have been around the whole time
in Kubernetes to the public clouds,
bringing their services to integrators
and others have a lot of those success stories
that come from making the right choice.
I don't know if there's a lesson,
but if you see a giant tech company picking open source
software, they may tell you where the wind's blowing,
but you really need to look at the folks who are successful,
not just building it themselves to really assess that
and I do think that that's something
the community can do a lot better.
- Yeah, I agree with that,
I think that's the key for people
to really better understand how Kubernetes
is going to develop and change IT
in ways that are immediately
beneficial and meaningful for them.
But hey, it's been a great conversation,
I look forward to following up at some points,
a great conversation,
I'm glad to have that opportunity to chat.
- Lee, it's been phenomenal talking to you,
I really enjoy this perspective
and how do we as the larger ecosystem of everybody,
we're all trying to improve,
to give the right information at the right time from
community to vendor, to analyst, and I think that this flow
is something that even the ecosystem doesn't do enough of.
And so it was really a pleasure to talk to you today.
Thank you.
- Thank you.
(ethereal music)