004 - Why Kubernetes

Today we bring you the audio from “Why Kubernetes,” a recent webinar by Pluralsight author Nigel Poulton. If you’ve been looking for a primer on Kubernetes, this is it.

• Watch the full “Why Kubernetes” webinar
• Docker and Kubernetes: The Big Picture
• Docker Deep Dive
• Docker Desktop download
• How Kubernetes can future-proof your development process

If you enjoy this episode, please consider leaving a review on Apple Podcasts or wherever you listen.

Please send any questions or comments to podcast@pluralsight.com.

Daniel

Hello, and welcome to All Hands on Tech, where today's leaders talk tomorrow's technology. Today, we bring you the audio from, "Why Kubernetes", a recent webinar by Pluralsight author and Docker captain Nigel Poulton. If you've been looking for a primer on Kubernetes, this is it. Nigel also tackles tons of audience questions, so make sure you listen through the end if you want to catch those. This audio has been edited slightly for an optimal listening experience. If you're interested in watching the full video version of the webinar, there's a link in the show notes. Nigel also recently published a vlog post on the power of Kubernetes, so we'll include a link to that in the show notes as well. All right, please enjoy.

 

Nigel Poulton

So, to frame this discussion right, I think we need to step back a bit and talk about why Kubernetes initially came into being, so the story of why Google needed to create Kubernetes, and why it needed to contribute it to the community as an open source project. And I think, probably, why we talk about that, why everybody else like, I don't know, Microsoft, and IBM, and even like the Iron Mountains and the Colo data center providers of the world, why they also needed Kubernetes. Because, once we understand those things, like why, I don't know, why the world needed Kubernetes, like Microsoft and Google, and all those people, that will give us some context as to why you and your company probably needs it as well. Wind your clock back just for a minute, and let's talk about why Kubernetes came into being.

Think about when Amazon was this upstart online bookstore. Do you remember those days? I mean, some of you might be, maybe, too young to remember it, but those are fun days for me. A few years ago, I don't really remember how many, I'm going to throw a number out there, seven, eight, nine, 10 years ago, but I used to run a weekly infrastructure podcast, and this was when cloud was just becoming a thing. You might remember, back in day when we all talked about cloud, but most of us, and I include myself here, most of us didn't really know what it meant, so we would use the word, the buzzword, and not really know what it meant. Anyway, look, we're on this podcast, and one of my co-hosts, Mark Farley, was talking about Amazon being a cloud company. And I thought I was clever, and I called him out saying, "Listen, look, this is all hype. Amazon's an online bookstore."

Now, Mark, clearly had way more vision than me, and he basically called me a fool. And he wasn't wrong. I mean, he wasn't wrong on so many levels, actually, but, he definitely wasn't wrong that I was a fool by thinking that Amazon was just a book selling company. So, amid all this hype around cloud, and folks like me throwing the term around without really knowing what it meant, amidst all of that, Amazon was building this cloud thing that was about to change the world. And part of that changing the world meant that they were about to start eating a lot of people's lunch. So, in building Amazon Web Services, Amazon was about to take a huge old bite out of the lunches of all of the incumbents, like Microsoft, and Oracle, and Dell, and HP, and all of those guys. Obviously, those guys didn't like the sound of that. Nobody likes somebody else eating their lunch, so they needed a play. They needed something that would let them take on Amazon Web Services, and if you don't mind the term, prevent the bleed. 

Now, one possibility came in the guise of OpenStack. I'm going to keep this high level, but at a high level, OpenStack tried to go toe to toe with Amazon Web Services, what was almost an open source feature for feature rival for AWS. But I think the idea in OpenStack was to build something that looked and smelled as much like AWS as possible, or make it something that you could install yourself on premises or wherever you liked. And, don't get me wrong, I'm sure it was great tech, and it was certainly a noble effort height, and it's still going to some extent today, but it needed an army of developers for you to be able to build and run it. And I'm really not just talking about regular developers here. These had to be hardcore developers that spent their time hacking the Linux kernel. And people like that tend not to be cheap, and I'm going to be cheeky here, sometimes they're not super easy to manage either. No offense, if you're one of those people. I doubt you are. But, I think in essence, OpenStack, while it was a noble effort, was the opposite of what Amazon Web Services was, because Amazon Web Services was point and click, and give us your credit card details, and you're up and running. OpenStack was not there. 

Back to the story: we've got Amazon building AWS and eating everybody's lunch, OpenStack's trying to take it on, but also, in the background, we've got Google. So, Google has a couple of internal systems called Borg and Omega, that are basically running and managing all of this stuff behind Google search, and Gmail, and all of that stuff. Internally, Google are running a couple of projects, Borg and Omega schedule all of the containers that run their infrastructure and applications, we've said, search, Gmail, GFS, whatever. But with it being Google, this is at massive, massive scale. While Google's running all this, they're obviously watching the market and seeing what Amazon is doing, and they're thinking, "Well, heck, yeah, we'd like in on this cloud business." But the problem is, Amazon's got a start on everybody, and they're way out ahead. And, if you've ever been in a situation like that, catching up is always really, really hard.

