>> Hi, I'm Justin.
>> I'm Bridget.
>> This is The Open Source Show.
>> Okay, Justin. Lay it out for me.
What is cloud native?
>> Cloud native is a loaded term that
is- I mean a lot of marketing and hype around it
but it's really about how to use
cloud environments and how to make use of
them for the best value to
your business. And being native just means:
I no longer control
the infrastructure or the services completely,
I don't have to run those things and
understanding why that's valuable
and how your applications will look
different when they are in a cloud environment.
>> So, you're talking about abstractions.
You're picking the level of
abstraction that your application is
going to interact with and
reside on a specific set of infrastructure?
>> Abstractions is one point of it because
abstractions add value in a lot of cases
where I talk to the Linux kernel now, I
don't write an assembly. But it's also
about using services when you can
and not necessarily trying to build
everything yourself, because you don't have to
reinvent...not everything has to be invented in
your company because a lot of these hard problems are
solved and you don't
have to always rewrite things from scratch.
I'm not writing a Linux kernel or a networking stack.
I'm writing applications that provide
value to real people.
>> Can you talk a little bit about how did
you come to write a book about cloud native?
>> Just like building applications,
the book kind of evolved from
being very focused on the projects
and what the Cloud Native Computing Foundation
does as far as being an umbrella organization around
these projects and really kind of
change instead of focusing on the projects themselves,
focusing on the patterns
that have emerged from these products and from
companies that have been running
infrastructure this way. From
the companies like Netflix, and Google, and Microsoft...
understanding what the value was in the patterns and not
necessarily just you need
to run containers, you need to run Kubernetes.
It's learning from all these other companies
that either were building clouds or using
clouds early on and
seeing the process and how they were using those.
When Netflix was doing this,
Kubernetes wasn't a thing, there was no Docker.
They were doing it with VMs and they understood that
the practice was more
important than the tools specifically.
That's really what we
try to lay out in the book, and Kris also does
a great job explaining... if
you are building something that
you need to run infrastructure,
how to take the patterns out of projects
like Kubernetes to run in a specific way
that adds more value, instead of just here's a bunch
of Bash scripts I threw together.... and now it's production.
>> Yes. I feel like the work
that I've done with infrastracture,
it ends up being like you
can hand tool a lot of things... if you want to
build it reproducibly, and if
you want people to be able to consume it as a service,
that's an entirely different ball game.
But when you're looking at the entire CNCF,
what would you say makes the most sense
for someone who is pretty
sure they want to get involved in
some sort of cloud native development?
>> Start as high in
the stack as you can and work backwards.
Find out what the application does,
how that provides value to
the business, whatever that value is.
But reaching customers and really
making an impact that matters to the business
and working backwards and seeing
the lowest thing that
you have to do that's different
than any other competitor
and not starting from the ground and saying well
I need to buy some servers
and I need to rack them them because obviously
that's a lot of work and people do that.
It doesn't differentiate a business.
Taking a critical look at what problem you're trying
to solve and why
you want to solve those problems because
yeah, interesting problems - engineers just love them.
We'll eat those things up and we'll write them
whatever distributed log in
my free time because that's fun.
But really, where does it provide value and
how is that the next thing that
you want to do and then understanding,
do you have to run this thing?
Is this something that I'm going to do it
different than all these other providers
doing it, from distributed logging or
just regular cloud environments that
provide compute for me.
Do you have to invent all those things? Probably not.
From there also, learning from how
these other tools are doing it, how other companies....
if you need to scale drastically like having declarative
APIs and having like pull base metric system,
there's all these things that
we learn from these projects that
are just kind of fundamental but
really for an infrastructure engineer,
start as close to the application
as possible and work your way backwards to see,
"okay, this is the part where I break
from everyone else or there isn't
a service that provides this thing or we
need to run it a different way"
and then work your way up from there.
>> Well, especially I think because
every single piece of unique to you,
unique to your organization,
the glue code that you need to
write in order to deploy your application...
that's more cognitive load,
that's more things that
people who come into your organization have to learn.
>> Right. It's not even that because it's
also how much of this is composable
and how tightly coupled did you make
these two systems together
versus how can I just replace that piece.
If someone does leave the organization
or when the situation
changes like "now, hey guess what?
We need to go that direction, we need
to do something else.
Hey, I need to plug this other piece in because it
solves the problem a different way and that's important."
Yes and that's what really
being in a cloud environment is super beneficial,
because these cloud providers
have solved a lot of those problems and you can just say,
"hey ,call that API, give me
a Kubernetes cluster... we're done."
>> Yes. If people want to catch up with you,
if they want to read your book,
if they want to interact with you on
the interwebs, where would they do that?
>> Yeah, I know there's some links in the show notes.
I'm on Twitter pretty active,
I'm @rothgar on Twitter, and
cnibook.info is information about the book.
I'm really open to just having people reach out online.
I know Kris is the same way.
We're both active in Kurbernetes communities in the CNCF.
We're on GitHub. If you're used to the open source tools,
we're available and reachable and
hopefully you can find us on there.
>> Nice, I love it. This is of
course The Open Source Show and people
can check out open.microsoft.com,
if they want to see more and contribute.
>> Ralph.
>> Yes.
>> I want to ask you a few questions.
>> Great.
>> What do you do? Who do you work for?
>> I work for Microsoft. I'm a Program Manager
with the Azure Kubernetes Service.
>> Why Kubernetes?
>> It's a wonderful
open source container native orchestration tool.
It is incredibly flexible and powerful.
>> Flexible and powerful. Can I have
one large cluster all around the world?
>> You could, but you might find that
the feature set is a little different than what
you expect on your machine or in your data center.
>> How do you spell it?
>> I sell a K, the letter...the number eight ,and s.
>> The letter eight?
>> Well, one of the letters.
>> What's AKS?
>> AKS is the Azure Kubernetes Service.
It's the managed Kubernetes service, where we own
the masters and the services that
normally involve touching the masters...
>> Yes.
>>... are provided as part of the service, and there's
an SLA for those -- and the nodes are yours,
so, you really focus on your application.
>> Okay. What about ACS Engine?
>> ACS Engine? Ah, I see where you going.
The ACS Engine is the open source version
of the templates that we use underlying AKS.
>> Yes. >> And so you can actually
participate with the team as we build the AKS
features there in
completely open source participate with issues,
vote things up and down.
>> Yes.
>> You could actually submit a PR for
your favorite feature if you want.
>> Awesome. What would you have as
a going away message for people to
get started with Kubernetes?
>> With Kubernetes, it's open source. I would
say go look at the docs,
go read the code, have a great time and actually...submit a fix
>> Maybe contribute too.
>> Yes absolutely.
>> Awesome. Thanks for the time Ralph, it's been great.
>>You bet.