In this episode of Semaphore Uncut, Elton Stoneman, Docker Captain, trainer, and author shares with us some great tips on how to get started with Kubernetes and exciting news about his latest project, Learn Kubernetes in a Month of Lunches.
Elton is a Microsoft MVP, PluralSight Author, and the writer of a step-by-step guide for those just starting out with containers.
We talked about:
- Latest project: Learn Kubernetes in a Month of Lunches
- Kubernetes: The beginning is always the hardest
- Deploying to Kubernetes with Waypoint
- The great challenge of simplifying Kubernetes
- Containerisation future-proofs your app
- Automation: the way to a streamlined deployment process and secure apps
Listen to our entire conversation above, and check out my favorite parts in the episode highlights!
You can also get Semaphore Uncut on Apple Podcasts, Spotify, Google Podcasts, Stitcher, and more.
Like this episode? Be sure to leave a ⭐️⭐️⭐️⭐️⭐️ review on the podcast player of your choice and share it with your friends.
Edited transcript
Darko (00:02): Hello, and welcome to Semaphore Uncut, a podcast for developers about building great products. Today I’m excited to welcome Elton Stoneman. Elton, thank you so much for joining us.
Elton: Thanks for having me. So, I’m a return visitor. I’ll do the new introduction for folks that haven’t heard of me before. So, just releasing a new book. The last time I spoke to you, I’d written a book about Docker, and I’ve just finished the sequel to that book, which is about Kubernetes. I’ve done the first draft, and it’s going through all the review process, so it’ll be out at the start of 2021.
It’s published through Manning, and they have this kind of early access program, so you can sign up and read all the chapters now. I was very keen to write this book; I’ve been using Kubernetes a lot for the last few years. I think people get frustrated with the big jumps in the learning curve. And Docker’s fairly easy, running an app on Kubernetes is fairly easy, but then configuring it and understanding all the other bits and pieces, and the bits of the ecosystem you need to bring in – I think people get frustrated that there are so many jumps.
Hopefully, the goal of this book is to guide you from, whether you’re a zero or whether you’re a relative beginner, to guide you through that whole learning curve of Kubernetes, to how many people use it in reality. And the other thing is you need to learn to be able to be successful with it but try and make it interesting. So that’s the goal, quite an advanced goal.
New book: Learn Kubernetes in a Month of Lunches
Darko: Can you maybe give us a more in-depth overview of the book’s aim, on the expectation that’s setting?
Elton: The book is called Learn Kubernetes in a Month of Lunches. Manning had this month of lunches series, my last book was Docker in a Month of Lunches. The idea is, there are 20 chapters, it’s very hands-on, so there are lots of exercises to do, every chapter finishes with a lab for you to go and test what you’ve learned, all that sort of stuff – lots of exercises to work through. The idea is you should be able to go through the chapter in about an hour, so nominally, in your lunch break, and then over a month, you’ll have the whole thing. That was fine for the Docker book because you can focus on these little topics, and in an hour, you can cover that in a lot of details. Twenty topics for Docker, you can cover everything at a fairly decent level.
With Kubernetes, it’s a bit different because it’s such a vast topic. What I wanted to do is get that balance between teaching you enough that it’s useful and giving you an authentic experience of using Kubernetes. You’re going to use Kubernetes a lot if you follow through the exercises. If you’re completely new to Kubernetes, you can read this book, follow the exercises, and then move on to a team that’s using Kubernetes and be comfortable. Be comfortable with what you’re doing and how they’re working. So, it’s trying to give you that kind of authentic experience. Each chapter is a self-contained topic, but I didn’t want to restrict myself, to say, “Each chapter has got to be 5,000 words. It’s got to be 60 minutes.”
The chapters are bigger. I do go into a lot of detail around those individual topics, but it always starts from somewhere simple, with an overview, a bunch of diagrams and then into all the exercises, and then finishes off with a step back to look at what we’ve done. I would hope it’s getting that balance of being approachable. It’s not targeted at developers or operators, or Java people or .NET people. There are examples in all sorts of languages for all sorts of people from different backgrounds, so I hope it helps people on a learning journey. But at the end of it, it gives them something that they’re confident to go on with in their career, because that’s the whole point of it.
Kubernetes: The beginning is always the hardest
Darko (03:41): It should make it much easier for people to get started. And, as you mentioned, get hands-on experience.
Elton: Yes, I’ve been teaching Docker and Kubernetes at workshops, and for clients, for many years. And I think that doing it yourself helps. All the content for these books, all the source code for the applications, the Kubernetes manifests, all that stuff, it’s all on Github. You can still work through and see how all these things work. And I try not to duplicate things you can find elsewhere. I don’t go into details about all the YAML specifications for Kubernetes because the API docs are the place to find that. What I’ll do is, I’ll say, “Here’s the YAML file, here are the five lines that are important for this particular topic, and this is how you’ll use them in production. This is what happens if you don’t include this.” That sort of stuff, and then go to the Docs for the next level of detail. But by then, you’ll be familiar with the core topics.
I think there are different levels of the desirability of the knowledge of the tech stack you’re in those environments. And because the old definitions are becoming blurred, you don’t have developers who have no understanding of the operations anymore, and you don’t have ops people who have no understanding of the build. Especially if you’re looking at CI/CD stuff, I think that’s all becoming blurred, and you need to take that step forward.
You hear a lot that people find Kubernetes complex, and the learning curve is steep. And then you get to other people who love that stuff, who love being able to dig into something, learn a new skill. It’s actually a really great product when you dig into it more and more. You’re getting a world-class platform to run your applications. And all you’ve got to do is learn some YAML. I think people like that as well. And I think there are all these various points, where you start learning these pieces that Kubernetes fits together for you, and you’re wondering why it’s so complex. You’re wondering why there are so many abstractions layered upon abstractions. When you realize that the reason you have a pod to run your containers is so that the pod can restart a container or replace a container, and you can run multiple containers in your pod, enabling all sorts of different plans, then you go, “Ah, now I understand why that abstraction is there.” And that keeps happening as you’re learning more and more about this stuff. For techie people, whichever background you’re from if you like digging into the tech and there’s a lot there for you.
So even though it is complex, the payoff then is that once you’ve learned your Kubernetes well enough and you know the management side of it, and you know the modeling side of it, and your YAML files, you can go to any project in your organization and pick it up straight away. And any other organization, and anywhere from joining an established team and running their stuff in Kubernetes, to helping a new team bring their things to Kubernetes. Once you’ve learned the skill, you’re done. And you can run that in any cloud, data-center, laptop.
Deploying to Kubernetes with Waypoint
Darko (13:07): Something we also touched upon was abstraction layers on top of Kubernetes. I’m not that deep into the Kubernetes community, but I feel that there were a couple of waves to bring some level of abstraction, make it more approachable, or simplify things. And you just mentioned the project from HashiCorp that was recently released, Waypoint. Can you give us an overview, how you see all those previous waves of abstractions and why they’re interesting? Then, what’s next?
Elton: The thing that people find difficult with Kubernetes is the modeling language. You model your applications in this YAML file, which says, “I’m going to run this number of these containers, and we need this type of storage. And then networking is how these things are plugged together.” It’s all described in these YAML documents, which can get big and difficult to work with. You can be talking with hundreds of lines of YAML to model this application.
The payback, of course, you can run that anywhere, and it’s effectively the same thing that you’re running, Azure or AWS, or wherever you want to run it, you can literally take your app and spin it up somewhere else using the same modeling language. But you’ve got all those hundreds of lines of YAML to maintain. There have been several different attempts to either abstract that away and have a simplified layer on top of it, or to augment it in some way so you can kind of simplify it down. There are projects like Ksonnet, an attempt to describe the modeling language in a different way. Some projects can take Docker Compose, which is an alternative way of modeling your application for a container runtime, but much simpler, and convert that to Kubernetes for you.
Waypoint is the new thing from HashiCorp. It’s trying to give you that ability to model your application and abstract from any kind of runtime. With Waypoint, in theory, you could model your application once, you can use that same definition to run it in Docker Compose on your laptop, and then take that to Azure and run it in the cloud. I think all these things are really interesting, but the ones that have fallen away, it’s just about the uptake, and sooner or later, you’re going to have to dig down into the detail.
The great challenge of simplifying Kubernetes
If you’ve got a complex app to represent, the beauty of the Kubernetes is you can represent it in all its complex glory in all those YAML files.
People really want to simplify it, but it’s not a simple problem. You can’t just give people all the flexibility in all the configuration options in a simplified version because sooner or later you’re going to need to dig down in that, I think. Certainly, conventions that you can apply across the board, things like that make a lot of sense, but my feeling is they’re always destined to have a smaller audience than the full modeling language. The people who can learn Kubernetes, because they’re trying to use it everywhere, going to learn it inside out, and they’re not necessarily going to use a simplified version because it doesn’t give them what they need.
A smaller number of people will adopt Waypoint or Compose with the goal to deploy into Kubernetes until they find there’s something they can’t configure, and then they have to make a choice. “Do we use Waypoint for all our non-production environments and then a full Kubernetes specification for production?” And then you end up with things getting out of sync. So yeah, I think the whole area is complicated. Unless it’s exceptionally well done, I can’t see an abstraction with a goal of simplifying the modelling language is ever going to work. Because the modelling language is complex for a reason, it gives you all those features. So yeah, I’m interested in how our Waypoint goes because all of HashiCorp stuff is great technology. So, I’m going to follow that, but I’d be surprised if it has the widespread adoption of a Compose or a Kubernetes spec.
Kubernetes is not the end, but I think something will come that does that in a simpler way. I mean, simpler is the thing that people want. If you look at the recent releases of Kubernetes, some of the stuff they’re writing now, which is really neat stuff. Like the ability to say, “My web application runs in a container, it uses an API. So ideally, when it connects to that API, connect to the pod on the same machine or the same nodes, so I don’t have to do a network hop. But if you can’t do that, then at least connect to a machine in the same region. And if you can’t do that, because there’s none available, then go over here.” Again, you can capture that in the modeling language. Well, that’s a pretty low level of detail that you need to get to.
Containerisation future-proofs your app
And all the simple stuff has all been done, and done really well. So something will come. I would hope that that thing that comes will start from the point of, “Well, you’ve got your application model during Kubernetes, and now you can take that and bring that with you.” Well, hopefully when you package your app, or your application component, to run in a container image, that should be the last thing you have to do, because then you can run that in Kubernetes or whatever it comes in the future is going to be a container platform. So I would think that the journey is that you’re going to learn this stuff and then to apply it to your existing projects, I think that’s going to future-proof you for a little while.
If you listen to some of the big players in the Kubernetes community, they talk about the API, they talk about that modeling specification as the thing that you should care about. Because if you’re saying you’re in a cluster, then you need to understand the internals of Kubernetes. You need to understand how to pull your cluster and add servers, and how you do a rolling upgrade of Kubernetes and all that sort of stuff.
But if you’re already in the cloud, you don’t need to know that. Because you would just spin up a managed Kubernetes cluster with X number of Linux servers and X number of Windows servers. And when it’s time to do a rolling upgrade, your provider will take care of that for you. You’ll set up maybe some new nodes in the new version and gradually move your workloads over.
But the interesting thing there is, you don’t need to know about the cluster underneath. If you listen to Kelsey Hightower and some of the people who were thinking about the future of Kubernetes, it’s about the API. And you will throw your YAML specifications somewhere, and everything will just run the way it always has, but you won’t need to manage a cluster. I think going forward, Kubernetes is just so big that whatever comes will have to be supportable with Kubernetes’ manifest, so I think it’s a safe bet.
Automation: the way to a streamlined deployment process and secure apps
Darko (23:55): From experience, production experience, of using Kubernetes cluster for three years, for running Semaphore, I could say that probably in three years, it will still run just great with the same YAML’s. So, it’s not as scary as it sounds. You need to take care of the majority of things once and then polish the pieces as your architecture application grows.
Elton: Yes, one of the great benefits is that stability with your API. And the other benefit is that because Kubernetes moves so fast, and because the container images that you base your own applications on have their own life cycle of being updated every month, it forces you into regular updates. With Kubernetes, you’re going to need to replace your cluster every year because they only have support for the previous minor releases for six months. You’re going to have to get used to tearing down production and spinning up a new environment with the new versions. You’re going to have to get used to the idea that an update of your own application means replacing containers. And then you get into this idea that deployment is something that is streamlined and standardized and not scary because you just do it all the time. It doesn’t matter whether it’s an update to the operating system image or the application platform that’s had a new patch; it’s all the same process to do the updates. It’s all automated. It all happens every day. I think that it just forces you to go down that route. And it means your apps are more secure, and it’s easier to deploy updates, and everything just becomes nice and standardized.
Get your free copy of the book
Darko (25:44): Elton, you mentioned the book is power is by Manning, and we have a special code for our listeners. The state is that it’s in the early preview.
Use the special code podsemaphore19 to get 40% discount for the Learn Kubernetes in a Month of Lunches book or any other product from Manning Publications.
Elton: Yes, all the chapters are written. So, you can go to this technical preview, you can go to the website now. You don’t even have to buy it; you can start reading the chapters online. And then if you want to, you can buy it now, and as soon as it’s released, you’ll get the full version.
Darko (26:13): Great, good luck with publishing with the book.
Elton: Thank you.