So, we've got OpenStack, but you know what? It's not looking like it's going to make a dent in AWS. So, Google thinks, "Well, I'll tell you what, let's take everything that we know about running infrastructure and applications at scale, with our internal tools, Borg and Omega, and we'll use all of that knowledge and skills, and we'll build something new, and we'll donate it to the community as open source, and then we can use it to abstract away AWS, and maybe even use it, I guess, as an on-prem to Google's own cloud." And thus Kubernetes was born from out of Google. In no way am I saying that this was Google's only, or its primary motivation for creating Kubernetes. I mean, listen, I know the folks that were involved in Kubernetes, and also Borg and Omega as well, they're passionate about technology, they're passionate about community, and they're passionate about open source and all that goodness, but, for sure, Google is a business, and part of the plan was to abstract away AWS, and make it easy to onboard workloads to Google's own cloud by abstracting away Amazon Web Services. 

What am I talking about abstracting away? What I mean is, you take AWS or, look, bare-metal, or even VMs, we've got them all on the screen, whatever, you'll layer Kubernetes on top of it, and you know what? You don't have to care what is below Kubernetes anymore. So, you can have Kubernetes on-prem and in the cloud, and you can run and migrate your apps, I don't know, to whatever cloud you want, between clouds, between on-prem, all of that jazz. I'm going to caveat this; if you're running your applications on AWS or whatever, and you've got Kubernetes, what you're also consuming other AWS services directly, services that Kubernetes doesn't abstract away, and of course, migrating your entire app away from AWS, or whatever cloud platform you're on for that matter, is going to be non-trivial. However, if you're running your apps on Kubernetes, and you're not buying into all these extra add-on services from whatever cloud provider you're on, then look, absolutely yes.

As long as you've got Kubernetes somewhere else, you can easily migrate your application workloads. So, Kubernetes was born out of Google, from all of the lessons that they learned with internal tools like Borg and Omega, that they use to manage their own infrastructure and applications. Kubernetes is written from the ground up. It is not Borg, and it's not Omega, repackaged and donated to the community as open source. It is all the lessons learned from those, and then said, "We've learned a ton, let's build a new product from the ground up as a cloud native platform that lets people run and scale modern apps on-prem or in the cloud, and you know what? Even on your laptop if you need to." And as well, like we said, it makes migrating to new clouds, and data centers and the likes, very, very simple. 

In summary for this section, AWS, they invented the cloud, or at least they brought it to mere mortals like us. All the incumbents were caught sleeping. Google donated Kubernetes to the world, open sourced it, and, as we speak today, I mean, this isn't just me, but Kubernetes is the de facto platform for running cloud native applications. If you want to build and run modern applications, the buzzword for those is, well, they tend to be cloud native micro services applications, but don't let the buzzwords put you off. The crux of that is, applications that can react to events and scale up and down according to demand. They can self heal when infrastructure breaks, and they can even self heal when the application itself crashes. So, we may be talking about this a bit later, but self healing when infrastructure breaks, and self healing when the application itself crashes. Oh, and I'm talking about self healing without anyone even noticing. So, no call at three o'clock in the morning, and when something breaks. Kubernetes can just fix things without you even knowing.

Well, if you want that, then, cloud native micro services on Kubernetes is what you want. If you want things like zero downtime rolling updates, with version roll backs, and things like canary deployments and stuff, then again, Kubernetes is what you want. Like we said, look, it's open, and it lets you use a cloud, or it lets you maybe choose a cloud today without having to live with that decision for the rest of your life. So, if you make a decision on a cloud, and you feel like it's the wrong one, then you can put Kubernetes somewhere else, and potentially, very easily, move your application to that new cloud, or even on-premises if you need to. I think that's the background as to, why Kubernetes? I think when we understand the need that the ecosystem, and I think earlier on, I called it the need that the world had, so the need the world had for Kubernetes as an open source, pretty much ubiquitous platform that avoids locking, and it lets us build and manage modern apps, and makes migrations easy, these are pretty much requirements that resonate with most modern businesses. 

I'm just going to check for questions before moving on. So, okay, lovely. So, I've got a question here, what does the term cloud native mean? This is really good. And, if any of you ever take any of my courses, which I'll point you to later, I am super keen at clarifying what buzz words are. So, I think I said before that, we tend to call these modern applications cloud native micro-services, but, I don't know, it was, like I said, the crux of it was, blah, blah, blah, blah, blah. So, cloud native is any kind of application that can deal with modern demands and requirements. So, think of things like, if you need your application to scale on demand, then that's an attribute of a cloud native application. If you'd like your application to self heal there, and I'll run you through some examples later, what that would be, self healing would be an attribute of a cloud native application. 

