Scott Hanselman

Why should I care about Kubernetes, Docker, and Container Orchestration?

February 8, '18 Comments [13] Posted in Docker | Kubernetes
Sponsored By

A person at work chatted me, commenting on my recent blog posts on the Raspberry Pi Kubernetes Clusters that are being built, and wondered "why should I care about Kubernetes or Docker or any of that stuff?"

WOCinTech Chat pic used under CC

Great question, and I'm figuring it out myself. There's lots of resources out there but none that spoke my language, so here's my thoughts and how I explain it.

"Hey, I have this great new blog app!"

"Fab, gimme!"

"Sure, first make sure you have this version of Windows/Linux, this version of .NET/Python/Node, and these prerequisites."

"Hang on, lemme call you next week when that's handled."

This is how software was built for years. Now let's deploy it.

"Here's the code/dlls/application zipped up."

"Lemme FTP/SFTP/Drag this from one Explorer Window to another."

"Is this version of that file set to this?"

"Wait, what?"

"Make sure that system/boss/dll/nounjs is version 4.5.4.1, they patched it."

"Ok, Imma shush* into production."

Again, we've all been there. It's 2018 and there's more folks doing this than you care to admit.

Enter Virtual Machines! Way better, right? Here's a USB key with a  file that is EVERYTHING you need. Handled.

"Forget that, use this. It's better than a computer, it's a Virtual Machine. But be aware, It doesn't know it's Virtual, so respect the lie."

"OK, email it to me."

"Well, it's 32 gigs. Lemme UPS it."

Your app is only 100 megs, and this VM is tens of gigs. Why does a 150 pound person need a 6000lb Hummer? Isolation, I guess.

"The app is getting more complex, but it's cool. There's four VMs now. One for the DB, one for Redis, and a front end one, and the shopping cart gets one. It's microservices!"

"I'm loving it."

"Here's a 2 TB drive."

Nice that we're breaking it up, but not so nice that we're getting bloated. Now we have to run apt upgrade/windows update on all these things and maintain them. Why drive a Hummer when I can get a Lyft?

"Ok I got them all running on this beefy machine under my desk."

"Cool, we're moving to the cloud."

"Sigh. I need to update all these connection strings and start uploading VMs."

"It'll be great. It's like a machine under your desk, except your desk is in the cloud."

"What's the cloud?"

"It's a server room you can't see. Basically it's the computers under your desk. But invisible."

Most VM infrastructure is pretty sloppy. It's hard coded IP addresses, it's poorly named VMs living in the same subnets, then we'll move them to the cloud (lift and shift!) but then they are still messy, but they're in the Cloud™, right?

"You know, all these VMs are heavy. I have to maintain and move a bunch of stuff that ISN'T the app. Containers are the way. Just define the app's base requirement and share everything else."

"I've been hearing about this. I can type "docker run hello-world" and on any machine it'll load the hello world image (based on Ubuntu) from a central hub and run it in a mostly isolated way. Guaranteed to work and run, even as time passes."

"Nice, because more and more parts of our app are in .NET Core on Linux, but there's also some Python and node."

"Yep and it'll all just run as the prerequisites are clearly listened in the container...and the prereqs are in fact references to other container images."

"It's containers all the way down."

Now the DB, Redis, the front end, and the shopping cart can call be defined in some simple text files. Rather than your Host OS (the main computer...the metal) loading up a bunch of Guest OS's (literally copies!) and then loading all the apps and prerequisites, you'll share  OSes, and when appropriate, the binaries and libraries.

"OK, now we have a bunch of containers running in Docker, but sometimes they go down or stop."

"Run them again?"

"It's more that that, we need to sometimes have 3 shopping cart containers, and other times we need 2 or more DB containers. Plus their IPs sometimes change"

"So we need something to keep them running, scale or auto-scale them, as well manage networking and naming/dns."

Enter a container orchestrator. There's Docker Swarm, Mesos/Marathon, Azure Service Fabric, and others, but for this post we'll use Kubernetes.

"So Kubernetes runs my containers, keeps them running, and helps manage the network?"

"Yes, and no. Parts of Kubernetes - or k8s, as cool people like me who have been using it for nearly 3 hours say - are part of the master components, like etcd for key value storage, and the kube-scheduler for selecting what node to run a "pod" on (a pod is cooler to say than container, but sometimes a pod is more than one container. Still, very cool.)

