For what it's worth, I've worked at multiple places that ran shell scripts just fine for their deploys.

- One had only 2 services [php] and ran over 1 billion requests a day. Deploy was trivial, ssh some new files to the server and run a migration, 0 downtime.

- One was in an industry that didn't need "Webscale" (retirement accounts). Prod deploys were just docker commands run by jenkins. We ran two servers per service from the day I joined the day I left 4 years later (3x growth), and ultimately removed one service and one database during all that growth.

Another outstanding thing about both of these places was that we had all the testing environments you need, on-demand, in minutes.

The place I'm at now is trying to do kubernetes and is failing miserably (ongoing nightmare 4 months in and probably at least 8 to go, when it was allegedly supposed to only take 3 total). It has one shared test environment that it takes 3-hours to see your changes in.

I don't fault kubernetes directly, I fault the overall complexity. But at the end of the day kubernetes feels like complexity trying to abstract over complexity, and often I find that's less successful that removing complexity in the first place.

Kubernetes is so easy that you only need two or three dedicated full-time employees to keep the mountains of YAML from collapsing in on themselves before cutting costs and outsourcing your cluster management to someone else.

Sure, it can be easy, just pick one of the many cloud providers that fix all the complicated parts for you. Though, when you do that, expect to pay extra for the privilege, and maybe take a look at the much easier proprietary alternatives. In theory the entire thing is portable enough that you can just switch hosting providers, in practice you're never going to be able to do that without seriously rewriting part of your stack anyway.

The worst part is that the mountains of YAML were never supposed to be written by humans anyway, they're readable configuration your tooling is supposed to generate for you. You still need your bash scripts and your complicated deployment strategies, but rather than using them directly you're supposed to compile them into YAML first.

Kubernetes is nice and all but it's not worth the effort for the vast majority of websites and services. WordPress works just fine without automatic replication and end-to-end microservice TLS encryption.

This is so unnuanced that it reads like rationalization to me. People seem to get stuck on mantras that simple things are inherently fragile which isn't really true, or at least not particularly more fragile than navigating a jungle of yaml files and k8s cottage industry products that link together in arcane ways and tend to be very hard to debug, or just to understand all the moving parts involved in the flow of a request and thus what can go wrong. I get the feeling that they mostly just don't like that it doesn't have professional aesthetics.

I love that the only alternative is a "pile of shell scripts". Nobody has posted a legitimate alternative to the complexity of K8S or the simplicity of doctor compose. Certainly feels like there's a gap in the market for an opinionated deployment solution that works locally and on the cloud, with less functionality than K8S and a bit more complexity than docker compose.

I'm giggling at the idea you'd need Kubernetes for a mere two servers. We don't run any application with less than two instances for redundancy.

We've just never seen the need for Kubernetes. We're not against it as much as the need to replace our working setup just never arrived. We run EC2 instances with a setup shell script under 50loc. We autoscale up to 40-50 web servers at peak load of a little over 100k concurrent users.

Different strokes for different folks but moreso if it ain't broke, don't fix it

> The inscrutable iptables rules?

You mean the list of calls right there in the shell script?

> Who will know about those undocumented sysctl edits you made on the VM?

You mean those calls to `sysctl` conveniently right there in the shell script?

> your app needs to programmatically spawn other containers

Or you could run a job queue and push tasks to it (gaining all the usual benefits of observability, concurrency limits, etc), instead of spawning ad-hoc containers and hoping for the best.

Highly amateurish take if you call shell spaghetti a Kubernates, especially if we compare complexity of both...

You know what would be even more bad? Introducing kubernates for your non-Google/Netflix/WhateverPlanetaryScale App instead of just writing few scripts...

Both this piece and the piece it’s imitating seem to have 2 central implicit axioms that in my opinion don’t hold. The first, that the constraints of the home grown systems are all cost and the second that the flexibility of the general purpose solution is all benefit.

You generally speaking do not want a code generation or service orchestration system that will support the entire universe of choices. You want your programs and idioms to follow similar patterns across your codebase and you want your services architected and deployed the same way. You want to know when outliers get introduced and similarly you want to make it costly enough to require introspection on if the value of the benefit out ways the cost of oddity.

The elephant in the room: People who have gotten over the K8s learning curve almost all tell you it isn't actually that bad. Most people who have not attempted the learning curve, or have just dipped their toe in, will tell you they are scared of the complexity.

