Scott Hanselman

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

February 08, 2018 Comment on this post [37] 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 are 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, 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 listed 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 needed, 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, every 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 apply 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 Evans' "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
Hosting By
Hosted in an Azure App Service
February 08, 2018 10:19
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.
February 08, 2018 11:05

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. is how I do it.
February 08, 2018 11:49
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?
February 08, 2018 11:55
Maybe shooze instead of shush?
February 08, 2018 12:00
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.
February 08, 2018 12:13
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.
February 08, 2018 13:03
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.
February 08, 2018 13:56
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.

February 08, 2018 15:32
You are right. I am slowly collecting more reasons to move to docker.

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. ;-)
February 08, 2018 15:59
I see containers as a new deployment mechanism for brownfield improvements, while PAAS for greenfield solutions.

Am I wrong?

February 08, 2018 16:15
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.
February 08, 2018 17:17
Don’t shush. mosh.
February 08, 2018 18:08
Scott, I just wanted to say I love your articles. Thanks for all the great stuff.
February 08, 2018 19:51
So I'm still wondering what's in it for me. Let's look at a basic scenario:

1. Azure hosted in Web apps (doesn't matter if it's linux or windows). Scalability turned on both horizontal and vertical.
2. Azure SQL DB and/or CosmosDB (which autoscales)
3. VSTS with automated deploy that deploys to failover, runs tests, and then flips it to production so 0 downtime
4. .NET Core Based everything.

So I don't need to make sure that dependencies are there persay because other than node_modules and nuget packages that automatically download as part of VSTS and would still happen with docker etc. I don't see why I need to do this.

AND Azure automatically updates Web Apps, SQL DB and CosmosDB for me. I don't need to do anything and don't have to worry about any downtime while it's happening.

Why would I use docker and k8s when I can fire and forget and it just works and scales as much as I want it to scale automatically? (Several million unique visitors a day site with over 5 terabytes of data plus analytics running just fine and I've done similar with much larger than that.) Dev, QA and Staging are just copies of production scaled down.

Seems like more stuff for no benefit and I'd have to actually do more to maintain my production environment than I do now. And even more to setup a development machine too.

Where am I wrong? On linux stuff, yes I can see this because getting it running is hard and keeping it running even harder. But .NET on Azure? Why? Is this better than VMs on AWS? ABSOLUTELY. Is this better than VMs on Azure? Absolutely.

But if you're using VMs for this stuff on Azure, you're doing it wrong and wasting money. I can't think of anything you need a VM for in Azure.

So, please provide a use case that would improve my current scenario using docker and k8s. I'd really like to know what I'm missing.
February 08, 2018 20:12
James Hancock: what if you wanted to move off Azure, perhaps because a customer insisted? Perhaps to another cloud, perhaps to on-prem? Using docker and/or Kubernetes would allow you to have the same scalability and manageability, using the same tools, regarless of where you run.
February 08, 2018 21:10
What if I said you don't shush but shell.
February 08, 2018 21:13
shush is pronounced shell.
February 08, 2018 22:22

"Here's a Golang application, compiled to a binary for your machine. It has everything you need embedded (web server, database, etc). It's a few megs compressed. Just run it."
February 08, 2018 22:34
Raj Chaudhuri: Sure. In that limited case I guess it would be better. But since you do that maybe once every 5 years, if you're unlucky, why would you introduce all of the overhead and complexity on a day-to-day basis? Your ROI would always be negative. That's my point.
February 08, 2018 22:39
So Docker images and k8s share the same OS images, but if X micro services are deployed as Docker images in a cluster, do they still require as much RAM as running X instances of the OS? In a Service Fabric cluster wouldn't it require much less resources if each service is deployed as an ASP.NET Core app directly on the cluster compared to a Docker image?
February 09, 2018 4:11
Non technically you explained the technology in great detail. Even a novice programmer will care about dockers, containers now :).
February 09, 2018 16:52
License compliance is a big deal where I ply my trade.

The devil is always in the details. How can you maintain license compliance when propreitary software is in your docker image? Seems like you'd be essentially screwed any time an audit is performed.

The documentation of your image becomes a whole new frontier of "interpretation" that has to be sent to the Legal Dept every time you want to ship an image (even intra-company).

Going fully FOSS is a dream, but rarely a reality.
February 09, 2018 17:37
I'm with @dibran and @james. We use PaaS (azure web apps in our case), each "service" is a separate web app or webjob running on either a shared or dedicated app service host. We're considering moving to Serverless Functions.

I really can't see the point of Docker containers... yes, perhaps if you're running VMs but then containers just seems more of an intermediate step to a full PaaS solution.

*if* there is a benefit to a PaaS platform then I'd like to read that kind of article.
February 09, 2018 17:42
@Raj - but an app can be designed for Azure PaaS that is highly portable between Cloud providers.

A web api "service" is just web api wherever it's deployed (AWS even lets you run .net core web api in their serverless framework... something azure doesn't let you do...) and a web job is just a wrapper around a console app or windows service.