"I'll need to make a glossary."

"Darn tootin' you will."

Kubernetes has basically pluggable everything. Don't like their networking setup? There's literally over a dozen options. Want better charts and graphs? Whole world of options.

Just as one Dockerfile can explain declare what's needed to run an app, a Kubernetes YAML file describes not only the  containers, but the ports need, the number of replicas of each (think web farm), names, environment variables, and more. Here's a file that shows a front end, back end, and load balancer. Everything is there, connection strings become internal DNS lookups, ever service has a load balancer (if you like), and you can scale manually or auto-scale.

"Ok so why should I care?"

"A few reasons. In the past, to install our app I'd need to give you a Word document and a weekend. Now you type kubectl apple theapp.yaml and it's running in less than a minute."

"I'm still billing for the weekend."

Simply stated, we are at the beginning of a new phase of DevOps. One that is programmatic, elastic, and declarative. It's consistent and clear and modular.

I recommend you check out Julia Evens' "Reasons Kubernetes is cool" as well as reading up on how to make a Kubernetes cluster (and the management VMS are free) in Azure.

* I'm trying to make shush a thing. We don't Es Es Eaytch into machines! We shush in! It's pronounced somewhere between shush and shoosh. Make sure you throw in a little petit jeté when you say it.

* Pic used under CC


Sponsor: Unleash a faster Python Supercharge your applications performance on future forward Intel® platforms with The Intel® Distribution for Python. Available for Windows, Linux, and macOS. Get the Intel® Distribution for Python* Now!

About Scott

Scott Hanselman is a former professor, former Chief Architect in finance, now speaker, consultant, father, diabetic, and Microsoft employee. He is a failed stand-up comic, a cornrower, and a book author.

facebook twitter subscribe
About   Newsletter
Sponsored By
Hosting By
Dedicated Windows Server Hosting by SherWeb
08 February 2018 06:19:00 UTC
Thanks, this article kind of explain my basic confusion on docker itself. I am using docker for some project testing, but really unable to include it in my workflow. Mainly because I cannot explain why I need docker. But your article explain that and point in direction where I can explore more for it.
08 February 2018 07:05:56 UTC
Hi

I'm using Docker for Jekyll static site publishing on my Windows machines. As you said, installing the dependencies (Ruby etc..) can take a while, 'lemme call you next week when that's handled' is so true. So Docker is a great use case, and I use it daily. https://davemateer.com/jekyl/2018/01/25/Jekyll-and-Docker.html is how I do it.
08 February 2018 07:49:42 UTC
Dear Sumit. I am absolutely with you on the docker feelings.
Looks cool when testing it. But do I really need it?
It solves compatibility problems which I DO NOT WANT to fall into in the fist place.

- I try to have all on the same .net framework version. Locally and also in AppService (so I can not move to 4.7.1 yet). (no need for docker)
- .NET Core work OK as it works side by side. (no need for docker)
- All is on windows which I do not need to "Shush" into (no need for docker)

... but wait, am I not constraining my options to much? Is my fear of incompatibility necessary when docker is around?

Maybe If I take the risk I can gain something?
Maybe I would not mind some Redis instance?
Maybe I could use Node on the server to run my picture generator instead of JavaScriptServices interface on the server?

One WebApp+WebJob was good up to a certain point, but I know that I need to move to microservices anyway.
So maybe the yaml file is a good cookbook for the whole application.

Am I alone in this mindset-shift-transition?

Does docker give us more courage to more adventurous solutions sooner?
Richard Vondráček
08 February 2018 07:55:19 UTC
Maybe shooze instead of shush?
Ian Rathbone
08 February 2018 08:00:41 UTC
Oke we all get it, if you are still using on-premises servers or VM's you're probably better of using containers.

But why should I care about containers if I'm already working in the Cloud and primarily on PaaS or even on Serverless? It feels like a step back, you can do Microservices even better with PaaS and Serverless components in my opinion. I would like to have some sort of scenario where you are better of using containers instead of PaaS? Is it more cost effective? Does it scale out better? I'm looking for answers to those questions.
08 February 2018 08:13:00 UTC
I see all of what this article describes as the equivalent of doing WinForms all your life and then switching to WPF.

It is a massive mindset transition.