An anecdotal datapoint: My standard lecture teaching developers how to interact with K8s takes almost precisely 30 minutes to have them writing Helm charts for themselves. I have given it a whole bunch of times and it seems to do the job.

What I really like are solutions that are simple to both install and maintain.

For example, look at Docker Swarm: https://docs.docker.com/engine/swarm/swarm-tutorial/create-s... or Hashicorp Nomad: https://developer.hashicorp.com/nomad/tutorials/get-started/... or Kubernetes distros like K3s: https://docs.k3s.io/quick-start

Either of those would work better than a bespoke solution a lot of the time, for anyone who is not the original person writing that hodgepodge of shell scripts, because of how much information and documentation exists out there about those solutions.

Either of those would also work better than a very complex Kubernetes cluster that was built with HA in mind and tries to be web scale for anyone who isn't a DevOps engineer that's ready to spend a bunch of time maintaining it, given how complex things can get.

Curiously, a previous article by the author calls out Docker Compose as not being good enough https://www.macchaffee.com/blog/2024/docker-compose/ and also critiques Docker Swarm without much elaboration (because that's not the main focus):

> Single-node only. Many apps never reach a point where they need more than one node, but having to either rip out your entire existing deployment method or invest in Swarm are not good options.

I've seen both Docker Compose and Docker Swarm be used in production with good results - in problem spaces where minutes or hours of downtime (e.g. non-global audience, evenings) was acceptable and having zero downtime deployments wasn't required, though usually there were no big outages anyways. Admittedly, that's a pretty good place to be in, even if not that much interesting happens there.

Just pick whatever fits your requirements, there are also very sane Kubernetes distros out there, even for something like test environments or running locally.

Much like Javascript, the problem isn't Kubernetes, its the zillions of half-tested open-source libraries that promise to make things easier but actually completely obfuscate what the system is doing while injecting fantastic amounts of bugs.

Dear Amazon Elastic Beanstalk, Google App Engine, Heroku, Digital Ocean App Platform, and friends,

Thank you for building "a kubernetes" for me so I don't have to muck with that nonsense, or have to hire people that do.

I don't know what that other guy is talking about.

Most of the complaints in this fun post are just bad practice, and really nothing to do with “making a Kubernetes”.

Sans bad engineering practices, if you built a system that did the same things as kubernetes I would have no problem with it.

In reality I don’t want everybody to use k8s. I want people finding different solutions to solve similar problems. Homogenized ecosystems create walls they block progress.

One is the big things that is overlooked when people move to k8s, and why things get better when moving to k8s, is that k8s made a set of rules that forced service owners to fix all of their bad practices.

Most deployment systems would work fine if the same work to remove bad practices from their stack occurred.

K8s is the hot thing today, but mark my words, it will be replaced with something far more simple and much nicer to integrate with. And this will come from some engineer “creating a kubernetes”

Don’t even get me started on how crappy the culture of “you are doing something hard that I think is already a solved problem” is. This goes for compilers and databases too. None is these are hard, and neither is k8s, and all good engineers tasked with making one, be able to do so.

Kubernetes biggest competitor isn’t a pile of bash scripts and docker running on a server, it’s something like ECS which comes with a lot of the benefits but a hell of a lot less complexity

It sometimes blows my mind how reductionist and simplistic a world-view it's possible to have and yet still attain some degree of success.

Shovels and mechanical excavators both exist and have a place on a building site. If you talk to a workman he may well tell you he has regular hammer with him at all times but will use a sledgehammer and even rent a pile driver on occasion if the task demands it.

And yet somehow we as software engineers are supposed to restrict ourselves to The One True Tool[tm] (which varies based on time and fashion) and use it for everything. It's such an obviously dumb approach that even people who do basic manual labour realise its shortcomings. Sometimes they will use a forklift truck to move things, sometimes an HGV, sometimes they will put things in a wheelbarrow and sometimes they will carry them by hand. But us? No. Sophisticated engineers as we are there is One Way and it doesn't matter if you're a 3 person startup or you're Google, if you deploy once per year to a single big server or multiple times per day to a farm of thousands of hosts you're supposed to do it that one way no matter what.

The real rule is this: Use your judgement.