It's easy to design your app with a custom "host" layer for Azure or AWS and the business logic to be independent of that. Just don't integrate too deeply on custom Azure (e.g. Azure Search, Table Storage) or AWS technology.
February 09, 2018 19:04
After reading this. The first thought I had was "I don't want to be a plumber". Most apps don't need this level of complication and if they do it usually means that they used the wrong parts. I don't use Node because its a nightmare of modules. I stopped using SQL Server because it wants to run business logic in its stored procedures. I keep my stack very simple which turns into a very easy installation and maintenance cycle. MVC, Mongodb, Elasticsearch. If I need a desktop UI I use nwjs.
February 10, 2018 8:07
So does that mean this is a good time to start talking about using embedded databases in .NET apps?
February 10, 2018 14:25
James: PaaS is great and just becuase you containerize some parts doesn't mean you get rid of all PaaS or SaaS offerings. It isn't one or other option. Key parts dockerized but still PaaS for other parts say Cosmos Db and Auth0. Also have you ever tried having multiple live versions in your application all in production. Different customers in different groups A/B testing? Ever tried having early adopters opt into new features and have those users redirected to a different version? Check out stuff like Vamp
February 12, 2018 17:29
Graeme Miller

Good points!

We do this now with powershell scripts that execute as part of our VSTS release process. I guess we could use K8 for this, but then we'd lose the automatic updating of Web Apps on Azure.

I don't want to be IT and I don't want to have IT staff on hand. I never want to have to worry about patching servers, I want it done automatically and transparently for me by experts. That's why I use the cloud. Otherwise I could host myself much more cheaply.

My devs write code and we've automated the test/deploy process using vsts. With PAAS that's the sum total of everything we have to do. No one is distracted by IT maintenance nor do we have to roll an updated version of our docker image every time there are security patches to deploy.

Either way I'd have to write scripts to manage what you're describing, k8 versus powershell, same difference. My problem is all of the additional stuff on top of that that I then have to maintain with docker/k8 from my understanding.
February 13, 2018 8:03
It's pronounced 'sesh'.

You're welcome. ;-)
February 13, 2018 14:17
Hi Scott, I just wante to say I really like your articles. Thanks for all the great stuff.
February 13, 2018 17:21
James: I am often as much PaaS as possible but it depends on the project and requirements. Sometimes we have to deploy on-prem with no Cloud dependencies. Sometimes we want stuff that PaaS offering isn't as good. E.g. NGNIX is better than Azure Application Gateway. We hated owning stuff but containerization makes it so much easier than a bunch of VMs. We can spin a whole lot more stuff up locally with containers – with PaaS that is often hard. We have been burnt by PaaS plenty – for example VSTS couldn’t build Framework 4.7.1 projects but our container didn’t care. VSTS keeps changing itself and you have no control over it – we have had build pipelines break because MS deprecate stuff – so in many ways containers made our build pipeline more reliable. Works locally – works on VSTS as build lives in a container.

I understand not wanting to own stuff but containers are moving towards a PaaS model. AKS (Azure Container Services) abstracts away the hosting of Kubernetes. All you own are the Docker hosts which are managed Azure VMs. It is moving towards a far more consumption model and you get more flexibility. Service Fabric offers Docker hosting as well. MS are I’m sure working on a fully managed PaaS service fabric offering for Azure (rather than the current IaaS offering). The management of Kubernetes is getting better and with stuff like Vamp I can fix issues with a new release by redirecting all IE traffic to old version. We started small and you can deploy a single container using Web Apps for containers

Everything in its place – but containers prevent lock-in and offer flexibility with decreasing management overhead. Doesn’t rival PasS for many things e.g. I want MS managing my Azure SQL Servers. I’m pretty sure in next year MS will have AKS working in heterogeneous Linux/Windows container environment in which you don’t have to manage the underlying AKS and it will have a nice UI. There are growing add-ins for Kubernetes and it is becoming more prevalent.
February 15, 2018 14:03
Great article, and thanks for it.

Just to echo some of the other comments - perhaps you could write a framing piece comparing cloud-native PaaS-hosted offerings (with automated deployment e.g. via ARM templates) vs. KaaS (such as on AKS) vs. a pure Kubernetes play?

I think the tradeoffs are nicely covered in this comments section already, but you always find a great way to explain it and think of new angles that others haven't covered.
February 16, 2018 13:36
This sounds great, but will a pod be able to handle 4 CSS files? They're over 60 lines each! That's my only worry with this approach
February 18, 2018 11:57
My clients don't want to adopt it unless it goes out of Preview. So please go GA to drive up Azure consumption and we can sell it more.
February 19, 2018 9:50
Azure has hosted web apps. I can run my .NET apps without a container, with scalability.

AWS has elastic beanstalk. I can run my .NET apps without a container, with scalability.

A customer might request that I move an app from Azure to AWS, sure. I have yet to see this happen. Usually when a customer has their infastructure setup they rarely move, especially with prices being so competitive between the two giants.

Docker is a tool with very specific use cases. Not everyone needs that level of elasticity or extra complexity in their deployment process. The problem is everyone is jumping on the bandwagon because it's cool and, in essence, asking their boss to pay the bill for making them more marketable.

If you can tell me why Docker is a great idea without being able to tell me why it's not a great idea at the same time, then you haven't thought about the problem enough :)
February 20, 2018 2:19
I liked your reasoning for using Containers. However, one major thing was missing: How the Containers are better than the cloud hosted environments like Azure AppService. What are the advantages of using Kubernetes over AppService? And perhaps, one-day containers hosting services like AKS will turn into AppService 2...
February 23, 2018 11:04
Second (and third, and fourth) all the complaints about licensing. How do you deal with SQL Server licensing? What about Oracle? What about Windows Server? Surely none of these people are willing to give up the revenue of 10s (or hundreds, or thousands) of installations of their software.

And what about other miscellaneous items, like fonts? You have 10 licenses to use certain commercial fonts for producing documents server-side, OK, now you have k8s and someone accidentally says "scale up to 60 containers," well shit now you owe a cool $250k in license violations, in addition to committing a crime.

Comments are closed.

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