Why should I care about Kubernetes, Docker, and Container Orchestration?
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?"
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 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 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.
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.
About Newsletter
Sumit Gupta
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.
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?
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.
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.
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.
However, when I reached "I'm still billing for the weekend." - I very nearly snorted my coffee over my keyboard.
:)
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. ;-)
Am I wrong?
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.
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.
"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."
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.
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.
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.
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.
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.
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.
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 :)
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.