Containers are revolutionizing the way that we develop and manage applications.
These containers allow us to build, develop, test, and even deploy on the exact same system.
We can build layered systems that fill in our dependencies.
They even can play a crucial role in zero downtime upgrades.
This is great until you end up with five different types of containers,
each of them scaled out, and you need to get them to work together,
discover each other, and upgrade together.
That's where Kubernetes comes in.
Today, we'll meet Kelsey Hightower, a developer advocate on Google's cloud platform.
This is Talk Python to Me, episode 126, recorded June 9, 2017.
Welcome to Talk Python to Me, a weekly podcast on Python, the language, the libraries, the ecosystem, and the personalities.
This is your host, Michael Kennedy. Follow me on Twitter, where I'm @mkennedy.
Keep up with the show and listen to past episodes at talkpython.fm, and follow the show on Twitter via at Talk Python.
This episode is brought to you by Rollbar and us at Talk Python Training.
Be sure to check out what we're offering during our segments.
It really helps support the show.
Hey, everyone. Just a quick heads up on this episode.
I recorded it on site, on location, with Kelsey Hightower, which is a great experience, cool opportunity,
but it turns out the audio was a little echoey and not the same as back in the studio where I normally record.
So you'll have to forgive a bit of an echo on this one.
It's a great conversation, and I hope you learn a lot from Kelsey.
Now, let's chat with him.
Kelsey, welcome to Talk Python.
Awesome. It's awesome to be here.
Fantastic show. So I'm honored to be a guest.
Thanks. It's an honor to have you as a guest.
You had such a cool keynote at PyCon. It was really fun.
Yeah, I was honored to do that one.
That was my, I think, completing the mission.
You know, Python meetup is where I first started,
and then having the honor to do a closing keynote at PyCon 2017 was amazing.
You've completed the circle of your Python journey?
Yeah, I think so. I think you just think about what just over the years,
it was probably maybe six or seven years in between my very first talk and giving that Python keynote.
So a lot has changed for me personally during that time frame.
Yeah, I'm sure it has.
So I totally want to talk about PyCon, but let's start with your story.
How did you get into programming in Python?
I think, like most people, you know, I was looking for my first real programming language.
So I started with Bash as a system administrator.
And you kind of run into some limitations with Bash, you know, things you can and can't do.
So I reached for things like Python.
So I was working in the financial industry, and I just needed a tool that could actually replace some of our COBOL jobs.
Okay.
So we had these old things that like transform data for the mainframe.
Can you believe that stuff still runs?
Oh, yeah.
I mean, and fast.
Yeah.
Right.
And people still make a ton of cash on it.
So my first, you know, dip my toes in the water and I learned PacDecimal, right?
Because I had to convert a lot of the formats for the mainframe.
So you're dealing with EPSIDIC, fixed-length formats.
And then Python was like a really straightforward language, but it also had great libraries to kind of deal with a lot of the math stuff and, you know, things that you would do even in the mainframe world.
Right.
Absolutely.
Okay.
And so you started out in Python and now, well, started out in Bash, got into Python.
And now what are you doing?
Mostly Go?
Yeah.
So Golang is kind of my language of choice.
You know, something happened in the industry where, you know, when I used to think back, most of the tools you were using,
as a system, I remember written in Python, whether it was like AppGit or Yum or, you know, things like Ansible.
It was kind of like the system means go-to language, you know, after Perl, there was Python.
And, you know, something happened where Golang just became like the thing you'd use for like distributed systems and containers.
So kind of made a switch to that a couple of years back.
That's cool.
Because, yeah, you're all about the containers these days, right?
Yeah, containers, distributed systems, this whole new world where we're like packaging our apps in like this universal format
and then just giving it to the system to deploy.
So that's been a pretty interesting journey.
Yeah, yeah.
It's very interesting.
And I think we're just at the beginning of this really, right?
Yeah, I think a lot of times I think these are patterns we've always been doing.
If you think about like in the Python world, we were dealing with like virtual nth.
We were trying to create these self-contained deployments.
So virtual nth, having pip.
And when you put those things together, things like Docker is the natural evolution where you say, hey, I create this virtual environment.
Everything I need is in there and self-contained.
How about we just package that up and ship that around?
Right.
Instead of creating a virtual machine or even a real machine on real hardware, setting it up, setting up a virtual environment, get it all going.
Now you just have, what, like a Docker file?
Yeah, and I think the Docker file, if you think about what it looks like, if you've never written one before, it's essentially like an organized bash script in many ways, right?
There's some semantic meaning to some labels and things you can do in there.
But for the most part, you're making a repeatable set of steps.
You know, maybe you install Python or you have a base image where Python's already installed.
And then within that Docker file, you will say things like pip install my requirements.txt.
And then when you're finished, you can just say, here's how you start my app.
So it just gives us a repeatable process to what we've already been doing.
Sure.
It's like scripting, automating all of the best practices we should be doing, but maybe aren't.
Yeah, I think so.
And also, usually on a team, you have like one person who does know how to build an app from scratch, right?
Usually keep this like build my app type script inside of the directory.
And a Docker file has become that.
And it also now produces an artifact so that once you build it once, ideally you can reuse it in multiple environments.
Right.
Yeah, that's cool.
Let's you test closer to production, for example.
But you definitely don't want to lose that person that knows how to build that thing.
Oh, yeah.
We're not replacing people.
I think what we're doing is also there's a lot of open source projects, right?
You can imagine going to get like your favorite web app built in like Django, for example.
And then having to deal with like what version of Python, what dependencies, how to build it.
Sometimes people just want to play with it right now.
So an alternative, and this is key because some people are starting to replace their documentation, their scripts with just Docker files.
And that's infuriating to a lot of people.
So I think you can complement your installation by saying, hey, here's the raw, you know, maybe if you're still doing eggs or whales for the actual application.
But an alternative could be, oh, here's a Docker container if you just want to just run it on your Docker machine.
Yeah, yeah, absolutely.
Absolutely.
Let's talk really quickly about PyCon before we dive deep into Kubernetes.
So you got to go to PyCon and give this presentation.
That was super amazing.
What was your favorite thing about the conference?
Well, I think the thing I like the most about PyCon, most people are there because they want to be right.
And I think that's a unique thing that we don't see at a lot of tech conferences.
Either tech conferences could be expensive, so you really need to be reimbursed by your company or you have to take time off work to do it.
And since PyCon is on the weekend, a lot of people choose to be there.
Some people, a lot of people pay their own way.
So just the experience of the, you know, I call it the, I guess kind of the hallway track, right, where you just walk around, you meet new people.
I met people with the, what do they call it, the holy staff or whatever.
You know, this thing travels the world.
Yes, that's right.
Staff of enlightenment.
That was Anthony Shaw.
He brought it from Australia.
Yeah, so you have people like that walking around PyCon like, hey, we just want to get a picture of you with this staff of enlightenment.
And you know that there's this organic feel to why people are there.
It's a deeper community.
It's like one of these communities that have been around for so long.
This is a family reunion for most people at PyCon.
So it just feels different.
Yeah, yeah.
I just had Kenneth Wrights on the show.
He's done a bunch of Python stuff and said, this is my favorite time of the year, right?
This is actually like the favorite week.
And so I feel that way as well.
It's really, really, really amazing.
We get great keynotes like yours.
But I really, besides the keynotes, I honestly try to just do the hallway track.
Like these chances of meeting people who you would not normally get to talk to.
You just get to stop.
And then I drop in on YouTube and watch the presentations.
Yeah.
And I think the other element, I didn't get to enjoy it this year.
But my very first real conference was PyCon in Atlanta.
And the sprints, you know, where you're actually working side by side with, I guess you can call them the big names in Python, the people that are actually doing the hard work, maintaining the packages, maintaining the core.
And they just make space for you to come in and learn, do your first contribution.
That was my first contribution to Python.
I was working on PyPy at the time and PIP.
Yeah.
So some of the disk utils and those tools.
So I think that's kind of the thing that's really unique to PyCon is that you can actually sprint with the people that are working on this stuff.
That's actually a really good point because most conferences don't have that.
The big names go up, they speak at you, and then they leave.
And that's that.
That's right.
Yeah.
So very, very cool.
Okay.
There's also the after party events, right?
We went to like, it was the dinner at the art museum, for example, we got to meet up.
And we played this really cool game, the classical programmer painting naming game, which I think any programmer must do when they go to an art museum, right?
Yeah.
I think for those that have never played the game before is you go to a museum.
Where it's supposed to be serious business.
Very proper formal art, Monet and so on.
Yes.
People there who are appreciating the art.
And then, you know, you show up and then you start to give names or meaning to paintings you know nothing about.
And I think you start to learn more about people as they pick names or they give an explanation for what they see.
It's like, wow, this person really needs to take a vacation.
Yes, exactly.
Maybe there's like a picture of with like a burning field in the background, people working.
You're like, these are like Java enterprise developers, like finishing a sprint or something like that.
Or you give it a name of Docker 001, right?
It's on fire all the time.
Awesome.
All right.
Cool.
So let's talk about Kubernetes.
We spoke about Docker and we spoke about containers.
How does Kubernetes relate to that?
What is Kubernetes and how does it relate to Docker?
So I think when you think about like Docker, you think about I have a single machine.
And, you know, if we think about the way we used to do deployments or still do, right?
I don't think it's that far removed.
You can copy some bits to a machine.
If you don't have the environment set up, you can probably do something like virtual ent, get all your dependencies there.
Maybe use an init system to start it up or maybe just, you know, fork it into the background.
So what Docker does is says, hey, let's contain all of that, make a reusable package and then provide an API.
So no more logging into servers, right?
You got a Docker machine.
You have the Docker command line tool.
You can say, hey, Docker, run my web app.
Okay.
Docker, run my SQL.
Docker, run all my dependencies.
And then you look at that and you say, well, how do I scale that across a lot of machines?
And I think that's where Kubernetes comes in, has a new API.
You can say things like, hey, give me five of these, decouple from a particular machine.
And you can also do things like service discovery being built in, right?
So that's kind of a deeper topic where you already have MySQL deployed in this Kubernetes system.
You have no idea where it's going to land.
It's going to get its own unique IP.
How do you connect to it?
And those are the kind of features that are built into Kubernetes from a bigger cluster management standpoint.
Yeah, that's fantastic.
It solves such a great problem because Docker is pretty straightforward when you're doing one container.
Your app is in the Docker container.
But if you've got different tiers, a database tier, like a web tier, a load balancing tier, like different services, like if you're doing microservices, it gets really crazy, right?
Like how do you even like identify all of these things?
And so Kubernetes is kind of like that, both the management of all the containers plus that glue that binds them together.
Yeah, it's like a big framework where you can do all these policy-based decisions.
Like you can have things like autoscalers or a core concept inside of Kubernetes.
You can say, whenever this aggregate set of my containers reaches 10% of CPU utilization, scale them up based on the step function.
And you can define that by just using simple YAML.
You put it in place.
And the whole system works that way.
So it gives you a way to think about a lot of computers, like a single computer, just based on this declarative policy-based way of thinking about compute.
All right.
So let's see.
We take a Docker file.
I'll start with just one for now.
We take a Docker file.
We want to run that in like a cluster.
We can go to Kubernetes and go, Kubernetes, run this, scale me five of them.
And you just get like an endpoint and a port and you just treat it as one thing and it's just like round robin and load balances around?
Yeah.
So I think for most people it's great to think about this in layers, right?
So you may use Docker for your day-to-day development and then you're going to produce an artifact.
Let's call it WebApp001.
And you push that to a registry.
So the price of admission to Kubernetes is that container in a registry because that's how it pulls things down.
This is kind of the fundamental building blocks.
And then you may have a deployment.
Hey, deploy three of these.
And at that point, you just have three of these things sitting there with their own IP addresses.
They're going to land on the right set of machines.
And then the next layer is maybe you want to expose it to the outside world.
Then you can create what we call like a service and say, hey, Kubernetes, anything that looks like that WebApp, which we identify by labels, you know, app equals foobar.
And then the service will say, okay, I'll go and find those and keep that curated list.
So if one of them crashes and comes back up, it knows to replace them in a low balancer.
And then that layer will handle incoming traffic and make sure that it routes directly to the right pause to handle it.
That is really super nice because that's one of the concerns, right?
Like I'm going on vacation pretty soon.
I really don't want my sights to go down and just vanish from the Internet.
But I also don't want to be like woken in the middle of the night to try to bring it back.
I mean, this is not something that happens often, but it's something that's like really bad if it does.
And so we used to solve this problem by sticking pagers on people, right?
Yeah.
So I think the whole on-call thing is born from, especially for the simple cases, it's okay to get on-call like for something that is like, oh, wow, no one could imagine that.
That's a true emergency.
But some of these on-call pages are like, hey, you're one instance of your site is down.
You're like, so why are you calling me?
Like, how about you just re-spin that up?
We know how to do that.
Exactly.
Did you try rebooting the server?
Yeah, exactly.
How many times?
And lots of people wake up and they do that.
They wake up and say, you know what, let me just kick the server and then go back to sleep.
And that's the thing that kind of disappears in a system like Kubernetes where you just say, look, I want three no matter what.
So if a machine goes down, it just knows like, hey, let me just spin one up because the declaration you used to create the first one is still there and it can use the same template over and over again.
Nice.
And you basically pin it to a version.
Like right now you should have three of version three of our app.
If it goes down, recreate that, right?
Yeah.
And that's the key about this whole container thing, right?
Is people say immutable and that's probably a good way to think about it.
But, you know, while it's running, of course, there's memory being mutated.
But on disk, you're starting from the same point over and over again.
So if you do have to restart two or three, you're always going to get back to the same point that you expect.
Yeah, that's awesome.
So really, you're almost to the point where the only reason it wouldn't come back alive, okay, is some other service.
It depends on changes, right?
Like if you're doing microservices and the API like completely freaks out your app, then you've got to fix it.
But if something went wrong with that machine, it's just, well, it's just going to fix itself, right?
Yeah.
And it'll come back and it'll be fine.
And I think you bring up an important point.
Kubernetes doesn't solve all the problems, right?
It's not magic.
We can't just sprinkle magic on us.
No, no, no.
It's definitely not magic.
You have people, like you're right, if someone were to deploy a new version of the dependency that you have and the API is fundamentally different, yeah, Kubernetes will say everything looks good to me and your app will be down.
So you have to think about where Kubernetes starts and stops and then what becomes an application concern.
And that's where your classic metrics monitoring come into play.
Yeah, but it does make it easier to test as a kind of a cluster, right?
So if you have this microservice thing with five services, you could just locally or in some staging areas spin up all the various pieces, make sure they click together, and then just make sure what you deploy is all those pieces, right?
Yes, we're definitely getting to a place where now we have an API to reason about this kind of thing, right?
You have five different deployments that need to talk to each other.
You can associate a service, give every deployment a name, and then just reference those services by name, whether there's one or five of them, and you can be sure to connect to one that's available.
So that's just much easier to do versus tribal knowledge, scripts, and just knowing how to do things.
Yeah, it sounds better for sure.
How do you know from within your app?
Like, suppose I have a Flask app like you had in your demo, and it talks to, say, a database server that's also running in a different container but also managed by Kubernetes.
Do I talk to it by name, by IP address?
How do they find each other?
So today in Kubernetes, what you would do is ideally just say, hey, I want to connect to MySQL by name, MySQL, on port 3306.
And what will happen is if you have a deployed container in Kubernetes, ideally you'll have a service in front of it, and the service name will be called MySQL.
So what that does is Kubernetes has these control loops.
So what the control loop will do is say, all right, let me find the MySQL server, get its IP address, and update the internal DNS server that we have, cluster-wide.
So all you have to do is call MySQL, and the name or the IP address associated to that service, that IP will be fixed for the life of the container.
So even though the container may go up and down and get a new IP, you'll have this kind of virtual IP that maps to it.
And it kind of runs its own DNS, so you talk to it by the name.
You've given even maybe that load-balanced group of things, and it just finds it?
Exactly.
So that becomes a virtual IP that allows us to have a stable naming convention, kind of the key to doing service discovery correctly.
Okay.
This sounds pretty cool.
Does this work pretty well in your own data center?
Like if I had 10 big Linux machines, could I just set this up?
Yeah, so that's always been the goal of Kubernetes.
We think of it like, you know, some people refer to it like the Linux of distributed systems.
Okay.
Right, so the goal is it doesn't really matter too much what distro you have or where you run it.
We have all these pluggable, what we call them, cloud providers.
So if you're in Amazon or Microsoft or Google, it will kind of detect that and like integrate with all the stuff that's there.
So if you say, give me a load balancer, it'll spin up the proper load balancer for that environment.
If you're on-prem, you're free to make your own integration.
So maybe you have something like an F5 load balancer.
You can do your integration there.
But for most functionality, it doesn't matter if it's on your laptop or in your own data center.
You install it, you hook it up correctly, you have a Kubernetes cluster.
And you guys at Google also have, you guys do some cloud computing, right?
Yes, we do.
We do a lot of cloud computing.
And you guys have a Kubernetes service as part, like kind of, you've got Google Compute Engine, you have Google's Kubernetes engine, right?
Yeah, we call it a Google container engine.
Container engine, right.
So it's largely the open source Kubernetes, deeply integrated into Google Cloud.
And we just try to give you all the things we know you would need, like access to load balancers, storage, metrics, monitoring, logging, audit logs, that kind of thing.
Okay.
And so tell me about the persistence stuff.
This is almost more of a Docker question than it is a Kubernetes question.
But if I run MySQL in one of these containers, ultimately I want that data to not be transient, right?
Where does that stuff go?
On one hand, I could obviously just hook into like RDS and Amazon or some database as a service.
But assuming I'm not doing that, if I'm storing it on the disk, where does it go?
So this question is probably the biggest source of confusion because of the defaults.
If you take Docker out of the equation and I tell you I have a server and I install MySQL on the server, app git install MySQL, and you write data.
Where does it go?
It goes to whatever volume you write to on that server.
If the server dies, there goes your data.
Now let's add Docker to the equation.
You say Docker run MySQL.
Now the default in Docker is that you're going to get a temporary file system and you won't be able to write to those.
Inside the container.
Yeah.
But really inside your true root, right?
Still on the disk.
Yeah.
Except for it's going to get its own unique name.
And by design, by default, we're just going to clean up when that container dies.
Here's the temp files.
We don't need any more.
Yeah, exactly.
Now, if you wanted to do this, you could just say the same varlib MySQL.
Just mount that into the containers.
You can say Docker run MySQL.
Mount in the host, varlib MySQL, into the container, varlib MySQL.
And everything you know about writing data to this is pretty much going to be the same.
Okay.
So there's no magic there.
It's just that the default for a container is complete isolation.
I see.
So, yeah, right.
So you basically configured your MySQL to write to, like, slash datastore or var, datastore, whatever.
And then that, as long as you map that somewhere on your main machine, you could throw away that container, recreate it.
It'll read from there again.
It'll carry on, right?
Exactly.
And I think we're all spoiled by just having full access to a machine.
And then, like, wherever it writes, that's where it writes.
But inside of the container, since you can run multiple of these containers at one time, you kind of want your own file system space to do whatever you want.
But remember, you can always just mount things.
You just have to be explicit versus it being in an explicit contract.
Right.
And you just put that in the Docker file?
So that's the thing.
So in Docker files, that's where Kubernetes starts to be very advantageous to people or something like Docker Compose.
Some of these semantics around run it like this is kind of where Kubernetes starts to shine.
So when you look at a Kubernetes manifest, you say, run this container.
And, oh, these are the volumes that come from the host.
And I want them mounted here into the container.
So you look at the full spec, you can see, oh, this is what should happen.
And you know that that would be the right semantics versus, like, the Docker file, you can express some volumes.
But you really need to make sure that you do the right thing when you say Docker run, mount all these things up.
Or do something like Docker Compose.
Right.
And it's a little more like your Kubernetes Yemma file can just put that all together, right?
Yeah, you want that to be the whole contrast.
When we think about a pod, we say a pod is the network, the container, and the volumes that it needs.
This portion of Talk Python to Me has been brought to you by Rollbar.
One of the frustrating things about being a developer is dealing with errors.
Ugh.
Relying on users to report errors, digging through log files, trying to debug issues, or getting millions of alerts just flooding your inbox and ruining your day.
With Rollbar's full-stack error monitoring, you get the context, insight, and control you need to find and fix bugs faster.
Adding Rollbar to your Python app is as easy as pip install Rollbar.
You can start tracking production errors and deployments in eight minutes or less.
Are you considering self-hosting tools for security or compliance reasons?
Then you should really check out Rollbar's Compliance SaaS option.
Get advanced security features and meet compliance without the hassle of self-hosting, including HIPAA, ISO 27001, Privacy Shield, and more.
They'd love to give you a demo.
Give Rollbar a try today.
Go to talkpython.fm/Rollbar and check them out.
How do you guys use Kubernetes at Google?
Like, I saw that this sort of was born out of the Borg, which is a pretty awesome name.
And now it's an open source project, and it's hosted by, what is it, the Cloud Native Computing Foundation?
Yep.
So Kubernetes was born.
CNCF is a foundation kind of designed for all these cloud native tools.
FluidD, Prometheus, Kubernetes, OpenTracing.
This is where you start to do application level tracing on how web requests flow through a system.
So all of these collections of tools we think of make up the cloud native stack, kind of cloud native idea.
And where does Kubernetes come from?
Internally, we have a thing called Borg, but that's kind of a bit misleading.
People say Borg, and they mean like maybe six or seven layers of stuff.
Right.
Okay.
So Kubernetes represents one layer of that kind of stack, right?
So Kubernetes would be the part that knows how to manage resources across a bunch of machines,
knows how to deploy containers, and then serves as a framework of information for things like metrics and monitoring.
And you would bring in other tools for that.
So I think when you say Borg internally, it means a lot to Google.
It's kind of like a catch-all, but there's lots of stuff in there.
If you want something like Borg in the real world, you would say Kubernetes plus Prometheus plus there's a new project called Istio that works really great for microservices.
So Istio's idea is that you have these sidecars that know how to do exponential back-off, retries, TLS mutual off, and authentication between microservices and policies.
You take that and maybe some more, then you get what we call Borg, right, for the most part.
Yeah.
So is Kubernetes actually running inside Google as part of this thing that's called the Borg now?
No.
So Borg is its own system.
It has a lot of features, and it actually has a lot of the way Google works, the way Google infrastructure works.
Super specialized to Google.
Hyper-optimized, right?
But if you think about Kubernetes, it's used a lot in our cloud offerings.
Like if you think about what the cloud ML and the TensorFlow team is doing.
So they use Kubernetes for their stuff.
And you can also imagine a lot of our customers are course running on top of Kubernetes.
Kubernetes can also be used for other product offerings.
You can imagine something like building hosted services or something like cloud functions.
So Kubernetes gives us a really nice API for managing containers in a cloud platform.
Do you, or I don't know if you can even talk about it, but do you have groups of people who are basically running cloud computing services on top of Google App Engine and these types of things?
Like they're putting their own infrastructure and then reselling it as a service on top of what you guys are doing?
Well, you're talking about internally.
No, I'm talking like, is there a company that like is like DigitalOcean or Linode type of company?
Oh, like a second tier cloud provider just reselling services?
They've got some special layer on top of what you guys are doing.
I don't know if there's any of those that I could probably talk about, but we know there's services like, of course, public like Snapchat, for example.
You know, they built their platform.
And most cloud providers, what you'll either see is either they'll use like our storage, you know, if you need petabytes and petabytes of storage at scale, you'll see something like that.
And maybe they turn around and sell that as some other thing that they call by another name.
Sure.
But typically to be a cloud provider reselling another cloud provider, I think you'll get destroyed on margins.
The best you could probably do is what Rackspace is currently doing, where they're providing like supports, where it's your account.
You'll be paying the cloud provider and they put their support premium on top.
Yeah, yeah, that makes sense.
I mean, the margins are, it's a super competitive business.
Yeah.
I mean, like, why would you buy a VM knowing that it's running on like another cloud provider and pay more for it?
Like, that's going to be tough.
Yeah, there has to be a secret sauce, something extra.
Okay.
Yeah.
Very interesting.
So it feels to me like if I use Kubernetes, I'm a little bit more removed from the infrastructure of any one cloud provider.
So can you maybe speak to like the relative lock-in of like one cloud provider versus the other and using, say, Kubernetes?
Yeah.
So this lock-in thing is like, I look at it and I think I made a quote recently.
If you try to switch products to avoid lock-in, that's just another form of lock-in.
And Kubernetes, the API is open.
The project happens to also be open source.
So if you run it on your own data center, on your laptop, Google Cloud, Azure, or Amazon, you're going to get the same API.
So essentially, you can be locked into the Kubernetes API across all these environments.
So the trade-off there is maybe for some people, that's better than being locked into, say, one endpoint like ECS or Heroku.
So I think when we talk about lock-in, we ask ourselves, what trade-offs and compromises are we willing to make?
And Kubernetes offers enough value that if you lock into it, right, to go with the terminology we're using,
then you feel like you can be a little bit more portable than what we were doing with virtual machines.
Sure. Yeah, I totally agree.
Also, it depends on how much you kind of buy into the full set of APIs, right?
Like if you use Google Blob Storage and hosted databases and all of the specific Google App Engine APIs, well, you're more tied into Google's cloud than if you just use Linux and straight up stuff and write to your own disk and your own server.
Exactly. I think a lot of us are starting to ask ourselves what the trade-off is worth.
So when I look at the spectrum of trade-offs around lock-in, you've got a couple of options.
Like let's say you use a hosted database service.
Well, they manage the database for you.
They back it up.
They control the version.
But you feel it's a good compromise for your time because you're using an open protocol.
I can go and talk to the MySQL protocol in any environment that I want.
So you know what?
You can host that.
Now, it gets a bit more tricky when you're dealing with something like maybe, let's say, Cloud Spanner.
That is its own thing.
It offers its own capabilities.
Tell people what Cloud Spanner is.
So Cloud Spanner is this, like, we are challenging this idea that if you have SQL, that we can scale it horizontally.
You can also have it multi-regional.
We can also do distributed transactions.
So this would be, you have the SQL language you know and love.
So imagine having a SQL or a Spanner database in Asia, in California, and Europe, and you're able to write to them
and then actually have all the data be available in all the regions and be able to do things like distributed transactions.
So you're not making the tradeoff between no SQL where you have eventual consistency from, you know, the traditional database stuff.
So that's one of those things where people look at it and say, you know what?
It's really hard to maintain my own MySQL shards and all the magic that goes behind that.
Maybe I'm willing to trade off a little bit for this kind of proprietary thing that only runs in one cloud provider.
You just got to make that decision.
Yeah, that sounds, I remember what that is now.
That sounds really, really advantageous for global companies, right?
And if you're on the internet, maybe global, right?
Yeah, what we're hearing is best of breed.
So what we'll see now is that there'll be some companies that say, hey, we're using Amazon because we like a few of these things where we got a bunch of data inside of RDS, you know, their MySQL management thing.
And they say, no, we're going to leave those apps there.
But you know what?
We like BigQuery.
So we're going to deploy some stuff and just use BigQuery on the Google side.
And you're starting to see, you've seen this.
Companies are huge.
They may have like 50 different departments producing their own apps, their own business units.
So what you'll see is each of them choose their own story or how they want to do things.
And they'll end up having usage on all platforms.
And maybe there's no reason to reconcile when they're going for best of breed.
Yeah, you know, this service works really good for this.
That service works good for that.
For a Cloud Spanner, it makes a lot of sense to have this geolocated and maybe starting by region like Asia and Europe and US.
And so when you do a query, it like hits the local version.
How do you get your web app near each one of those regions?
So for each query or each interaction with the database is kind of local.
So the goal is, of course, you would try to optimize in a way where you write the local stuff to it's local to Asia.
But if you're in the US and let's say you failed over and you need to query some of that data, ideally we're replicating this, right, synchronously across these regions when it's time.
So the goal of Spanner is that you don't want to make that tradeoff.
You know that failures are going to happen.
Ideally, you want your data in as many places as possible.
So Spanner kind of gives you that ability to.
So you don't think about that in your app.
You don't think about partitions the same way.
So Spanner tries its best to do the partitioning for you under the covers.
It does the scaling underneath the covers for you.
Depending on how much money you have, you can keep scaling horizontally.
But some people want that.
The last thing you want to do is stop everything and repartition your database.
That's a nightmare for people that have ever done that before.
If you have petabytes of data.
Yeah, for some people, you just start a whole new cluster and you're like, we'll just phase that thing out.
So I think it's one of those things where you just got to think of a tradeoff opportunity in time.
Yeah, I mean, we feel like we have fast internet and these cloud, they're very fast and whatnot.
But, you know, Amazon, I don't know about Google, but Amazon has a service where you can literally FedEx hard drives as like the fastest way to upload data.
Yeah.
I mean, you're going to see this quite a bit.
I mean, the more data people produce, you need these white glove services where someone shows up with a truck and maybe they use that as the, you know, our sink.
You know, you just like copy the big file and the our sink from there.
And I think that's going to be until we get super fast pipes, we're going to have to figure that out.
But I think that will probably be the fastest way in some cases is to just ship things around at that scale.
That's awesome.
You just gave me a vision.
So, you know, a lot of these cloud providers like Google and Azure, they've got basically what look like shipping containers, which contain the servers.
I can just see trucks that just drive up with the full container full of servers.
You fill it with data, it drives over to the next data center and it unloads.
Yeah.
It's possible, right?
Yeah.
I think a lot of backup companies have to do this, right?
Like if you're truly doing backups, they're off site.
And if you have lots of data, you will have a vendor come around in a truck and securely grab your store's medium and go lock it down somewhere.
Wow.
All right.
That's awesome.
So we talked about Kubernetes and it's solving the lock-in problem.
One of my biggest pet peeves with working with these cloud things, especially when you deeply tie into their APIs, is I like to go work at a coffee shop.
Or on a plane or I'm on a trip and I have crappy internet access because, you know, I don't have a good international data plan or something.
Is there a way to like run this stuff locally on my laptop?
On your laptop, you can run a project called Minikube.
Okay.
So Minikube basically takes a lot of inspiration from Docker.
So Docker for Mac or Docker for Windows.
Yeah.
This idea that you'll have this kind of lightweight VM.
Docker will be installed there.
And Minikube just says, all right, let's install all the Kubernetes components on a single node because you get the same API.
So whether you have one node or five, you get the same API.
And for a lot of people, I guess you could do that.
But me personally, I develop using my normal flow.
I don't even use containers during development time.
Like I'll use like Homebrew on my Mac, give me Postgres, give me Redis, get those protocols up.
And I just write my app outside of all the container stuff.
Once it works, then I think about packaging and then making sure that I can deploy it on Kubernetes.
So I kind of decouple those workflows.
I know some people want to make it part of just the incident workflow.
But I look at that like running integration tests.
I run unit tests locally, integration tests on the integration environment, not on my laptop all the time because they may be too big or take too long.
Yeah, that makes a lot of sense.
Okay.
Yeah, very cool.
So if I'm going to use Kubernetes, how much of an expert do I need to be in like DevOps type stuff?
So there's two parts to this.
There's I want to install Kubernetes and manage it and upgrade it.
Then you should probably learn quite a bit about Kubernetes, right?
And I think a lot of people are looking for the 10 minute, like,
give me the tool where I can just twist all the knobs.
That's not reality right now, right?
There's some hosted offerings where you click the button and then they'll do everything for you.
Right.
That's GKE.
GKE, Tectonic from CoreOS.
Red Hat has, you know, OpenShift and, you know, some things to help you with Kubernetes.
But if you want to be the cluster administrator, meaning the company comes to you when Kubernetes breaks or needs to be upgraded or something doesn't work.
Yeah, you're in for a learning curve, right?
Like, have you ever watched a developer use Vim for the first time?
They can't get out.
This is a text editor, right?
And I think when you think about a fully distributed system that has a distributed database, has all these moving parts, you need to expect to study a little bit if you want to manage a cluster.
Now, if you just want to kick the tires in demo mode, then yeah, install Minikube, go at it, find some Hello World tutorials and you can get off the ground in less than a day for sure.
But if you just are a developer and you just want to use Kubernetes, this is where someone is managing it for you.
There's an API.
Then you install a little bit of tooling, kubectl on your laptop.
You look at a few examples on how to create your, you know, package your app and describe how you want it to run.
There's also things like Helm.
So Helm is a package manager for Kubernetes.
You can say Helm install etcd, Helm install Zookeeper or MySQL.
And then that will go out and get all the things you need to do, like the service, the volume, the deployment object and deploy it to Kubernetes and manage it as like a single package.
So then I can like start that pod, which is just.
Yeah, exactly.
So you can say Helm install MySQL, Redis and Kafka.
That's the things I depend on.
Then write your app, package it up, and then you can refer to them as MySQL, Redis and Kafka because service discovery is all built in.
And for a lot of people, that is the magic moment.
It's like, wow, I didn't have to even touch all that stuff.
Yeah.
So we're used to doing that at the application level, but you're kind of doing this at the server level.
Like, yeah, I install this server machine and every bit of its infrastructure.
Yeah, because some of these projects are huge.
Like if you think about a production ready to go Kafka setup, you're talking multi nodes.
They need to be configured.
They need to be set up a certain way.
And you may not want to learn all of Kafka just yet, but you may want something that's a little bit more bulletproof so you can actually test how your client does fail over.
So it's really nice to have something like Helm install Kafka with three nodes.
And then you can test out that your client does connect to all three of them and fails over correctly.
Yeah, that's really nice.
So basically, I guess to sum it up is if someone is managing it within your environment, it's pretty easy to just like deploy your app and use it.
But if you want to be the person that maintains it, that's pretty risky, right?
Because now the entire company is sort of balanced upon your...
Well, think about your Linux distro, right?
Like, you know, how many people really know how to build a Linux distro anymore?
Most people do not know that you got to bootstrap and get the kernel, get the user land, get the package manager, make sure it all works.
You just like, you use Ubuntu and you're kind of beholden to every distro of Ubuntu works right.
The upgrades don't break everything.
And infrastructure is a lot like that, like the networking.
You realize that someone has all your routes set up that you can actually go out to the internet and back again.
So we tend to think that these things are...
We think we have control of them, but they just work and they're largely invisible.
So if you get a Kubernetes setup that works the same way, you can almost forget about it.
But if you want to be the management of it, then, you know, it's going to be front and center.
Yeah, of course.
Of course.
Okay, cool.
Let's talk about your keynote.
Awesome.
I heard so much good feedback on the internet about your keynote and people really loved it.
The comments on the YouTube video, right?
So it's on YouTube.
People can go and watch it.
Yeah.
So maybe just sort of let's talk about what you did.
So you start out with a Flask app, right?
Super simple Flask app.
You said, great, it runs here.
Well, you kind of riffed a little bit on the challenges of actually running an app, right?
Because it's one thing to have Python.
It's another to have all the dependencies and all the configurations and stuff, right?
Yeah.
So I think a lot of people, when we say, hey, just use Docker.
And you just tell the person that's doing Pythons, just use Docker.
And then when they go out and look around about what's required, they're like lost.
Because if you look at just a single container and you got to bundle in Apache, UWSGI, Flask,
shut the Unix socket, then fork them off in the background.
Oh, did you forget to change the permission on the Unix socket?
I don't know why it doesn't work.
Yeah, exactly.
So by the time you do all that and you only have one Docker file to express all of this,
you're like, something's not right.
This doesn't feel like I would do on a VM.
Because on a VM, you would have two separate processes.
And you think about them separately, right?
So I started with the Hello World.
And you go from Hello World to let's do Hello World with UWSGI and Apache sitting in front.
And then once people have that understood, and it's okay, now I get it.
I see that you're using pip to manage your dependencies.
What does it take to put that in the container?
And what we did was say, hey, let's show two.
There's one for your app and a separate one entirely for Nginx.
Let's not mix the two.
Right.
So you basically set up one Kubernetes pod for Nginx and one for MicroWizGui plus your app.
And you said, let's run those two together and they can one passes along.
So slightly differently.
So the pod concept is to capture what it means to be a logical application.
Okay.
So we know that Nginx belongs to this one instance of my app.
They're inseparable, right?
So in that case, in a pod, you can actually have a list of containers.
So we know we want Nginx to be the front door.
Nginx will mount the Unix socket from the other your app container.
And then those two should be expressed in the same Kubernetes manifest.
That's one pod.
And then I can scale that together horizontally if I want five copies running.
Nice.
And do those two containers always run on the same machine?
Yes.
They run what we call the same execution context.
I see.
So imagine having a virtual machine.
You would just install Nginx there and your app there, right?
So they all live in the same place.
But in this case, since we're using containers, we're going to put them in their own independent
true roots and file systems.
So they're still independent from that aspect.
But where we do start sharing things is the network.
So they share the same IP address.
That means Nginx can talk to your app over local host.
Now, my app is exporting a Unix file socket.
So it's a file.
So what I can do there is say, hey, we're going to write that file to a shared file system.
On wherever that happens to be running on that Unix machine.
Yep.
So on that machine, we'll say, I want a temporary host mount.
And once that host mount is created by Kubernetes, it's going to have a unique name.
So no one else mounts it.
And then we're going to give it to both containers.
So in their own separate worlds, they see the same path.
Container A, your app, writes its unit socket.
The Nginx container says, oh, there's a file in this mount point.
And I'm just going to send traffic to it.
This portion of Talk Python is brought to you by us.
As many of you know, I have a growing set of courses to help you go from Python beginner
to novice to Python expert.
And there are many more courses in the works.
So please consider Talk Python training for you and your team's training needs.
If you're just getting started, I've built a course to teach you Python the way professional
developers learn by building applications.
Check out my Python jumpstart by building 10 apps at talkpython.fm/course.
Are you looking to start adding services to your app?
Try my brand new consuming HTTP services in Python.
You'll learn to work with RESTful HTTP services as well as SOAP, JSON, and XML data formats.
Do you want to launch an online business?
Well, Matt McKay and I built an entrepreneur's playbook with Python for Entrepreneurs.
This 16-hour course will teach you everything you need to launch your web-based business with
Python.
And finally, there's a couple of new course announcements coming really soon.
So if you don't already have an account, be sure to create one at
training.talkpython.fm to get notified.
And for all of you who have bought my courses, thank you so much.
It really, really helps support the show.
So we started with that and you got it working in Kubernetes.
And then you said, well, let's scale it, right?
Right.
So now it's like you got this pod manifest.
And I guess before we did that, we made sure our container worked with Docker.
Right.
And then now we said, let's, how do we get this thing to scale inside of Kubernetes?
So we make this pod manifest and then we submit it to Kubernetes and we watch it just place
it somewhere.
So now that it's placed on the machine, you can now say now Kubernetes is in control of this.
If I delete it, Kubernetes brings it back, right?
To my original specification.
That's way better than getting woken up in the middle of the night.
Of course.
Like this whole on-call thing is overrated.
Like you've never done it before.
Trust me.
It's not something you really want to do.
And I guess to spice things up a bit, I decided to show what does the world look like when you
have an API to control it all, right?
We're not just talking bash scripts.
So this is for the first time I broke out the OK Google, scale the particular application.
And I think a lot of people, if they've been doing this long enough, never thought we would
get to a point where you can just ask for something and do it the correct way.
So part of that keynote, not only did we deploy the app, we scaled it horizontally while having
like curl run in the background, showing the output from the app.
And then we just did an in-place update of the application, all voice controlled.
Yeah.
And I think people were like, wow, we're there.
It was really such a cool demo.
I mean, if you guys haven't watched it, those of you who are listening, you basically pulled
up your phone and you said, okay, Google, connect to Kubernetes.
And you would set up an app or something in the background to like wire your cluster over
to...
Yeah.
So some of the magic behind the scenes is when you have something like the Google assistance
or Google Home, what you're really doing is saying, I'm going to send my speech and
then there'll be a converter that's text to speech or speech to text.
And it sends it to, in my case, I was using a thing called API.ai.
And this is where you design your conversation, all the logic branches.
And that does a bit of ML to take the speech and say, all right, this is your parameters.
This is your intent.
This is your action.
Right.
And then it sends it to a webhook.
And that webhook I just had running written in Python.
I had it running inside of my Kubernetes cluster that would get my intents, like create this
deployment.
Well, what's the name of the deployment?
What's the version of the deployment?
And it will take that and then it will interact with Kubernetes.
And send a response back, which is text.
And when the text hits your phone, it will read it back to you.
So that's how we got the whole theatrical, it reading back what it was doing.
That was beautiful.
It wasn't just like you could talk and it worked.
It would have a conversation with you, right?
Yeah.
So that was kind of the fun part where we would say, you know, I hope the demo guys are on
your side.
And that brings a bit of personality to the system.
Whereas when you run a command, it either works or it doesn't work.
It's very minor.
Status code zero.
Everything okay.
Exactly.
But when you have this thing saying, you know, hey, deployment complete, that was awesome.
And then people were like, oh, wow, that's a bit unique.
Yeah.
So you basically got one of them running in Kubernetes and you said, okay, Google, scale
this five times and five instances of it scaled up.
Then the real trick that I think really impressed people was the zero downtime deployment.
Because I know a lot of companies, when they schedule like deployments, they'll have a page
and say, our site is down for maintenance.
Our people will come in on the weekend and we're going to try to get it back with this four hour
window.
But if it might take 12 hours to deploy it, like that's the wrong way, right?
Yeah.
I think that's a way where we just didn't have a cohesive system, right?
We talked earlier in the show about having that virtual IP sit in front of everything.
So given that, and we have these controls behind the scenes.
So when we do our rolling update and on, and part of the demo, I showed how in engine X, there's
a pre stop hook where you can say, drain the connections before shutting down.
And then we can reject new traffic.
So when you combine all that stuff together, Kubernetes gives us enough cover where we can take down
an instance and then remove from the load balancer, cleanly draining the connections and replace
it with the new version and just do this over and over again till it's complete.
That's where the, like the magic comes.
I see.
That really does make it work well.
I was wondering if you just got lucky and it like, there was that microsecond where one
was down and it wasn't one other, you know, like there was a transitional period where it
wasn't quite right.
But no, you had this very carefully, gracefully shutting down and it already spins up the new
one.
And then it starts.
Yeah.
So Kubernetes understands those semantics.
So what we did in the demo, when I asked Kubernetes to update the version, of course, that goes
with the whole pipeline and we create a new deployment object that has a new version.
And once that's put into the system, Kubernetes says, okay, let's walk through this.
The first thing we're going to do is launch the new version and make sure that it's all
up and running.
So we go from three to let's say four.
So the fourth one is now in the low balancer and traffic is flowing through.
And then we're safe to shut down, let's say number three.
And then we give it as clean shut down hooks and then it's gone.
But while we initiate that process, we make sure no new traffic is allowed to flow.
And this is why we don't actually see those blips or hangups.
That's perfect.
Yeah.
I mean, it's so nice.
Yeah.
That's like out of the box.
So I think now that this is what you get out of the box, we're going to start to see new
functionality as the years evolve or years go by.
People start to try new challenges.
What kind of apps can we deploy?
Maybe even new ways of working develop now that this is automatic and not somebody like
running manually a bunch of things, right?
Exactly.
I did a talk in Paris at a conference called .go and that talk, I had a self-deploying application.
So in that demo, we talked about making a container and you put it on the registry and you write
a Kubernetes manifest and you tell it to do things.
But in that particular talk, I showed an app that deploys itself.
So it's a statically linked binary.
And if you run it on your machine, it will just, hello world.
But if you give it the --Kubernetes flag, it will sense the Kubernetes API that
you may have either mapped in a config file.
And then it will do is create its own container in the background.
It will upload itself, create its own image, and then make all of the configs necessary to
run in Kubernetes and sit there.
And if you have five copies running, Kubernetes has an API to get all the logs.
So you can imagine this thing is now in your laptop running in the foreground and it goes
out to Kubernetes and says, okay, where am I deployed?
Give me all three streams of logs and put them together and stream them to the laptop.
So it looks like it's just running on your machine when in reality it's running on this
distributed system somewhere in the world.
That's a really interesting point.
The logs is also like a big challenge because if you're, anytime you're scaling horizontally,
putting, especially in microservices where it's going from here to there to there, right?
It's like, how do I put back together these requests?
Yeah.
So that's a thing where when people say they want to move to microservice and it's like,
we got to have a conversation.
You're going to go from a monolith where you only have one thing to really worry about to
breaking it up into a bunch of pieces.
So now you got to stitch back together your logs.
And this is where things like trace IDs come in handy.
You also need to do things like, where's it slow, right?
First, you were just kind of in memory, making all these calls between, you know, what's on
the stack or whatever function you need to resolve to, to now it's over the network.
Well, is it on the same machine?
Is it on a different machine?
How do you know?
So this is where things like tracing become very important.
So a client hits your front door.
You may have to talk to three other services.
You want to have some metric to tell you, you've been spending 25% of your time in service
A.
That's your bottleneck.
You might want to think about moving that either closer to the app or putting it back
into the app because maybe you cut too deep.
Right.
It's too chatty.
You're making a hundred calls to it.
That is the number one thing people go from, people have like 10,000 lines of Jason just
flying around the infrastructure because you're passing all these objects back and forth.
And you're like, why is my bandwidth going through the roof?
Or why is it so slow?
Why is it slow?
Yeah.
You just have now Jason parsing as a service.
Jason parsing as a service.
I got it.
Awesome.
Yeah.
So I guess the finale of your demo was to just say, okay, Google, upgrade to version
two.
And it just, all five instances just switched magically.
Right.
And this is the nice thing about the demo is that when I ask it to do that, and when you're
building these voice integrations, you have this idea of what we call a follow-up.
Right.
So if I say a certain word or phrase, it will go down a different logic branch.
So when it worked, I was able to say thank you.
And then it was able to respond.
I got to admit that was pretty dope.
Yeah.
And everyone, you know, gave a good round of applause and then you can just end it right
there.
But if it didn't work, I was not going to say thank you because it would be silly for this
thing to say that was pretty dope.
Thank you for ruining my demo.
Yeah, exactly.
Yeah.
That was really good.
So people listening, definitely go check it out.
I'll link to it in the show notes.
It'll be great.
So maybe we'll leave it there for Kubernetes.
If people want to get started, they have good resources.
You wrote a class, right?
A course?
Yeah.
So I did it with one of my colleagues, Carter Morgan.
We did a Udacity course on kind of a workshop that I used to give hands-on out in the field
for a few years.
And we decided to turn it into a Udacity course so people can learn at their own pace.
And we kind of go through a narrative like you saw in the keynote where you package a
container, you play with Docker a little bit, and you go from Docker to Kubernetes.
And you just kind of go through the basics.
And there's like sections in there where you do a little hands-on.
Then we have some slides and you kind of see how things work at a high level illustrated.
And the goal there is like you learn at your own pace and you kind of really understand what
this thing is trying to do for you.
All those things you have to do hands-on to learn.
You can't just kick back and then know it.
Yeah, exactly.
I think there's going to be a mix of learning.
I tell people it's going to be a little while before you get it all.
But everyone has a different way they like to start.
And I think the course is great for people who like to kind of learn visually a little
bit of hands-on and then have that as a kickstart to go into the deeper material like the Kubernetes
documentation.
I also have a book coming out with O'Reilly, Kubernetes Up and Running.
That's written with the co-founders of Kubernetes, Joe Beta and Brendan Burns.
So we just put the wraps on that.
So that should come out pretty soon.
Yes.
Writing a book is a tall order.
But hopefully it helps more people kind of learn and get up and running.
Yeah, yeah.
I'm sure it will.
And your course, it's free, right?
Yes, of course.
We try to make as much of the documentation free.
And the course definitely falls into that bucket.
All right.
So just because the timing of PyCon and all this was very, very near, I think it was the
same week as Google I.O.
Did you happen to go to Google I.O.?
I'm sure you watched it, right?
Yeah, I watched a bit of Google I.O.
That's a big event for Google.
It does a lot around the consumer side of things, mobile, a lot of the ML stuff that we're doing
at Google in general.
But you know, Python's a special event.
So we actually had a lot of Googlers show up there as well.
You know, a lot of people are into Python.
Python's a big presence on App Engine, the libraries, you know, Google Cloud, the command
line tools written in Python.
So Python has a very storied history at Google.
Lots of people are Pythonistas and will always be.
So that is also a big event that we all mark in our calendars at Google.
That's awesome.
What did you make of like the specialized chips that Google's making and the whole machine
learning AI?
Well, Google's just trying to show a little bit of their secret sauce.
Like Google has been pushing boundaries for a long time.
I think there's a saying at Google, Google doesn't have all the solutions, but we definitely
have all the problems.
So a lot of our problems, if you think about them at a large scale, you get into the situation
where you need to do specialized things like come up with your own chips to process things
faster.
Right?
Like imagine like when you do a Google search, you want instantaneous.
Like if it took even 500 milliseconds, you'd be like, this, what's wrong with my internet?
It was broken.
Yeah, exactly.
So people are very impatient at this point.
So we're always finding a way to reduce perceived latency.
We got to do things and give you accurate results faster than ever.
And that pushes us boundaries all the time.
You've spoiled people for other websites.
You can go to websites that seem like they're not really big or doing much.
And they're like two or three, five seconds to respond.
Like what is wrong with this website?
Oh, two seconds, people leave.
Like if your website comes up for two seconds, people won't put their credit card on a website
that slow.
They just have an instant mistrust and say, you know what?
If you can't load the page quickly, I am not putting my credit card in there.
It's a really interesting point.
I saw a study that says that people trust from a security perspective, software that's faster
and software that is functionally accurate.
They believe it is more secure, even though it's kind of cross-cutting anyway.
Yeah, and I think there's a good reason for that.
I mean, you figure that security is probably the hardest part of the problem.
And if the thing that you think should be the most straightforward part isn't right,
you really have your doubts about the security part.
Yeah, that's a really, really good point.
All right.
So I guess we'll wrap it up.
That was such a great conversation.
I have two more questions before I let you out of here.
Okay.
If you're going to write some code, what editor do you open up?
Vim.
And Vim with no plugins.
Just straight.
No syntax highlighting either.
Like, it's just straight dark with white letters and no helpers.
And I tend to pay attention to every line of the code.
I don't have any blind spots.
Like, you know, my variables are this color or my comments are this color.
So I end up just reading everything top to bottom.
It's probably slower.
But I feel like I know the code base better because I'm not ignoring things anymore.
It's not magically just barely completing with a different word than what you meant.
Nope.
Yeah.
Awesome.
And a notable PyPI package.
There's over 100,000 of them now.
Like, one they maybe run across lately that was really cool.
Well, for the keynote, I actually used the Kubernetes package, which allows you to write integrations for Kubernetes and Python.
And that was a very interesting package, mainly because it's generated from the Swagger API of Kubernetes.
So if you've never used Swagger before, it's a way to kind of instrument your API so they can be, you know, you have this machine representation of, hey, here's every endpoint.
Here's the input.
Here's the output.
And that Python library was generated from that.
And then the documentation is also generated.
So there's an example for every function you have.
And it has pretty good coverage across the board of doing things in Kubernetes.
So that's a well put together package.
And that's what I've been using lately.
All right.
That sounds really, really cool.
People want to check that out.
So good place for final call to action.
Like, people are excited about Kubernetes.
How do they get started?
I think a good way to get started is make sure that you need Kubernetes.
There's a nice little tweet I saw the other day.
A guy had kind of this full size tractor trailer flatbed.
And it was just like a little piece of like wood on the flatbed that it was hauling.
And this is what happens when people are like trying to deploy a very single WordPress on a thousand node Kubernetes cluster.
Like, listen, it's okay if you want to learn.
You know, that's cool.
Yeah.
But you don't need it for everything.
So I would say if you want to learn, Minikyu is a great way to start.
But it's also okay to look at Kubernetes and say, you know what, it's not required for what I'm doing and exit there.
But if it does, it's a good fit.
Like, you're running web instances or you want to have mixed workloads.
You can also do batch jobs on Kubernetes.
You can do these cron jobs on a timer.
So Kubernetes kind of gives you this framework for thinking about running multiple workloads on a single set of machines.
And then you can start going higher up the stack.
So Minikube, find examples in your language of choice, like how to run my Python app in Kubernetes.
That's a really kind of good Google search.
And just take your time with it, right?
You're going to have a long time to really master this thing.
Yeah.
It's something you can get started quick, but it takes a long time to master.
Exactly.
Hello, world.
I always challenge people.
I say, you know, Kubernetes.
This is what I want you to do.
In the language of your choice, I want you to write hello, world, package it, and deploy it in Kubernetes.
And you watch how many people fall over because they don't actually remember all the commands.
And they're still looking for their cheat sheet to put things together.
So make sure you really understand the basics before you jump into all the complexities.
All right.
Well, fantastic.
Thank you so much.
It's been really great to chat about Kubernetes.
And congrats on the keynote.
It was amazing.
Awesome.
Thank you.
Yeah.
Thanks.
Bye-bye.
This has been another episode of Talk Python to Me.
Today's guest was Kelsey Hightower.
And this episode has been brought to you by Rollbar and Talk Python Training.
Rollbar takes the pain out of errors.
They give you the context and insight you need to quickly locate and fix errors that might have gone unnoticed until your users complain, of course.
As Talk Python to Me listeners, track a ridiculous number of errors for free at rollbar.com slash Talk Python to Me.
Are you or a colleague trying to learn Python?
Have you tried books and videos that just left you bored by covering topics point by point?
Well, check out my online course, Python Jumpstart, by building 10 apps at talkpython.fm/course to experience a more engaging way to learn Python.
And if you're looking for something a little more advanced, try my WritePythonic code course at talkpython.fm/Pythonic.
Be sure to subscribe to the show.
Open your favorite podcatcher and search for Python.
We should be right at the top.
You can also find the iTunes feed at /itunes, Google Play feed at /play, and direct RSS feed at /rss on talkpython.fm.
Our theme music is Developers, Developers, Developers by Corey Smith, who goes by Smix.
Corey just recently started selling his tracks on iTunes, so I recommend you check it out at talkpython.fm/music.
You can browse his tracks he has for sale on iTunes and listen to the full-length version of the theme song.
This is your host, Michael Kennedy.
Thanks so much for listening.
I really appreciate it.
Smix, let's get out of here.
I'll see you next time.
Bye.
you
Thank you.