Just because an application is branded as cloud native does not mean that it will only run on the cloud. A cloud native application will run anywhere that you have Kubernetes. So, if you have Kubernetes on-premises, in your own data center running on bare-metal, you can run a cloud native application there. So, I would say, a cloud native application is one that is built to deal with modern day demands, modern business demands, ability to scale, the ability to self heal, and react to market conditions, but also, it tends to be written in a very modular way. So, let me just wind the clock back a little bit here as well. Traditionally, we would build applications as what we would call a monolith. That would be where we would put all of the logic of the application into one big binary, or one big computer program, to keep it high level. So, maybe your web front end that you talk to from your laptop or your phone would be in there, and then the database would also be included in the application program, and any search features, and any authentication, all gets bundled together. And what that meant was, anytime you wanted to, I don't know, upgrade the web front end, you had to upgrade the whole thing. And it was like a full weekend of work with everybody in the office performing the upgrades, and it took hours and hours and hours.

And then next week, if there was a bug in the database, and that had to be updated, again, you'd have to take the whole thing down. So, a tentative cloud native applications is that you build them out of small specialized parts. So, you would have, maybe, a small team of people that would build a web front end, and another team of people that manage the database, and other team of people that manage search and cataloging, and authentication, stuff like that. And all of these little specialist parts talk to each other, and they form that bigger application, so you get the same application experience, but it's lots of small things on the back end. And why that is important is, let's say you need to take the web service down, and you don't have to take the entire application down with it. And, this kind of a pattern of building applications out of small specialized services that talk to each other, is really enabled us to scale and self heal, and push updates far more frequently than we could with the older, I guess, monolithic applications. The fact that it can run anywhere on any cloud, even on-premises really, if you have Kubernetes.

Alright. So, somebody's asking, "If you don't want to run apps in the cloud, is there an on ..." So, the term is on-prem or on-premises. You can absolutely run Kubernetes on-premises, which means not in somebody else's cloud. If you want to run it on-premises, that would be in your own data center. So yes, you can install Kubernetes in your data center, it does not have to be on a cloud. 

"Any thoughts about how managed services by cloud providers may affect reusability of Kubernetes?" A lot of the big cloud players at the moment are offering Kubernetes as a service. So you can go to Amazon Web Services, or Google Cloud, or Azure, or DigitalOcean cloud, all these places, and within a couple of clicks, they'll give you a Kubernetes service. And they manage it all for you, and they just expose the bits that you run your applications on. Fortunately, and I hope I'm addressing the question here, all of these players are committed to keeping the Kubernetes that they offer you as vanilla or as plain as possible, so that, if you don't like that cloud, you can move your applications and run them somewhere else. The community actually have been really good at not locking people into their flavor of Kubernetes. Hope that answers the question.

Another one, Swarm versus Kubernetes. So, Kubernetes has all of the momentum, and it's got all of the ecosystem support, but Kubernetes is quite big, and it's quite challenging to implement and learn in comparison to Docker Swarm. So, Docker Swarm does a lot of the things that Kubernetes does, and it's super simple to install and get up and running. And for a lot of use cases, and I think especially smaller use cases, Docker Swarm might be the answer for you. What locking at long term roadmaps, and where the community is locking in all of the investment going forward, I think, Kubernetes is, generally speaking, going to be the safer choice. 

Can I define Kubernetes in one sentence? Yes, a really long one. Now, it's a platform that lets you run modern applications anywhere that you need to run them, and it will look after your applications for you. I'm hopefully going to give you some examples a little bit later that might shed some light on that. Repost the question again at the end, if I've not really answered it there. But you run your applications on Kubernetes, and Kubernetes hides all of the virtual machines or physical machines and stuff below, and it provides you a loads of features that let you scale and self heal, and do rolling updates and stuff like that.

"Do you mean to say a container is different to a VM on a cloud, if so ..." Yes. Okay. Super good question, actually. Is a container different to a VM? Yes, it is. So, containers are much smaller than virtual machines, and much more lightweight. I should say, by the way, here, we'll come to this later, but I've got a ton of courses in the Pluralsight library that go over all of the basics here. Lovely pictures and animations, and me spending all the time in the world explaining it nice and clearly, and not trying to rush here. But, yeah, a container is much more lightweight than a virtual machine. So, every virtual machine, if you've got 10 virtual machines, and they're all running Linux, that's 10 copies of Linux, the Linux kernel, the entire file system, all that jazz. Containers don't contain their own kernel or anything like that. They're much smaller. They all just share the kernel of the machine that they are running on. I understand this is getting super technical. 

Okay. So, let me just get back to my slides here so I can get to where I was looking; the impact of Kubernetes. Let's talk about you and your organization. I mean, look, I love technology, and Kubernetes is really cool technology. So, from a technology perspective, highly recommend it, super cool and all that, but you know what? I live in the real world, and I know that that is not a real reason to spend precious corporate resources and energies on. However, I do think the fact that Kubernetes is a juggernaut, is a reason that you should be investing in it, or at least, I don't know, being aware of it and having it firmly on your radar. Make no mistake, Kubernetes is coming, and if you'll excuse the pun, look at the screen, resistance is probably futile. Now, I personally see containers and Kubernetes as being as inevitable as virtual machines were. I mean, it's just such a no brainer, and, I don't know, I just feel like you'll be the one missing out if you don't adopt them.