You're supposed to be smart. You're supposed to be good. Be good. Figure out what's actually going on and how best to solve the problems in your situation. Don't rely on everyone else to tell you what to do or blindly apply "best practises" invented by someone who doesn't know a thing about what you're trying to do. Yes consider the experiences of others and learn from their mistakes where possible, but use your own goddamn brain and skill. That's why they pay you the big bucks.

I think one thing that is under appreciated with kubernetes is how massive the package library is. It becomes trivial to stand up basically every open source project with a single command via helm. It gets a lot of hate but for medium sized deployments, it’s fantastic.

Before helm, just trying to run third party containers on bare metal resulted in constant downtime when the process would just hang for no reason, and and engineer would have to SSH and manually restart the instance.

We used this as a previous start up to host metabase, sentry and airbyte seamlessly, on our own cluster. Which let us break out of the constant price increases we faced for hosted versions of these products.

Shameless plug: I’ve been building https://github.com/czhu12/canine to try to make Kubernetes easier to use for solo developers. Would love any feedback from anyone looking to deploy something new to K8s!

I don’t think scale is the only consideration for using Kubernetes. The ops overhead in managing traditional infrastructure, especially if you’re a large enterprise, drops massively if you really buy into cloud native. Kubernetes converges application orchestration, job scheduling, scaling, monitoring/observability, networking, load balancing, certificate management, storage management, compute provisioning - and more. In a typical enterprise, doing all this requires multiple teams. Changes are request driven and take forever. Operating systems need to be patched. This all happens after hours and costs time and money. When properly implemented and backed by the right level of stakeholder, I’ve seen orgs move to business day maintenance, while gaining the confidence to release during peak times. It’s not just about scale, it’s about converging traditional infra practices into a single, declarative and eventually consistent platform that handles it all for you.

> Inevitably, you find a reason to expand to a second server.

The author has some good points, but not every project needs multiple servers for the same reasons as a typical Kubernetes setup. In many scenarios those servers are dedicated to separate tasks.

For example, you can have a separate server for a redundant copy of your application layer, one server for load balancing and caching, one or more servers for the database, another for backups, and none of these servers requires anything more than separate Docker Compose configs for each server.

I'm not saying that Kubernetes is a bad idea, even for the hypothetical setup above, but you don't necessarily need advanced service discovery tools for every workload.

> Spawning containers, of course, requires you to mount the Docker socket in your web app, which is wildly insecure

Dear friend, you are not a systems programmer

I think we need to distinguish between two cases:

For a hobby project, using Docker Compose or Podman combined with systemd and some shell scripts is perfectly fine. You’re the only one responsible, and you have the freedom to choose whatever works best for you.

However, in a company setting, things are quite different. Your boss may assign you new tasks that could require writing a lot of custom scripts. This can become a problem for other team members and contractors, as such scripts are often undocumented and don’t follow industry standards.

In this case, I would recommend using Kubernetes (k8s), but only if the company has a dedicated Kubernetes team with an established on-call rotation. Alternatively, I suggest leveraging a managed cloud service like ECS Fargate to handle container orchestration.

There’s also strong competition in the "Container as a Service" (CaaS) space, with smaller and more cost-effective options available if you prefer to avoid the major cloud providers. Overall, these CaaS solutions require far less maintenance compared to managing your own cluster.

