Do I Need Kubernetes?

&gt; Run your applications in Docker from day 1 (with docker-compose it’s as valuable for dev as it is for production) and think carefully before letting your applications store local state.<p>I think this is the key take away for many startups. Get it so you:<p><pre><code> 1. Have a single-command way to bring up your entire backend 2. That command can run on your dev machine 3. You document all of the settings for your containers and deps </code></pre> Once you have that in a docker-compose.yml file migrating to something like kube when you need health checks, autoscaling, etc is easy.<p>The only thing you must be critical of is bashing people over the head to make everything you run in your company run in this environment you&#x27;ve created. No special deployments. Establish 1 method with 1 tool and go from there.<p>Every company I&#x27;ve worked at I&#x27;ve brought a single command `docker-compose up -d` workflow and people were amazed by the productivity gains. No more remembering ports (container_name.local.company.com), no more chasing down configuration files and examples, no more talking to shared DBs, etc.

I think one of the underrated parts of using something like Kubernetes early (or even w&#x2F; simpler orchestrators like swarm or rancher), is that it encourages (and sometimes enforces) architecture best practices from the start. IE, you won&#x27;t be storing state locally, you&#x27;ll be able to handle servers being randomly killed, you&#x27;ll already have horizontal scaling, etc. In my experience the hard part of migrating to containers in a legacy app is when they break those constraints, especially around local state and special servers. It&#x27;s easier to do these things sooner rather than later, and the constraints kubernetes places on you aren&#x27;t that hard to work around if you design it in from the start.<p>I good reason <i>not</i> to use kubernetes though is if you know your app is probably never going to scale, or if it&#x27;s the kind of thing that can scale very well on a single machine, or if it&#x27;s not primarily based on http communication. (I wouldn&#x27;t write a real time game server in kubernetes, for instance, because I doubt it&#x27;d really help with a primarily UDP workload that is likely going to be attached to one server)

I&#x27;ve always seen the story like this:<p>It all started with Ruby. Ruby&#x27;s syntactic sugar inspired the &quot;syntactic sugar&quot; of tooling, primarily Bundler and Rspec. Tooling, for what felt like the first time, became a first class citizen. Ruby&#x27;s tooling made Heroku possible: ie, reproducible builds across; dev, testing, staging and production environments. Heroku&#x27;s success was based on the primitives of the Twelve-Factor App[1]. The 12 factors (and therefore Heroku) were fundamentally designed around the already-old lightweight virtualisation technology of LXC. The success of Heroku paved the way for Docker. The success of Docker created the world in which Kubernetes makes sense.<p>To be blunt: if you don&#x27;t understand the relevance of Kubernetes, or whether it&#x27;s relevant to you, you don&#x27;t understand the benefits of the 12 factors in their broadest sense. The 12 factors are much, much more than just &quot;How To Deploy On Heroku&quot;.<p>Copypasting the 12 factors:<p><pre><code> I. Codebase One codebase tracked in revision control, many deploys II. Dependencies Explicitly declare and isolate dependencies III. Config Store config in the environment IV. Backing services Treat backing services as attached resources V. Build, release, run Strictly separate build and run stages VI. Processes Execute the app as one or more stateless processes VII. Port binding Export services via port binding VIII. Concurrency Scale out via the process model IX. Disposability Maximize robustness with fast startup and graceful shutdown X. Dev&#x2F;prod parity Keep development, staging, and production as similar as possible XI. Logs Treat logs as event streams XII. Admin processes Run admin&#x2F;management tasks as one-off processes </code></pre> 1. <a href="https:&#x2F;&#x2F;12factor.net&#x2F;" rel="nofollow">https:&#x2F;&#x2F;12factor.net&#x2F;</a>

Honestly nobody <i>needs</i> k8s, but nobody really needs anything. If you know it and you know it suits your needs, then sure! Go for it! Have fun.<p>If you don&#x27;t know it, then learn it first. Then you can properly evaluate whether it suits your requirements or not.<p>There&#x27;s huge value in choosing something that your team already knows + is familiar with<p>I&#x27;d totally advocate for learning something new, but solving a business problem probably isn&#x27;t the best time for this :)<p>I think the article gave a great overview though, and is perhaps a good way to decide what to learn next

Remember Greenspun&#x27;s 10th rule?<p>&quot;Any sufficiently complicated C or Fortran program contains an ad hoc, informally-specified, bug-ridden, slow implementation of half of Common Lisp.&quot;<p>Well, there&#x27;s a kubernetes version, which is that any sufficiently advanced deployment system will ultimately be half assed version of kubernetes.

I was a huge proponent of not hosting monolithic applications on kubernetes, that was until the company I worked for acquired another same size company and I had to learn their hand rolled puppet2&#x2F;shell script based infrastructure management&#x2F;deployment logic all over again(we had our own hand rolled puppet3&#x2F;shell script based infrastructure logic too, so that&#x27;s two stacks with their own quirks.)<p>Now I&#x27;m completely in favor of hosting anything you can cram into kubernetes in kubernetes, even though kubernetes is more complex than most other infra tools, most of the time there is only one way to do things(configmaps for config, PV allocations for storage etc..) So if you understand kubernetes, it&#x27;s easier to get the larger picture about the infrastructure even if you know nothing about the application stack.

I think what isn&#x27;t fully appreciated about k8s yet, but we will look back on is how it creates an open standard platform for apps to be deployed. It is one thing to port your own apps to run within a k8s cluster, it is another to have and operate a k8s cluster that you can use to deploy services built by others. I hope we see more of this soon

Not a single mention of elastic beanstalk or App Engine? The best middle ground for small teams who just want one reliable website with minimal scaling (and who can&#x27;t just choose a nom-aws service).

I only have one tiny detail: Bursty traffic means that your cluster needs to be able to deal with the peaks. If you running an on prem Kubernetes cluster, then there is no savings, unless you can use the capacity for something else during non peak periods.<p>The scaling, and potential savings is a cloud feature, not a feature of Kubernetes.

My assessment is that if you have a large, complex micro service environment with several applications, docker may be a good route to take as an interim to cloud native.<p>If you have a relatively simple deployment structure (one big application with 10-20 services), maybe you don&#x27;t need to add the docker skill to what you&#x27;re already doing.<p>If you&#x27;re in the process of rebuilding your applications and you&#x27;ve decided cloud native is the way to go, then containers are pointless.<p>I&#x27;d argue if you don&#x27;t have the skills and you don&#x27;t want to pay someone to do this work full-time, you might put your developers in a position to fail.<p>Based on my 30+ years of building software, I see containers as a dead end. It may help you out in the short term, prove to your CTO that you&#x27;re using &quot;well-known&quot; technology, but in the end, cloud native is going to replace everything. And before you say &quot;but we can&#x27;t be in the cloud,&quot; then you should know that cloud-native development like Lambdas can be done on-prem as well.<p>I&#x27;m positive this post will get negative votes. That&#x27;s fine. I like tilting at windmills.

&gt; To make a cluster useful for the average workload a menagerie of add-ons will be required. Some of them almost everyone uses, others are somewhat niche.<p>This is the concern I have with k8s. All this complexity introduces operational and security concerns, while adding more work to do before you can just deploy business value (compared to launching on standard auto-scaling cloud instances)

This sounds like people try to compare K8s with what was before and sure, that all holds true.<p>You get all of this with serverless (be it with managed services or FaaS), with reduced (albeit not zero) complexity compared to K8s.

Here&#x27;s a quick reference:<p>1) Are you on AWS? Then you don&#x27;t need Kubernetes. Use Fargate.<p>2) Are you on Google Cloud? Then you don&#x27;t need Kubernetes. Use Cloud Run.<p>3) Are you on Azure? Then you don&#x27;t need Kubernetes. Use Azure Container Instances.<p>4) Are you on a PaaS like Heroku? Then you don&#x27;t need Kubernetes.<p>5) Are you on a random VPC provider &#x2F; bare metal machines? You could probably still do without Kubernetes using Docker Swarm (apparently it&#x27;s not dead!), Nomad, Mesos DC&#x2F;OS, or a standard Linux box and systemd (or some other process or cluster scheduler).<p>6) Do you need to solve the bin-packing problem? Do you need to self-host a service mesh of microservices in multiple colocated regions? Do you need a fully automated redundant fault-tolerant network of disposable nodes to constantly reschedule different versions of applications with stringent RBACs, scheduled tasks, dynamic resource allocation, and do you have about a million dollars to spend on building and maintaining it all? Then you need Kubernetes.

To me the question is more: Is there an extremely valid reason to _not_ use K8s.<p>As a freelancer I visit quite a number of enterprise companies, think: Banks, Insurance, Airports, and they are all making the switch or are full-on invested in living in K8s by default. If it does not run in or was not made with K8s in mind: It will not be used&#x2F;bought.<p>Another thing I&#x27;m noticing with smaller companies: If you start fresh, you choose k8s. Which mens all other stuff is already slowly dying by virtue of not beeing chosen.<p>Developers want&#x2F;expect it, sysadmins see the benefits from day one, and companies see the potential gains of using less cloud resources and a platform that could potentially run in multiple clouds for the first time ever.<p>K8s, openebs, prometheus&#x2F;grafana, loki, kustomize, github actions. This is truly where &quot;it&#x27;s at&quot; at the moment.

I work for a startup whose product is small (half a dozen servers, if relatively beefy ones) clusters that will be run on-prem by customers, at least sometimes in a low-to-no-touch capacity. Most of our application components are micro-ish services that are run on all hosts in the cluster for either extra capacity or fault tolerance.<p>We currently run everything on mesos&#x2F;marathon, but are looking to switch away from it. K8s is kinda the “default” option, and is potentially appealing to some potential acquirers and investors.<p>But I never really see k8s being talked about in that context of “physical hardware that’s on prem, but not on MY prem.” Is there a reason for that? If we go with k8s is it going to bite us? Does anyone have experience with something like that they could share?

I would say if you have the question &quot;Do I need Kubernetes?&quot;, you don&#x27;t need it because the benefits are not immediately crystal clear to you. Also, the author starts the evaluation from the wrong point of view, because the decision should be not so technical, but like everything else should be based on BUSINESS REQUIREMENTS. Evaluating Kubernetes is no different:<p>- Do you have such high traffic that you need a distributed system?<p>- Will a unified framework solve all your distribution problems?<p>- Do you really need high availability?<p>- Can you swallow the cost of high availability?<p>- Can you handle the insane complexity of Kubernetes at a reasonable cost?<p>You should not start asking questions about &quot;Pods, Ingress&quot; or anything Kubernetes specific, those are just implementation details.

Vendor lock-in aside, I&#x27;ve found ECS to be a great alternative.

The article outlines a very nuanced detailing of how to answer that question, but I have a more blunt first consideration: If you need kubernetes, you don&#x27;t need to ask whether you need it.<p>Basically, I think that a team&#x2F;product <i>knows</i> when the time has come in which the infrastructure has grown in complexity so much for it to need something like kubernetes to orchestrate it. If there are doubts, then whatever current setup is in place* is probably still enough and kubernetes is beyond what the team requires.<p>I am very proud of the one time I managed to convince both my then tech lead and project manager, in one of my past jobs, to move away from kubernetes into a simpler architecture leveraging docker, compose and PaaS.<p>* Hopefully one using docker and compose or similar, as mentioned in the article.

For small apps and projects that continuous delivery is not required I would start with lxd. I think it&#x27;s the easiest way to containerize an app.<p>Once that feels too little, I would start looking at docker, and only when docker feels again too little, to kubernetes.<p>So in essence, for 95% of the apps&#x2F;people, the answer is no.

I&#x27;ve sprinkled some comments in this thread, but as someone who is working more or less full time with k8s infrastructure, architecture and maintenance (and I do love k8s!), my take is that if you have to ask this question then the answer is invariably: NO.

I need Kubernetes since we&#x27;re outgrowing Docker Swarm. Docker Swarm has a lot of issues we deal with on a constant basis so it&#x27;s becoming quite painful.<p>Can anyone suggest a good migration guide from Docker Swarm -&gt; Kubernetes?

Would have been much funnier, if this would have been just a page with a single word on it: NO.<p>See also: <a href="http:&#x2F;&#x2F;dowebsitesneedtolookexactlythesameineverybrowser.com&#x2F;" rel="nofollow">http:&#x2F;&#x2F;dowebsitesneedtolookexactlythesameineverybrowser.com&#x2F;</a>

Probably not.

No.

When a newspaper headline or blog post title ends in a question mark, the answer is almost always &#x27;no&#x27;.

No

&gt; Kubernetes isn’t just a 2018-era buzzword.<p>And then he goes on to throw buzzwords. Yet another poorly written article as is now the norm for Kubetnetes.

Probably not. Why not utilise ECS&#x2F; Fargate and attach managed services, rather then tending a whole now flock of things?