Look, just take a moment to imagine where you might be if you'd passed over on the virtual machine revolution. If you were still stamping out applications on a one app to one physical machine approach, your time to market, I mean, it'd just be scary to think about, and your costs would be astronomical, and I think your impact on the environment would be questionable as well. So, I think that containers and Kubernetes, and the associated revolution, is similar to what we experienced with virtual machines. You really won't want to be rocking your business without Kubernetes and containers in two or three years out. I really believe that. From the perspective of an organization, the benefits of Kubernetes have been, I think, probably laid out somewhat already. It's infrastructure agnostic, and we said it was designed for modern applications to deal with dynamic modern business environments, all that jazz, and who doesn't want all of that, seriously. It really is the safest and most wholly independent, and most flexible platform to build on as well. And it gives you, I think, a bunch of future proofing, as much as anything can future proof you, of course. 

I'm using words like, or I'm saying it's the safest platform, and it's the most independent platform, because it's open source, and it is looked after by, I guess, a foundation called the Cloud Native Computing Foundation, which, if you don't know, it is a consortium of sorts. It's made up of the who's who in the technology world. The Cloud Native Computing Foundation owns and locks after the direction of Kubernetes. I'm being a bit high level here. What that foundation, has members from just about every tech company in the industry. So, in that respect, its overall interests are the wider community. So, maybe it's easier to think of it, it is not owned and controlled by any one major player with their own interests in mind. And Kubernetes were very careful and clever, I think, when they donated it to the community, and effectively built the Cloud Native Computing Foundation, because that has really protected it from Google saying, "Well, we've got this awesome piece of technology here, and let's use it for just our own purposes."

So it really has got a very open approach, and a very gentle approach as well. You're not going to have massive lock-in. To give context as well, a term that's increasingly bandied around, is that Kubernetes is becoming the Linux of the cloud, in the same way that Linux became pretty much the de facto platform to build applications on. And, look, when I say this, I mean no disrespect to Windows. I spent my life with windows in the past, and I'm well aware that it's been a stalwart servant to the enterprise for many, many years, Microsoft even themselves these days, are treating Linux like it's some long lost child. Microsoft can't give Linux enough love, it seems, at the moment. I say this a few times to people when I'm talking about this, if you're an alien visiting planet earth for the first time, and bear with me on this, and if you had an interest in tech ... I mean, you're an alien, so I'm assuming you would be interested in tech, maybe not, but if you were, you could well go home to your home planet thinking that Microsoft pretty much invented Linux. That is how much love they're showing it these days. 

Anyway, look, I'm waffling. Let's get back on track. In the same way that Linux is arguably the operating system of choice for writing cloud native applications, Kubernetes is the platform of choice for running those applications. You write your modern applications on Linux, as containers, and then you run them on Kubernetes, and Kubernetes lets you run it pretty much anywhere like we said. Now, let me be clear for a second, I'm using the term platform, which I fully appreciate can mean different things to different people. You can run whatever infrastructure you want here at the bottom, VM's physical machines, instances and your cloud, it doesn't matter. Kubernetes does not care. You lay a, excuse me, Kubernetes on top of that, and then on top of Kubernetes is where you run your applications. Mostly, these days, those applications are going to be containers, but you know what? Kubernetes is pretty skillful. It can run virtual machines if you need it to, and it can run functions as well, if that's what you need, functions or serverless workloads. But mostly it's really containers these days.

Now, in doing this, Linux apps running as containers on Kubernetes is becoming more and more the thing. It's properly, is the real deal. However, as with anything in technology, you don't get there overnight. Getting there is a journey, and it is a hard journey sometimes. So, the sooner you start, obviously, the better. Because, if your business relies on technology, then, honestly, you need the freedom and the portability and all the funky stuff that Kubernetes brings and enables, those buzzwords again; flexibility, scalability, self healing, zero downtime updates, all of that kind of stuff. And I'm saying that you need them, because your competition is going to be getting them, if they haven't already. And in today's competitive business world that relies so heavily on technology, any advantage you can get is important, but, with Kubernetes, we are fast approaching the point where it's just going to be table stakes. So, if you don't have, then you're going to be lagging behind.