Yes, but the people just cannot comprehend the complexity of it. Even my academic professor for my FYP back when was an undergrad, now he reverted back to Docker Compose, citing the integration is so convoluted that developing for it is very difficult. That's why I'm aiming to cut down the complexity of Kubernetes with a low-friction, turnkey solution, but I guess the angel investors in Hong Kong aren't buying into it yet. I'm still aiming to try again after 2 years when I can at least get an MVP that is complete though (I don't like to present imperfect stuff, either you just have the idea or you give me the full product and not half baked shit)

One can build a better container orchestration than kubernetes; things don't need to be that complex.

Like, okay, if that's how you see it, but what's with the tone and content?

The tone's vapidity is only comparable to the content's.

This reads like mocking the target audience rather than showing them how you can help.

A write up that took said "pile of shell scripts that do not work" and showed how to "make it work" with your technology of choice would have been more interesting than whatever this is.

I was using some ansible playbook scripts to deploy to production some web app. One day the scripts stopped working because of a boring error about python version mismatch.

I rewrite all the deployment scripts with bash (took less than a hour) and never had a problem since.

Morality: it's hard to find the right tool for the job

For my own websites, I host everything on a a single $20/month hetzner instance using https://dokploy.com/ and I'm never going back.

Why do I feel this is not so simple as the compiler scenario?

I've seen a lot of "piles of YAML", even contributed to some. There were some good projects that didn't end up in disaster, but to me the same could be said for the shell.

I was very scared of K8s for a long time then we started using it and it's actually great. Much less complex than its reputation suggests.

I thought k8s might be a solution so I decided to learn through doing. It quickly became obvious that we didn't need 90% of its capabilities but more important it'd put undue load/training on the rest of the team. It would be a lot more sensible to write custom orchestration using the docker API - that was straightforward.

Experimenting with k8s was very much worthwhile. It's an amazing thing and was in many ways inspirational. But using it would have been swimming against the tide so to speak. So sure I built a mini-k8s-lite, it's better for us, it fits better than wrapping docker compose.

My only doubt is whether I should have used podman instead but at the time podman seemed to be in an odd place (3-4 years ago now). Though it'd be quite easy to switch now it hardly seems worthwhile.

You did a no-SQL, you did a serverless, you did a micro-services. This makes it abundantly clear you do not understand the nature of your architectural patterns and the multiplicity of your offenses.

I wish the world hadn't consolidated around Kubernetes. Rancher was fantastic. Did what 95% of us need, and dead simple to add and manage services.

Started with a large shell script, the next itération was written in go and less specific. I still think for some things, k8s is just too much

https://github.com/mildred/conductor.go/

For the uninitiated: how does k8s handle OS upgrades? If development moves to next version of Debian, because it should eventually, are upgrades, for example, 2x harder vs docker-compose? 2x easier? About the same? Is it even right question to ask?

Friend, you built a J2EE server

i'm at this crossroads right now. somebody talk me out of deploying a dagster etl on azure kubernetes service rather than deploying all of the pieces onto azure container apps with my own bespoke scripts / config

I am 100% sure that the author of this post has never "built a kubernetes", holds at least one kubernetes cert, and maybe even works for a company that sells kubernetes products and services. Never been more certain of anything in my life. You could go point by point but its just so tiring arguing with these people. Like, the whole "who will maintain these scripts when you go on vacation" my brother in christ have you seen the kubernetes setups some of these people invent? They are not easier to be read into, this much is absolute. At least a shell script has a chance of encoding all of its behavior in the one file, versus putting a third of its behavior in helm variables, a third in poorly-named and documented YAML keys, and a third in some "manifest orchestrator reconciler service deployment system" that's six major versions behind an open source project that no one knows who maintains anymore because their critical developer was a Belarusian 10x'er who got mad about a code of conduct that asked him to stop mispronouning contributors.

>Tired, you parameterize your deploy script and configure firewall rules, distracted from the crucial features you should be working on and shipping.

Where's your Sysop?

Swarm Mode ftw!

Dear friend, you have made a slippery slope argument.

Dear friend, you should first look into using Nomad or Kamal deploy instead of K8S

why adding complexity when many services don't even need horizontal scaling, servers are powerful enough that if you're not stupid to write horrible code, it's fine for millions of requests a day without much of work

Infra person here, this is such the wrong take.

> Do I really need a separate solution for deployment, rolling updates, rollbacks, and scaling.

Yes it's called an ASG.

> Inevitably, you find a reason to expand to a second server.

ALB, target group, ASG, done.

> Who will know about those undocumented sysctl edits you made on the VM

You put all your modifications and CIS benchmark tweaks in a repo and build a new AMI off it every night. Patching is switching the AMI and triggering a rolling update.

> The inscrutable iptables rules

These are security groups, lord have mercy on anyone who thinks k8s network policy is simple.

> One of your team members suggests connecting the servers with Tailscale: an overlay network with service discovery

Nobody does this, you're in AWS. If you use separate VPCs you can peer them but generally it's just editing some security groups and target groups. k8s is forced into needing to overlay on an already virtual network because they need to address pods rather than VMs, when VMs are your unit you're just doing basic networking.

You reach for k8s when you need control loops beyond what ASGs can provide. The magic of k8s is "continuous terraform," you will know when you need it and you likely never will. If your infra moves from one static config to another static config on deploy (by far the usual case) then no k8s is fine.

Even without needing to spawn additional Docker containers, I think people are more afraid of Kubernetes than is warranted. If you use a managed K8s service like Azure, AWS, GCP, and tons of others provide, it's... Pretty simple and pretty bulletproof, assuming you're doing simple stuff with it (i.e. running a standard web app).

The docs for K8s are incredibly bad for solo devs or small teams, and introduce you to a lot of unnecessary complexity upfront that you just don't need: the docs seem to be written with megacorps in mind who have teams managing large infrastructure migrations with existing, complex needs. To get started on a new project with K8s, you just need a pretty simple set of YAML files:

1. An "ingress" YAML file that defines the ports you listen to for the outside world (typically port 80), and how you listen to them. Using Helm, the K8s package manager, you can install a simple default Nginx-based ingress with minimal config. You probably were going to put Nginx/Caddy/etc in front of your app anyway, so why not do it this way?

2. A "service" YAML file that allocates some internal port mapping used for your web application (i.e. what port do you listen on within the cluster's network, and what port should that map to for the container).

3. A "deployment" YAML file that sets up some number of containers inside your service.

And that's it. As necessary you can start opting into more features; for example, you can add health checks to your deployment file, so that K8s auto-restarts your containers when they die, and you can add deployment strategies there as well, such as rolling deployments and limits on how many new containers can be started before old ones are killed during the deploy, etc. You can add resource requests and limits e.g. make sure my app has at least 500MB RAM, and kill+restart it if it cross 1GB. But it's actually really simple to get started! I think it compares pretty well even to the modern Heroku-replacements like Fly.io... It's just that the docs are bad and the reputation is that it's complicated — and a large part of that reputation is from existing teams who try to do a large migration, and who have very complex needs that have evolved over time. K8s generally is flexible enough to support even those complex needs, but... It's gonna be complex if you have them. For new projects, it really isn't. Part of the reason other platforms are viewed as simpler IMO is just that they lack so many features that teams with complex needs don't bother trying to migrate (and thus never complain about how complicated it is to do complicated things with it).

You can have Claude or ChatGPT walk you through a lot of this stuff though, and thereby get an easier introduction than having to pore through the pretty corporate official docs. And since K8s supports both YAML and JSON, in my opinion it's worth just generating JSON using whatever programming language you already use for your app; it'll help reduce some of the verbosity of YAML.

Now compare cloud bills.

k8s is the API. Forget the implementation, it's really not that important.

Folks that get tied up in the "complexity" argument are forever missing the point.

Dear Friend,

This fascination with this new garbage-collected language from a Santa Clara vendor is perplexing. You’ve built yourself a COBOL system by another name.

/s

I love the “untested” criticism in a lot of these use-k8s screeds, and also the suggestion that they’re hanging together because of one guy. The implicit criticism is that doing your own engineering is bad, really, you should follow the crowd.

Here’s a counterpoint.

Sometimes just writing YAML is enough. Sometimes it’s not. Eg there are times when managed k8s is just not on the table, eg because of compliance or business issues. Then you’ve to think about self-managed k8s. That’s rather hard to do well. And often, you don’t need all of that complexity.

Yet — sometimes availability and accountability reasons mean that you need to have a really deep understanding of your stack.

And in those cases, having the engineering capability to orchestrate isolated workloads, move them around, resize them, monitor them, etc is imperative — and engineering capability means understanding the code, fixing bugs, improving the system. Not just writing YAML.

It’s shockingly inexpensive to get this started with a two-pizza team that understands Linux well. You do need a couple really good, experienced engineers to start this off though. Onboarding newcomers is relatively easy — there’s plenty of mid-career candidates and you’ll find talent at many LUGs.

But yes, a lot of orgs won’t want to commit to this because they don’t want that engineering capability. But a few do - and having that capability really pays off in the ownership the team can take for the platform.

For the orgs that do invest in the engineering capability, the benefit isn’t just a well-running platform, it’s having access to a team of engineers who feel they can deal with anything the business throws at them. And really, creating that high-performing trusted team is the end-goal, it really pays off for all sorts of things. Especially when you start cross-pollinating your other teams.

This is definitely not for everyone though!