The thing that always gets me with these kind of articles and videos is they make it all sound so sunny and perfect - but in my head I'm saying "reaaaallly?!"
The current project I work on needs SQL Server database with mixed mode auth/full text indexing AND - the kicker - SSRS. That is used as the backing for a full fat .NET MVC web app. There is also a Windows service that runs various automated import process and scheduled tasks that interact with both the DB and/or web app.
The customers of this project obviously have different sets and config for all of this. Currently this all set up on hosting company VMs (2 for live (DB/web) and 2 for test (DB/web)).

So I've got to some how get docker images for SQL Server, IIS with URL rewrite module, configure the IIS appropriately for a given customer - think IP restrictions for test site with a version of my web app, win service installed.
The majority of the software to be set-up and configure is 3rd party. Doesn't the 3rd party software have to lend itself to use with docker? i.e. have lots of way of scripting/automating it; if it doesn't then isn't that game over - how would you ever update it.

For SQL Server for example, what would I do if I had a docker of that with the customers DB - which has to stay on the server - ISO standard for data sensitive I can't bring it back locally to our sensitive servers unless permission is granted and I can't achieve the same goal any other way - and I wanted to apply the latest service pack to SQL?
Also lets not forget that SSRS is satans spawn and the bain of everyone who ends up using it.
Peter
08 February 2018 08:50:37 UTC
Great article!

's/apple/apply'
08 February 2018 09:03:05 UTC
Richard Vondráček: "I try to have all on the same .net framework version. Locally and also in AppService (so I can not move to 4.7.1 yet)" - and there's your reason for containers right there.

Imagine deploying your application on a server that has 4.7.1 installed and configured. With containers, your application and everything it needs gets deployed as a unit, and runs in near-complete isolation. Which means that server administrators can run a large number of applications from a large number of people, without bothering that any one application's dependencies or configuration will interfere with any other application.

And developers, if they take the additional effort of creating docker images (and compose files/kubernetes config files when needed), are essentially shipping their own machines to production. Mr. Hanselman's "Works on my machine badge" becomes practical with containers, because if a container (or a stack of containers) works on your machine, it (or they) will work anywhere.
Raj Chaudhuri
08 February 2018 09:56:38 UTC
As I'm currently 'enjoying' the experience of deploying several web app to various VMs, this article was the source of genuine LOLs, for me.

However, when I reached "I'm still billing for the weekend." - I very nearly snorted my coffee over my keyboard.

:)
Robert Armour
08 February 2018 10:11:16 UTC
We work with docker for app developments. It's cool, and not thread with it
ananya
08 February 2018 11:32:46 UTC
Raj:
You are right. I am slowly collecting more reasons to move to docker.

Dibran:
Good points. PaaS is great as long as you're OK staying in the boundaries (worked good so far for us and our business would never start without Azure PaaS ). Serverless is a fantastic cost/scale model and is orthogonal to whether you deploy DLLs or container images. Therefore I still await some sort of KaaS "Kubernetes as a service" combined with serverless services declaration based e.g. on FaaS.
AKS is getting close.

I enjoy watching the smart people figuring that infrastructure out as I'm focusing meanwhile on good quality code inside of my DLLs. I guess we both merge our efforts by the end of 2018. ;-)
Richard Vondráček
08 February 2018 11:59:04 UTC
I see containers as a new deployment mechanism for brownfield improvements, while PAAS for greenfield solutions.

Am I wrong?



08 February 2018 12:15:09 UTC
I have been reading your articles for a loooon time, and this series about docker and kubernetes... all the time I have been thinking "why on earth would you make things that complicated". I'm still not sure. I've read your articles that are page after page after page about how "simple" this stuff is, yet it needs a dozen articles to explain... Something's not right here.

Oh, and those examples are - yes I know, examples, but still way, way overboard. You lost me on the first one. "a kewl blog software - gimme gimme - ok, here's the link". Why would it be any more complicated than that?

Not sold, but will keep reading.
El Dorko
Name
E-mail
(will show your gravatar icon)
Home page

Comment (Some html is allowed: a@href@title, b, blockquote@cite, em, i, li, ol, pre, strike, strong, sub, super, u, ul) where the @ means "attribute." For example, you can use <a href="" title=""> or <blockquote cite="Scott">.  

Live Comment Preview

Disclaimer: The opinions expressed herein are my own personal opinions and do not represent my employer's view in any way.