But if you just think where you as an individual in your career, and also where you as your organization would be, if you hadn't taken up with virtual machines, well, containers and Kubernetes are similar, but driving even more fundamental changes. So, if you thought not taking on virtual machines would have left you behind, not taking on containers and Kubernetes is going to leave you way behind as an individual, and as an organization. And, look, like I said with virtual machines, you're talking longer release cycles, all of that kind of badness, paying more than you need for physical infrastructure and stuff. Nobody wants any of that. I have also been a hiring manager in the past. Well, as in, I've had technical roles where I've led teams and I've had to hire people. I know that when that was me, I wanted to hire top talent, but top talent wants ... Well, look, I mean, it wants other things, of course, but top talent wants to be working with the best technology, and on the most interesting projects. Usually, when I was hiring in the past, I have had good budgets for headcount. And I've even been in prime central London locations with good budgets, and I've still struggled to get the right people, because, sometimes, the right people that just didn't want to work with the technologies that we had at the companies I was at.

We offered good money and a great location, but they wouldn't come because they wanted to be working with better tech. So, if you, as an organization, or as an individual that hires people, if you value good talent, then the good talent is going to be wanting to work with containers and Kubernetes. Listen, I'm talking about your existing staff as well, so, get those guys trained up, and keep them happy, and keep them at your company, because replacing them can be hard. As an organization, I feel you need to be going with Kubernetes and containers, and you need to be keeping your existing staff happy, and trying to get new talent in through the door, and, look, Kubernetes is a great way to do that. It's not the be all and end all, of course, it's not a guarantee, but top talent is going to be attracted to Kubernetes and containers increasingly going forward.

On the personal career front, jobs in containers and Kubernetes, they pay well, that's no secret. So, as an individual, that's a no brainer for you. You also tend to be the more exciting projects with the companies that have the best coaches. Now, listen, I'm making broad sweeping statements here. There's obviously good and bad everywhere, and taking a job at a company that uses Kubernetes, for sure, it's no guarantee it's going to be a great place to work, but, generally speaking, the exciting work of the places that value innovation and technology, they're doing it with containers and Kubernetes, as well, it locks for everything in the world, like Kubernetes is here to stay, and all the trends are pointing towards it practically becoming ubiquitous. So, I'm pretty confident in saying, Kubernetes is probably the best place that you could invest your training budget. Now, I'm talking here both as an individual, so, your own personal training budget, as well as within your company. So, get yourself and your teams trained and up to speed on Docker and Kubernetes.

Speaking of which, how do you even get started? Because it's no secret, I think I hinted at it earlier, learning Kubernetes and reworking your existing applications, and deploying new applications as containers on Kubernetes, can be a steep learning curve. Clearly, you're at the right place here with Pluralsight. I'm going to say, if Kubernetes is the de facto platform for modern cloud native apps, I think it's pretty fair to say that Pluralsight is the de facto platform for learning technologies like Kubernetes. I mean, the Pluralsight library at your disposal is just outrageous. The sheer breadth of offerings around containers and Kubernetes is the absolute business. Obviously, there's more than what I'm going to show you here by more people than just me. So, go and check yourself, like Daniel was saying. Docker and Kubernetes, the big picture here is the best place to start if all of this is brand new to you.

This course, if you take it, it explains all of the buzzwords that we've covered here, like, what does it even mean, like we were asked before when I say things like cloud native or microservices? Well, that's all in this course. It's your DevOps one on one, but I think, it's ideal for those of you who were also potentially in non-technical roles, like you might be senior management, architecture, or even a C level role. You can look at this course as almost an executive summary of Docker and Kubernetes. So, I'd make a promise to you, if you take it, you won't need to pretend anymore that you know what all the buzz words mean. They're all explained in detail with pictures, and you know what? It's a really fun course as well actually. People tell me they catch themselves grinning and even laughing out loud sometimes when they're watching. And a couple of others, though, on the Docker and containers front, because Kubernetes uses Docker very heavily, Docker deep dive on the left here is an absolute gem of a course. And getting started with Kubernetes is just magic. 

Again, the feedback has been overwhelming, and a common theme has been that they're really fun courses to take. I don't know if you're picking up from the webinar here, but I'm really passionate about this stuff, and that shows through in the courses, and I'm all about making learning as fun as it can possibly be. Technical people needs to get their hands on, and I'm telling you, we live in an amazing world where there's just a host of options here as well. Gone are the days of needing to feel like the corner of your garage with noisy power hungry hardware, if you wanted to get your hands on with something, those days are way in the past. Today, you can spin up a Kubernetes cluster pretty much anywhere. So, I reckon, probably, nearly every day I use Docker desktop. It's a free download from docker.com, and it gets you Docker and Kubernetes on your laptop. Now, if Docker desktop's not an option for you, then play with Docker, and play with Kubernetes. Just google both terms. They're on the internet, and they give you a free time limited cluster that you can play with. 

Then there's things like Magic Sandbox, for a fee, so you have to pay for things like this. But Magic Sandbox, you get your own private Kubernetes cluster to play with, plus a bunch of curated lab exercises and stuff to follow along with. I just think we live in a great world today. One where Pluralsight has done such an amazing job of building this library of videos that can teach you just about anything. I mean, what I would have given for a Pluralsight library when I was younger learning IT. But then when you need to go and get your hands dirty, Docker desktop, all these things on the screen ... I mean, I literally remember begging for a PC from my boss when I was learning Windows NT, and racking it up in the corner of my bedroom with one of those huge old monitors that weighed like a ton. My wife was like, "What are you doing?" I was like, "Well, I've got to learn the job."

There's none of that now. We live in such a better world. So, within your organization, and I think, probably, even personally, you need to pick a project to start on. And like anything else, I'm going to warn you, start small, but you'll never finish. And I mean that in the fact that, technology in business is always changing, so, no matter what project you start within your business, whatever you tackle first, there's always going to be something else to do, and it's a never ending round, and I love it. But generally speaking, within an organization, and of course, this all depends on the size and structure of the organization, but if you're a medium to a large organization, you probably want to set up a specialist team that looks into containers and Kubernetes, and maybe re-factors or rewrites an existing application. I don't know, maybe they deploy something net new, but they do it all on containers and Kubernetes. And the team is a bit of a skunk works factory, if you know what that means, like a side project thing. 

But they break all of the new ground and do all of the early graft work, and then they take what they've learned, and they systematically disseminate that to the wider organization. So then, I'm talking about things like helping other departments and teams start to integrate and leverage containers and Kubernetes. And you know what? If you go to the DockerCons and the CubeCon big events and things, you'll hear loads of stories from people on the stage telling about how their medium and large organizations, they take this type of approach of having, maybe call it a cloud native practice within the organization, then methodically pushing it out to the wider organization. Let me just take a couple of minutes to talk about, maybe, self healing and scaling. I've not really had time to go into things as much as I do in my courses, but I feel like I've thrown those couple of buzzwords around a lot, and I know they are proper buzzwords. 

So, just assume with me you've got a Kubernetes environment running, and you deploy an application to it. Now, the way that you deploy an application to Kubernetes is, you basically tell Kubernetes what you want, I'm not kidding here, Kubernetes then goes and does the hard work. No joke, it really does. So, you say something pretty much as simple as, "Kubernetes, I want a web front end for my app. Give me five replicas of an engine X web server running on a particular network port." And you tell that to Kubernetes, Kubernetes makes it happen, five web servers. You don't need any complex startup scripts, or complex monitoring scripts, or anything like that. You just tell Kubernetes what you want, and you're like, "Kubernetes, go figure out how to do it." Fabulous, but, then let's say it's four o'clock in the morning or whatever, and a node in your environment breaks, it goes down, melts, catches on fire, whatever, and it takes down one of the five web servers with it.

Now, look, back in the day, and I've lived through this, lots of phone call or an alert to the help desk, and people are getting woken up out of bed, and it's 4:00 AM, and you've got to fix the problem. Only we all know that's rubbish, and Kubernetes knows that. Well, the people that built Kubernetes knew that that was rubbish. Remember, Kubernetes comes out of lessons learned at Google, and you know what? Something tells me that Google wasn't waking an engineer up every time one of their million or so servers died. Anyway, look, because you declared to Kubernetes what you wanted, five replicas of engine x, on whatever network ports, Kubernetes keeps that as a list of what you want, and then it sits there just watching the environment all day, all night, making sure that what is running is what you want. Now, in our example, a node went down taking a replica with it, so clearly, we haven't got five engine x web servers anymore. But Kubernetes knows that we want five, so it spins up a new one. And you know what? As simple as that, and I'm saying it's simple, Kubernetes implements loads of amazing logic and cleverness to make that all happen, but as simple as that, Kubernetes has healed your application, as well, though.

And I'm going pretty quick, so I want to leave some time for questions. But you can define health checks for your applications. So you might have to find a health check that Kubernetes runs every five or 10 seconds, that checks that your application is alive and working. Then if it crushes, or, I mean, it fails the health check, Kubernetes can restart it. And you know what? It's all so easy to do with Kubernetes, so it can recover from hardware failures and application failures. As well, though, scaling was another buzzword that I've thrown around, which is also massively important these days. So, the premise of scaling is that you should always be running the right amount of infrastructure and applications to be able to cope with your demand. So, if demand goes up by, I don't know ... Think like it's black Friday or something, and you're an online retail company. Well, Kubernetes automatically scales your app and your infrastructure, so that you can cope with the demand. When things cool down maybe later next week, it scales things back, which, look, it's really cool, of course, but you know what? It's really important if you're in a cloud, where you pay based on what you consume. 

So, that idea of always running just what you need, it's just got so many benefits. But let me just do a super quick recap, and then we'll see about opening up and looking at some questions. So, recapping, we live in modern times that require modern apps. In turn, these need a modern platform with modern tools that implement modern patterns. Well, guess what? Kubernetes delivers all of that. And it is openly designed and managed with, I think, the wider community, and also the future in mind.

Somebody is asking here, "My experience so far has been with Docker containers, but the way you described Kubernetes implies that it isn't just containers. Are there more types of things that run inside Kubernetes than Docker?" So I'm going to rephrase that to say, are there more things that run inside of Kubernetes than containers? And the answer is yes. For the vast majority, like proper, most part, it runs containers, but it can orchestrate your virtual machines and functions as well. But generally speaking, and certainly when you're starting out, you're going to be doing it with containers. 

"Why choose Kubernetes of autoscaling capabilities provided by your cloud platforms?" So, that's a really good question. So, let me give you an example. If you run Kubernetes on a cloud platform, and you implement ... So, Kubernetes has ... Let me talk about two scaling technologies it has right there. Something called, I love this name, the Horizontal Pod Autoscaler, that scales your application instances. And then it has the Cluster Autoscaler, which scales the infrastructure behind Kubernetes to ... Maybe it throws more cloud virtual machines or instances at your cluster. So, if you're running Kubernetes, I'm just going to call it Amazon Web Services, and Kubernetes needs to add more nodes into your pool of Kubernetes nodes, then Kubernetes goes and actually talks to your cloud's API, and uses that autoscaling technology of your cloud provider in the background just to spin up more nodes, but then it adds the additional logic of automatically porting them inside of the Kubernetes cluster. Quite often, by using the Kubernetes autoscaling technologies, you are behind the scenes leveraging your clouds autoscanning technologies.

"Do you get the same layer of abstraction using just Docker, or is Kubernetes required? Docker implements the logic to start and stop containers and join those containers to networks and all that kind of stuff. And if you've got, let's call it, 30 nodes in a Kubernetes cluster, you would probably have 30 instances of Docker, one on each node, that manages all the containers. Kubernetes sits above that, and it manages all of those instances of Docker for you, so that you might say, "Why, I want to scale," like we said before, "the front end of our application, that web component from five," I'm going to call them containers, just to keep the conversation simple, "from five containers to 10." Kubernetes makes all of the decision as to which nodes that it will spin up those extra five containers on, and then it talks to Docker on each of those nodes to actually do this spinning off. Now, Docker has a similar technology that does something, well, similar to that called Swarm, but Docker on its own is much lower level than Kubernetes. I hope that answered the question. If it didn't, Docker and Kubernetes, the big picture, nails it for you.

"Does it have a connection with Docker?" Yes, it does. I think, like I just said there, Kubernetes effectively manages lots of instances of Docker for you. 

"Docker and Kubernetes, are they competitors?" Yes and no. Frenemies, friends and enemies, if you want maybe, or coopetition, cooperation and competition. I don't know. So, Kubernetes certainly competes with Docker Swarm, but it works hand in hand with the lower level Docker container starting and stopping stuff. So, like I said, Kubernetes sits higher up in the stack and it manages Docker below it.

"Is it possible to run a legacy applications on Kubernetes?" I guess it depends on your definition of legacy application. Let me just say this, you can certainly run legacy applications on Docker, and like we said, Kubernetes can manage Docker. You will not be getting the full benefits of Kubernetes if you do that. That's not to say that you won't get any benefits, but you won't be getting the full benefits.

"When we migrate our product to the cloud Kubernetes, is it better to leave traditional on-prem the way it is, or move it to Kubernetes as well?" So, I would say, when you start moving products to the cloud, you pick the low hanging fruit for one of the better term. First, you learn the ropes, you learn how it works, you become an expert at doing it yourself, and your wider organization, and then you start tackling the more difficult applications. Of course, do not take your hardest, most stateful, the most important application first.

"Will containers ever totally replace virtual machines?" Well, that's the same as, will virtual machines and open systems like Microsoft and Linux ever replace Big Iron UNIX, AIX, and HP-UX and the mainframe? The answer is no. This stuff will never replace everything, but it will consume a large portion of your applications and things in the future. But you'll still have some old legacy stuff running on-prem, on your mainframes, and your Big Iron UNIX and all that kind of stuff as well. Just probably less and less of that kind of stuff. Hope that answers the question to some point.

"Please tell us a path to get Kubernetes certification and how challenging it could be." So. I'm going to assume you're talking about getting yourself as an individual certified as Kubernetes, rather than your applications to be certified to run on Kubernetes. Just google certified Kubernetes administrator and certified Kubernetes application developer. In fact, search the Pluralsight library for it. That's what I'm talking about. 

"What are the most valuable features that Kubernetes provides over VMs given that most clouds will run VM images? I'm going to rephrase that question slightly to, what valuable features do containers provide over VMs? They are much lighter weight, and they are far quicker to boot and to restart, meaning that you will consume less infrastructure. So, I'm going to pick a number out there. Take it with a large grain of salt. If you could host, for argument's sake, it's around number 10 virtual machines on a node, an instance, you might be able to run 100 containers. And then, Kubernetes provides a platform that just gives you all of these opportunities that bring ... And I'm talking proper scaling, and proper self healing, and proper rolling updates and version roll backs and stuff, which ... So, virtual machines, they let you take your old application and lift and shift and dump it into a virtual machine. And that was great, because it saved on servers, and power, and energy, and potentially, licensing costs and stuff, but you still had your old application, whereas containers and Kubernetes encourages you to refactor or rewrite your older application, so that it will work in a more modern, demanding business environment. So, you get the containers are more lightweight and start faster than virtual machines, but you get all of the proper cloud native stuff that we talked about before scaling, self healing, rolling updates, all of that.

"Which is your preferred container orchestration, Kubernetes or Docker Swarm?" I love them both. I genuinely do. Docker Swarm is easier, and it may be the right choice if you are a smaller organization. I don't speak for Docker Inc, nor do I speak the Pluralsight, and to be honest, I shy away from even owning my own comments myself sometimes. Look, Kubernetes does not look like it is going away. It has so much momentum and so much ecosystem support. The same is not true for Docker Swarm. Now, I am not saying that Docker swarm is going to go away. I have no insight onto that, but I prefer Kubernetes. I just think it has the brighter and more exciting future.

"And what does EKS provide, Amazon's elastic Kubernetes service?" So, they will effectively run Kubernetes for you, and provide you a hosted hidden Kubernetes environment that you can run your applications on. Super easy to set up, costs money to use, of course, but they'll look after all of your upgrades, as in upgrading your Kubernetes, not your applications. But on the flip side, you have to run the versions that they want, and you probably can't tweak it if you really need to. And that's the same for Google's Kubernetes engine and DigitalOcean Kubernetes, and all that kind of stuff. So, any hosted service, you get it for dead easy, you've got to pay for it, but there are limitations apply. 

"Do you not see a great future for Windows containers in general? How about what ..." Oh, yes, I do. Yeah. "How about Windows containers on Kubernetes?" Yeah. So, I think about a month ago, Window nodes and your Kubernetes clusters, nodes in your Kubernetes cluster that can run Windows containers when general availability about a month ago, and I think it's got a really great future. I really don't want people to think that I was saying that I think Windows or Microsoft is not good, because I think the exact opposite actually. I think, on the Satya Nadella, and what have you that's going on at Microsoft, I am much-o impressed-o. So, I think Windows containers and Windows in Kubernetes, yeah, super bright future. 

"Is it a good idea to run Kubernetes on-premise?" Well, look, if your business is well invested in on-premises data centers, and you want that to be the case going forward, then running Kubernetes on-premise is, yes, absolutely, fabulous, go for it, I think, and this is generally speaking across the industry, going to the cloud, we all probably recognize it, that's not a cheap option these days, and if you go to the cloud, it tends to be for convenience. And then, once you run a lot on the cloud, you start to get big bills, and you're like, "Ooh, maybe we should look at moving some of this back on-premises." So, as you get good at Kubernetes, and what have you, you may look to move some of your workloads back to on-premises from a cost perspective. I'm saying "might" here. Everybody's different. But, for a lot of people, it will be a good idea to run it on-premises. 

"Have you tried working with K3s?" So I'm so busy that K3s, K3d, things like that, these miniature small Kubernetes for maybe Internet of Things devices, or running on your laptop and things like that, I've not had as much time as I want to absolutely go and check out those projects. I think they have super bright futures. 

Is it a good idea to run Windows nodes and Linux nodes in the same cluster, and use Windows nodes for old application that are lifted?" If you run Windows nodes in your Kubernetes cluster, maybe you can put some of your ... I'm not a big fan, I'll be honest with you, of putting old legacy applications onto something new like this. I'm just going to say, I would much rather you rewrote your applications to be more cloud native. I hope that I described that buzzword adequately enough earlier. If I didn't go, check out the courses I mentioned before. If anything, like I mentioned that story earlier of when I begged from my boss to get that huge old Compaq PC with the big heavy monitor in the corner of my bedroom, it used to be really hard work to learn stuff like this, and practice with it, and test, and get good at it. Compared to that, honestly, what a fabulous world we live in now with the opportunities that you have to learn anything you want.

I know Pluralsight uses the term democratize learning, and maybe I'm butchering it a bit there, but it uses the term democratize. Look, we have resources available now. I've written books on Docker and Kubernetes, other people have. I've got a ton of courses here on Pluralsight, other people have got courses on Pluralsight. There's the hands-on stuff that I mentioned before. There is ... I'm going to go into motivational mode here. There is no excuse now, for you and your organization, not getting your head around containers, Docker and Kubernetes. There literally isn't, that we've got fabulous resources available. Let's not leave them to waste. And I'm not just saying that because there's some of my stuff. Look, go and watch other people's courses. I'm more good with it at the end of the day. You've got opportunities that, I'm going to sound like an old man here, that I didn't have when I was a kid. Use them, and I promise, your career and your company, it can only benefit from them. And I will bow out on that, you have heard enough from me today.

 

Daniel

Thank you for listening to All Hands on Tech. If you enjoyed this show, please rate it on your podcast platform of choice. You can see show notes and more info at pluralsight.com/podcast.