“Let’s use Kubernetes.” Now you have eight problems | Hacker News Reader

“Let’s use Kubernetes.” Now you have eight problems

pythonspeed.com

719 pointssigna11469 comments

The odd thing about having 20 years of experience (while simultaneously being wide-eyed about new tech), is that I now have enough confidence to read interesting posts (like any post on k8s) and not think "I HAVE to be doing this" – and rather think "good to know when I do need it."

Even for the highest scale app I've worked on (which was something like 20 requests per second, not silicon valley insane but more than average), we got by perfectly fine with 3 web servers behind a load balancer, hooked up to a hot-failover RDS instance. And we had 100% uptime in 3 years.

I feel things like Packer (allowing for deterministic construction of your server) and Terraform are a lot more necessary at any scale for generally good hygiene and disaster recovery.

I have, at various times in my career, tried to convince others that there is an awful, awful lot of stuff you can get done with a few copies of nginx.

The first “service mesh” I ever did was just nginx as a forward proxy on dev boxes, so we could reroute a few endpoints to new code for debugging purposes. And the first time I ever heard of Consul was in the context of automatically updating nginx upstreams for servers coming and going.

There is someone at work trying to finish up a large raft of work, and if I hadn’t had my wires crossed about a certain feature set being in nginx versus nginx Plus, I probably would have stopped the whole thing and suggested we just use nginx for it.

I think I have said this at work a few times but might have here as well: if nginx or haproxy could natively talk to Consul for upstream data, I’m not sure how much of this other stuff would have ever been necessary. And I kind of feel like Hashicorp missed a big opportunity there. Their DNS solution, while interesting, doesn’t compose well with other things, like putting a cache between your web server and the services.

I think we tried to use that DNS solution a while back and found that the DNS lookups were adding a few milliseconds to each call. Which might not sound like much except we have some endpoints that average 10ms. And with fanout, those milliseconds start to pile up.

> I think I have said this at work a few times but might have here as well: if nginx or haproxy could natively talk to Consul for upstream data, I’m not sure how much of this other stuff would have ever been necessary.

To be fair, half of the API Gateways and edge router projects out there are basically nginx with a custom consul-like service bolted on.

You can do get around the nginx Plus requirement by using a module like ngx_mruby to customize the backend selection. I haven't measured the latency, so it may not be suitable for your 10ms example.

Here's a post I wrote on that ~4 years ago that uses an in-process cache [1]. It'd be fairly easy to add an endpoint to update it and pull data from Consul. I agree with you, it's a missed opportunity - there are alternatives, but being able to rely on a battletested server like nginx makes a difference.

[1] http://hokstadconsulting.com/nginx/mruby-virtualhosts

As a fan of nginx, I really liked your comment. In sleuthing after reading I came across this:

https://learn.hashicorp.com/consul/integrations/nginx-consul...

It appears that if the consul client has the right permissions it can restart the nginx service after editing the configuration file. It uses the consul templating engine to generate an nginx config file.

I haven't tried it myself but it looks promising.

> if nginx or haproxy could natively talk to Consul for upstream data, I’m not sure how much of this other stuff would have ever been necessary

Airbnb's Smartstack works well for this. It's not built in to nginx as a module, but I think it's more composeable this way.

Blog post: https://medium.com/airbnb-engineering/smartstack-service-dis...

The two main components are nerve (health checking of services + writing a "I'm here and healthy" znode into zookeeper, https://github.com/airbnb/nerve) and synapse (subscribes to subtrees in zookeeper, updates nginx/haproxy/whatever configs with backend changes, and gracefully restarts the proxy, https://github.com/airbnb/synapse).

It's fairly pluggable too if you don't want to use haproxy/nginx.

Then you have a dependency on zookeeper when you already have consul... it seems like consul template + nginx or haproxy is the solution hashicorp went with.

I totally agree, especially about being able to serve content out of a cache instead of files. It would simplify some of my configuration especially for static sites that point to a CDN.

I like what Caddy is doing, exposing their entire configuration through a REST interface.

You should check fabio ( https://github.com/fabiolb/fabio ), it is really awesome ).

I 100% agree with you, I've been using Consul for four years now to run 100s of services in 1000s of VMs across datacenters distributed globally and not once I saw the need for anything else...

Maybe I just don't have the scale to find service mesh or kubernetes interesting. Nomad however is something I am willing to give a go for stateless workflows that I would usually provision a VM running a single docker container for.

> I have, at various times in my career, tried to convince others that there is an awful, awful lot of stuff you can get done with a few copies of nginx.

under the load point of view, yes. absolutely. no doubt.

under the speed of action, no way. if your k8s cluster is properly managed, you can let developers do most of the operations work themselves, confined into their namespaces, touching only the kind of resources that you tell them to touch.

I personally would advise against using DNS for service discovery, it wasn't designed for that.

The few milliseconds that you get though, most likely is due to your local machine not having DNS caching configured, this is quite common in Linux. Because of that every connection triggers a request to DNS server. You can install unbound for example to do it. nscd or sssd can also be configured to do some caching.

> I personally would advise against using DNS for service discovery, it wasn't designed for that.

It was designed for that but the SRV record requires protocols and their clients to explicitly support it. You can argue that this an unreasonable design choice but load balancers like HAproxy do support SRV records.

Why is dns not used for service discovery? The internet as a whole uses it for service discovery currently

> I think we tried to use that DNS solution a while back and found that the DNS lookups were adding a few milliseconds to each call. Which might not sound like much except we have some endpoints that average 10ms. And with fanout, those milliseconds start to pile up.

Don't resolve DNS inline rather on every DNS update, resolve it and insert new IP addresses.

Correct me if I'm wrong, but I believe Consul, lacking a mesh of its own, is leveraging the early 1990's era trick of using round robin DNS to split load over available servers.

Caching those values for very long subverts the point of the feature.

Kubernetes has complexity for a reason. It's trying to solve complex problems in a standardized and mature manner.

If you don't need those problems solved then it's not going to benefit you a whole lot.

Of course if you are using docker already and are following best practices with containers then converting to Kubernetes really isn't that hard. So if you do end up needing more problems solved then you are willing to tackle on your own then switching over is going to be on the table.

The way I think about it is if you are struggling to deploy and manage the life cycle of your applications... fail overs, rolling updates, and you think you need some sort of session management like supervisord or something like to manage a cloud of processes and you find yourself trying to install and manage applications and services developed by third parties....

Then probably looking at Kubernetes is a good idea. Let K8s be your session manager, etc.

I would qualify that a little more. If you are using docker and deploying to a cloud environment already, then moving to a cloud-managed kubernetes cluster really isn't that hard.

I've seen too many full-time employees eaten up by underestimating what it takes to deploy and maintain a kubernetes cluster. Their time would have been far better spent on other things.

That story is getting a lot easier but historically was awful

What is a "mature manner"?

For example by covering all of the NFRs.

You don't always find open source programs that have dedicated so much effort to security, monitoring, governance etc. And doing so in a very professional and methodical way.

There's always more than one way to do things, and it's good to be aware of the trade-offs that different solutions provide. I've worked with systems like you describe in the past, and in my experience you always end up needing more complexity than you might think. First you need to learn Packer, or Terraform, or Salt, or Ansible - how do you pick one? How do you track changes to server configurations and manage server access? How do you do a rolling deploy of a new version - custom SSH scripts, or Fabric/Capistrano, or...? What about rolling back, or doing canary deployments, or...? How do you ensure that dev and CI environments are similar to production so that you don't run into errors from missing/incompatible C dependencies when you deploy? And so on.

K8s for us provides a nice, well-documented abstraction over these problems. For sure, there was definitely a learning curve and non-trivial setup time. Could we have done everything without it? Perhaps. But it has had its benefits - for example, being able to spin up new isolated testing environments within a few minutes with just a few lines of code.

> First you need to learn Packer, or Terraform, or Salt, or Ansible - how do you pick one?

You don't. These are complementary tools.

Packer builds images. Salt, Ansible, Puppet or Chef _could_ be used as part of this process, but so can shell scripts (and given the immutability of images in modern workflows, they are the best option).

Terraform can be used to deploy images as virtual machines, along with the supporting resources in the target deployment environment.

> Salt, Ansible, Puppet or Chef _could_ be used as part of this process, but so can shell scripts

I don't see the point of your post, and frankly sounds like nitpicking.

Ansible is a tool designed to execute scripts remotely through ssh on a collection of servers, and makes the job of writing those scripts trivially easy by a) offering a DSL to write those scripts as a workflow of idempotent operations, and b) offer a myriad of predefined tasks that you can simply add to your scripts and reuse.

Sure, you can write shell scripts to do the same thing. But that's a far lower level solution to a common problem, and one that is far hardsr and requires far more man*hours to implement and maintain.

With Ansible you only need to write a list of servers, ensure you can ssh into them, and write a high-level description of your workflow as idempotent tasks. It takes you literally a couple of minutes to pull this off. How much time would you take to do the same with your shell scripts?

Yes. Three web servers and a load balancer is fine. Three web servers and a load balancer, repeated 1,000 times across the enterprise in idiosyncratic ways and from scratch each time, is less fine. That’s where Kubernetes-shaped solutions (like Mesos that came before it) become appropriate.

You can get a lot done with a sailboat. For certain kinds of problems you might genuinely need an aircraft carrier. But then you’d better have a navy. Don’t just wander onto the bridge and start pressing buttons.

You're right.

However, a lot of new (or just bad) devs miss the whole Keep It Simple Stupid concept and think that they NEED Kubernetes-shaped solutions in order to "do it the right way".

Many times three web servers and a load balancer are exactly what you need.

And then what about when you need to add monitoring, logging, APM, tracing, application metrics etc.

Suddenly you have gone from 3 instances to 20.

I get the point but I’ve also seen three web servers and a load balancer go terribly wrong at a number of places as well. L8s provides a lot of portability that you would need a disciplined and experienced engineer to match with raw deployments.

> Many times three web servers and a load balancer are exactly what you need.

May be, just may be, they want k8s not to create value but to develop/enrich resumes - in order to signal that they are smart and can do complex stuff.

I think anyone considering these wild setups should read about how stackowerflow is hosted on a couple of IIS servers. It’s a sobering reminder that you often don’t need the new cool.

Joel, if any, has always been super pragmatic and very realistic.

Not to misunderstand. For FogBugz they wrote a compiler/transpiler for Asp and PHP because the product had to run on customers servers - because "clients should not leave their private data at another company".

Google it, great read.

Tried to google for it, couldn't find anything - could you provide a link, please?

> I think anyone considering these wild setups should read about how stackowerflow is hosted on a couple of IIS servers.

Apparently in 2019 stack overflow was hosted in at least 25 servers, including 4 servers dedicated to run haproxy.

https://meta.stackexchange.com/questions/10369/which-tools-a...

Nothing much happens if SO goes down, they are not doing a ton of business transactions.

That's right. As opposed to stock exchange software, which runs on complex micro-services cloud k8s thing-as-a-thing virtualized rotozooming engines. Wait, no, it's literally just good-old n-tier architecture with one big server process and some database backend.

Pet food delivery startups use k8s to manage their MEAN stack. Meanwhile grown-ups still have "monoliths" connected to something like Oracle, DB2 or MS SQL server, because that's obviously the most reliable setup.

The cloud/k8s stuff is an ad-hoc wannabe mainframe built on shaky foundations.

Nothing much? The world stops producing software:)

A typical PHP application that does a bit of database updating per request, gets some new data from the DB and templates it should handle 20 requests per second on a single $20/month VM. And in my experience from the last years, VMs have uptime >99.99% these days.

What made you settle on a multi-machine setup instead? Was it to reach higher uptime or were you processing very heavy computations per request?

Higher uptime and more computation, although this was mostly C# so very efficiently run code. It was an e-commerce site doing +100MM a year.

There was little to no room for error. I once introduced a bug in a commit that, in less than an hour, cost us $40,000. So it wasn't about performance.

Also this was 9 years ago. So adjust for performance characteristics from back then.

100 000 000$ a year with only 20 requests a second? That's some crazy revenue per request, 100 000 000 / (365 * 24 * 60 * 60) = 3.17$ per request!

What were you selling?

A single server isn't redundant. 3 behind a load balancer, where each is sized to handle 50% of the volume lets you take systems offline for maintenance without incurring downtime.

Heck, Raspberry Pis have more horsepower than the webservers in the cluster I ran around Y2k.

For performance context: nginx on a $5 DO droplet does 600 requests per second on static file.

Serving static files with Elixir/Phoenix has a performance of 300 requests per second.

Python+gunicorn serves about 100 requests per second of JSON from postgres data.

(outside of GP's reply) Generically, life is messy and unpredictable, never put all your eggs in one basket. Your cloud server is sitting on a physical hyp which will need maintenance or go down, or even something in your VM goes wrong or needs maintenance. Using a basic N+1 architecture allows for A to go down and B to keep running while you work on A - whether that's DNS, HTTP or SQL etc.

If your physical hyp dies, how do you redirect your traffic to a different one?

The odd thing about having 10 years of experience as a consultant is that you know when to write "Kubernetes" into a project proposal, even though everyone agrees that it'll be a sub-optimal solution.

But both you and their tech lead want to be able to write "used Kubernetes" on your CV in the future, plus future-oriented initiatives inside your contact's company tend to get more budget allocated to them. So it's a sound decision for everyone and for the health of the project to just go with whatever tech is fancy enough, but won't get into the way too badly.

Enter Kubernetes, the fashionable Docker upgrade that you won't regret too badly ;)

I worked on a transacted 20-60k messages/s system and am not sure K8S wouldn't be a hindrance there... Imagine writing Kafka using K8S and microservices.

I don't know about "lot more necessary". The images are one part of the equation especially to meet various regulations. There is a ton to running a large scale service especially if you are the service that the people who are posting how wicked smart they are at k8 service runs on. Google found that out yesterday when they said "oh hey people expect support maybe we should charge". That is not new for grown ups.

The cloud existed before k8 and k8's creator has a far less mature cloud than AWS or Azure.

But this thread has convinced me of one thing. It's time to re-cloak and never post again because even though the community is a cut above some others at the end of the day it's still a bunch of marks and if you know the inside it is hard to bite your lip.

The most important video I've ever watched for my career and sanity: https://www.youtube.com/watch?v=bzkRVzciAZg

Who is giving you 100% uptime? All major providers (AWS, GCP, Azure, etc) all have had outages in the past 3 years. And that level of infrastructural failure doesn't care about whether or not you're using k8s.

EKS (AWS Kubernetes) has the control plane across 3 AZs.

It is very rare to have a complete region outage so it is pretty close to 100% uptime.

Not OP but you can achieve higher availability through means like redundancy, availability zones, multi-region deployments, etc.

> Even for the highest scale app I've worked on (which was something like 20 requests per second,

Kubernetes is not for you. 5kQPS times a hundred or more services and Kubernetes fits the bill.

> And we had 100% uptime in 3 years.

Not a single request failed in that time serving at 20 QPS? I'm a little suspicious.

Regardless, if you were handling 10 or 100 times this volume to a single service, you'd want additional systems in place to assure hitless deploys.

> Not a single request failed in that time serving at 20 QPS? I'm a little suspicious.

Things that aren't monitored are also things that don't fail.

Same. I like trying out new things, so I have a feel for what they're good for. I tried setting up Kubernetes for my home services and pretty quickly got to "nope!" As the article says, it surely makes sense at Google's scale. But it has a large cognitive and operational burden. Too large, I'd say, for most one-team projects.

I'm in a similar boat, only my eyes are wide, glazed over, and I'm lost in the word salad...which only seems to be getting worse.

These kinds of posts always focus on the complexity of running k8s, the large amount of concepts it has, the lack of a need to scale, and that there is a "wide variety of tools" that can replace it, but the advice never seems to become more concrete.

We are running a relatively small system on k8s. The cluster contains just a few nodes, a couple of which are serving web traffic and a variable number of others that are running background workers. The number of background workers is scaled up based on the amount of work to be done, then scaled down once no longer necessary. Some cronjobs trigger every once in a while.

It runs on GKE.

All of this could run on anything that runs containers, and the scaling could probably be replaced by a single beefy server. In fact, we can run all of this on a single developer machine if there is no load.

The following k8s concepts are currently visible to us developers: Pod, Deployment, Job, CronJob, Service, Ingress, ConfigMap, Secret. The hardest one to understand is Ingress, because it is mapped to a GCE load balancer. All the rest is predictable and easy to grasp. I know k8s is a monster to run, but none of us have to deal with that part at all.

Running on GKE gives us the following things, in addition to just running it all, without any effort on our part: centralized logging, centralized monitoring with alerts, rolling deployments with easy rollbacks, automatic VM scaling, automatic VM upgrades.

How would we replace GKE in this equation? what would we have to give up? What new tools and concepts would we need to learn? How much of those would be vendor-specific?

If anyone has a solution that is actually simpler and just as easy to set up, I'm very much interested.

I'm in the same camp. I think a lot of these anti-k8s articles are written by software developers who haven't really been exposed to the world of SRE and mostly think in terms of web servers.

A few years ago I joined a startup where everything (including the db) was running on one, not-backed-up, non-reproducible, VM. In the process of "productionizing" I ran into a lot of open questions: How do we handle deploys with potentially updated system dependencies? Where should we store secrets (not the repo)? How do we manage/deploy cronjobs? How do internal services communicate? All things a dedicated SRE team managed in my previous role.

GKE offered a solution to each of those problems while allowing me to still focus on application development. There's definitely been some growing pains (prematurely trying to run our infra on ephemeral nodes) but for the most part, it's provided a solid foundation without much effort.

Exactly, all these articles seem to come from operational novices, who think in terms of 1-2 click solutions. K8s is not a 1-2 click solution, and clearly isn't designed to be; it's solving particular tough operational problems that if you don't know exist in the first place you won't really be able to evaluate these kinds of things properly.

If a group literally doesn't have the need to answer questions like the ones you posed, then OK, don't bother with these tools. But that's all that needs to be said - no need for a new article every week on it.

> it's solving particular tough operational problems that if you don't know exist in the first place

They probably don't exist for the majority of people using it. We are using k8s for when we need to scale, but at the moment we have a handful of customers and it isn't changing quickly any time soon.

Remember that not everyone is using an operational model that would benefit from K8s.

Yet, they write articles that prescribe their operational model on the rest of the world.

> I think a lot of these anti-k8s articles are written by software developers who haven't really been exposed to the world of SRE ...

Think again. There's plenty of SREs at FAANGs that dislike the unnecessary complexity of k8s, docker and most "hip" devops stuff.

From my knowledge, pretty much all FAANGs got their own tooling in place before k8s went public, covering those same issues.

Now imagine you have to do it from scratch.

Agreed. I've been saying for years that if you go with Docker-Compose, or Amazon ECS, or something lower level, you are just going to end up rebuilding a shittier version of Kubernetes.

I think the real alternative is Heroku or running on VMs, but then you do not get service discovery, or a cloud agnostic API for querying running services, or automatic restarts, or rolling updates, or encrypted secrets, or automatic log aggregation, or plug-and-play monitoring, or VM scaling, or an EXCELLENT decoupled solution for deploying my applications ( keel.sh ), or liveness and readiness probes...

But nobody needs those things right?

You do in fact get a lot of this stuff with ECS and Fargate - rolling updates, automatic restart, log aggregation, auto scaling, some discovery bits, healthchecks, Secrets Manager or Parameter Store if you want, etc.

This. We’ve been chugging along happily on Fargate for a while now. We looked into EKS, but there is a ton of stuff you have to do manually that is built into Fargate or at least Fargate makes it trivial to integrate with other AWS services (logging, monitoring, IAM integration, cert manager, load balancers, secrets management, etc). I’d like to use Kubernetes, but Fargate just works out of the box. Fortunately, AWS seems to be making EKS better all the time.

And suddenly you have a MUCH higher degree of vendor lock-in than on k8s.

Amen to that. We use ECS to run some millions of containers on thousands of spot nodes for opportunistic jobs, and some little Fargate for where we need uptime. It's a LOT less to worry about.

Pesky monitoring and logging just makes you notice bugs more and get distracted from making the world a better place

Why would docker be shittier? It's easier and flexible.

Eg. Sidecar pattern resolves most things (eg. logging)

1000%. If you take a little bit of time to learn k8s and run it on a hosted environment (e.g. EKS), it’s a fantastic solution. We are much happier with it than ECS, Elastic Beanstalk, etc.

> If anyone has a solution that is actually simpler and just as easy to set up, I'm very much interested.

Sure. @levelsio runs Nomad List (~100k MRR) all on a single Linode VPS. He uses their automated backups service, but it's a simple setup. No k8s, no Docker, just some PHP running on a Linux server.

As I understand it, he was learning to code as he built his businesses.

https://twitter.com/levelsio/status/1177562806192730113

Many startups are not as resource efficient. The ones I am familiar with spend 50%+ of their MRR on cloud costs.

My first production k8s use was actually due to resource efficiencies. We looked at the >50 applications we had to serve, the technical debt that would lead us down the road of building customized distribution to avoid package requirements incompabilties, and various other things, and decided to go with containers - just to avoid the conflicts involved.

Thanks to k8s, we generally keep to 1/5th of the original cost, thanks to bin packing of servers, and sleep sounder thanks to automatic restarts of failed pods, ability to easily allocate computing resources per container, globall configure load balancing (we had to scratch use of cloud-provider's load balancer because our number of paths was too big for URL mapping API).

Everything can be moved to pretty much every k8s hosting that runs 1.15, biggest difference would be hooking the load balancer to the external network and possibly storage.

That's very surprising to me! As an employee at multiple startups in multiple countries, I've never seen cloud costs anywhere near payroll.

You're asking exactly what I've been wondering. The answer in this thread this so far has been "maybe dokku." I can totally buy that K8s is overkill, but the alternatives for small scale operators seem to require a lot more work internally than just using a K8s service.

same we use kubernet not for scale but for the environment repeatability. we can spin any branch at any time on any provider and be sure it's exactly as we have it in production down to networking and routing, to built that out of plain devops tools would require a lot more in depth knowledge and it won't port exactly one provider to another

> These kinds of posts always focus on the complexity of running k8s...

Yes but that is also the worst already that you could criticize about k8s.

Complexity is dangerous because if things are growing beyond a certain threshold X you will have side effects that nobody can predict, a very steep learning curve and therefor many people screwing up something in their (first) setups as well as maintainability nightmares.

Probably some day someone will prove me wrong but right now one of my biggest goals to improve security, reliability and people being able to contribute is reducing complexity.

After all this is what many of us do when they refactor systems.

I am sticking with the UNIX philosophy at this point and in the foreseeable future I will not have a big dev-team at my disposal as companies like Alphabet have to maintain and safe-guard all of this complexity.

From a developer perspective, k8s seems ripe for disruption.

It does a bunch of junk that is trivial to accomplish on one machine - open network ports, keep services running, log stuff, run in a jail with dropped privileges, and set proper file permissions on secret files.

The mechanisms for all of this, and for resource management, are transparent to unix developers, but in kubernetes they are not. Instead, you have to understand a architectural spaghetti torrent to write and execute “hello world”.

It used to be similar with RDBMS systems. It took months and a highly paid consultant to get a working SQL install. Then, you’d hire a team to manage the database, not because the hardware was expensive, but because you’d dropped $100k’s (in 90’s dollars) on the installation process.

Then mysql came along, and it didn’t have durability or transactions, but it let you be up and running in a few hours, and have a dynamic web page a few hours after that. If it died, you only lost a few hours or minutes of transactions, assuming somone in your organization spent an afternoon learning cron and mysqldump.

I imagine someone will get sufficiently fed up with k8s to do the same. There is clearly demand. I wish them luck.

It seems to be. When you start implementing something, you'll soon find that most of that complexity is inherent, not accidental. Been there, done that, didn't even get the T-Shirt.

Today it's much easier to package nicer API on top of the rather generic k8s one. There are ways to deploy it easier (in fact, I'd wager that a lot of complexity in deploying k8s is accidental due to deploy tools themselves, not k8s itself. Just look at OpenShift deploy scripts...)

This, kubernetes is container orchestration framework. If you know your needs then you have opportunity to make a better decision and planning. I had similar experience with ingress also I would like to add installing Kubernetes on bare metal is a pain in the neck, even with kubespray.

Here is a comparison with other frameworks, from 2018: https://arxiv.org/pdf/2002.02806.pdf

Running k8s on GKE is the only rational choice for anyone who isnt a large enterprise with a team of Google SREs to support k8s.

Period.

I'm curious how, with your experience, that you came to the conclusion that k8s is a monster to run?

"Pod, Deployment, Job, CronJob, Service, Ingress, ConfigMap, Secre"

Wow as a new developer coming onboard your company, I will walk out the door after seeing that, and the fact that you admit its a small serivce.

The names may seem daunting, but here's what they do: a Pod is one or more containers, usually 1, that run an application. A Deployment manages a number of the same pods, making sure the right number is running at all times and rolling out new versions. A Job runs a pod until it succeeds. A CronJob creates a job on a schedule. A service provides a DNS name for pods of a certain kind, automatically load balancing between multiple of them. An Ingress accepts traffic from the outside and routes it to services. A ConfigMap and a Secret are both just sets of variables to be used by other things, similar to config files but in the cluster.

It's a small service according to " web scale", but it's serving, and vital for, a good number of customers.

People seem to hate learning vocabulary for concepts that they are already dealing with. Personally I love having a common vocabulary to have precise conversations with other developers.

It's an afternoon worth of research to understand the basic concepts. Then, with the powerful and intuitive tooling you can spin up your own cluster on your computer in minutes and practice deploying containers that:

- are automatically assigned to an appropriate machine(node) based on explicit resource limits you define, enabling reliable performance

- horizontally scale (even automatically if you want!)

- can be deployed with a rolling update strategy to preserve uptime during deployments

- can rollback with swiftness and ease

- have liveness checks that restart unhealthy apps(pods) automatically and prevent bad deploys from being widely released

- abstracts away your infrastructure, allowing these exact same configs to power a cluster on-prem, in the cloud on bare metal or vms, with a hosted k8s service, or some combination of all of them

All of that functionality is unlocked with just a few lines of config or kubectl command, and there are tools that abstract this stuff to simplify it even more or automate more of it.

You definitely want some experienced people around to avoid some of the footguns and shortcuts but over the last several years I think k8s has easily proven itself as a substantial net-positive for many shops.

So why should I do all of that instead of throwing a little money at AWS, run ECS and actually spend my time creating my product?

Heck, if my needs are simple enough why should I even use ECS instead of just putting my web app on some VM's in an auto-scaling group behind a load balancer and used managed services?

> It's an afternoon worth of research to understand the basic concepts. Then, with the powerful and intuitive tooling you can spin up your own cluster on your computer in minutes and practice deploying containers that.

Source? I’ve never heard of someone going from “what’s kubernetes?” to a bare metal deployment in 4 hours.

That’s a pretty small API. I don’t know what developers are doing if they can’t learn that in stride.

Really? If someone told me they were going to write all the glue code that basically gets you the same thing a UI deployment of k8s and a couple yaml files can provide, I’d walk out.

Reminds me of the business trying to reduce our spend on VMware licenses while keeping the same architecture.

A high level person actually asked me to reimplement vCenter :|

This, and the other articles like it, should be required reading on any "how to startup" list. I personally know startups for whom I believe drinking the k8s/golang/microservices kool-aid has cost them 6-12 months of launch delay and hundreds of thousands of dollars in wasted engineering/devops time. For request loads one hundredth of what I was handling effortlessly with a monolithic Rails server in 2013.

It is the job of the CTO to steer excitable juniors away from the new hotness, and what might look best on their resumes, towards what is tried, true, and ultimately best for the business. k8s on day one at a startup is like a mom and pop grocery store buying SAP. It wouldn't be acceptable in any other industry, and can be a death sentence.

When I was younger, I was much more enticed with new technologies. But as I grow older, I've grown much more cynical. I just want to solve problems with ideally as little coding/thinking as possible.

When I was younger, I believed technology is developed to solve problems people have. Today, I've grown much more cynical, and believe that most technology is developed to sell worthless crap to other people, which may or may not occasionally do something useful for them (but not as much as it would do if the vendor actually cared).

When I was younger, I was already suspicious of hyped, marketing-driven technologies and lock-in. But as I grow older, I've grown more aware at how people constantly ignore the problem.

I just want to solve problems with ideally as little complexity as possible.

Nothing cynical about it.

Old-man-yells-at-cloud.

Anecdata: series B startup. First year was a single VM with two docker containers for api and nginx. Deploy was a one shot “pull new container, stop old, start new” shell command. Year 2 onwards, k8s. No regrets, we only needed to make our first dedicated ops hire after 15 engineers, due in large part to the infra being so easy to program.

I used GKE and I was also very familiar with k8s ahead of time. I would not recommend someone in my shoes to learn k8s from scratch at the stage I rolled it out, but if you know it already, it’s a solid choice for the first point that you want a second instance.

When people talk about companies using k8s too soon, they are talking about deploying it on your own, not using a hosted service like GCE. That’s a whole new ball game and takes 100x the effort.

Some seniors get exited by that crap as well.

Tech lead in my team is full of common sense when it comes to not getting exited by JavaScripts framework of the season. But he loves to add new tools to the back end. He is choosing the "best tool" for the job, but we have a small team and already have way more things than we can comfortably manage. Good enough tools that are already in our system would be more pragmatic.

Hopefully that's not a case of "must be seen to be doing something" syndrome. If you can use pre-existing tools and they serve the purpose, how easy or difficult is it to resist the "shift to this" pressure?

Exactly this. For most startups Heroku, Dokku, or plain docker is enough. The stack will certainly evolve as growth (and success) comes.

Building with 12-factor principles make that transition effortless when the time comes.

From experience:

Plain docker - hell on earth. Literally some of the worst stuff I had to deal with. A noticeable worsening vs. running the contents of the container unpacked in /opt/myapp.

Heroku, Dokku - Very depends. A dance between "Simple and works" and "Simple and Works but my Startup is bankrupt".

K8s - Do I have more than 1-2 custom deployed applications? Predictable cost model, simple enough to manage (granted I might be an aberration), easy to combine infrastructural parts with the money-making parts. Strong contender vs Heroku-like, especially on classic startup budget

I have desperately avoided K8s since it became popular, but this seems to be pretty opposite of everything else I've read? Can you share what specifically makes plain docker so terrible?

You seem like you know what you're talking about. What do you think about AWS RDS for db and EBS for auto-scaling and deployment? (It's my first fullstack product and it feels as if it's both a good developer experience and something that won't cost as an arm and a leg, so I just have to ask).

I run plain docker without issue.

What about raw systemd? It can do resource control, service monitoring and restart and seems pretty lightweight compared to Docker. Fewer ways to footgun with data being erased, no separate shells or finding a tool you need isn't available inside the container.

you can use systemd to manage your dockers

Or, you could use a distro with a sane init system, which eliminates all the systemd and reinvented wheel footguns.

The last time I installed ubuntu 18.04, DNS queries took ~5 seconds. It’s a well known issue, with no diagnosed root cause. The solutions involved uninstalling the local dns stack, starting with systemd’s resolver.

2018 was well after DNS was reliable. How can stuff like that break in a long term support release?

Two virtual machines are more than enough to a startup for the first 2 to 4 years.

One for Website + database, the other for monitoring?

I guess backups could just be snapshots or something, depending on how active the database is. ;)

While your average startup doesn't need to go "uberscale", they probably need to be highly available.

> I personally know startups for whom I believe drinking the k8s/golang/microservices kool-aid has cost them 6-12 months of launch delay and hundreds of thousands of dollars in wasted engineering/devops time.

If Kubernetes had only cost us a year and two hundred thousand dollars then we'd have been luckier than we actually are.

It definitely has a place, but it is so not a good idea for a small team. You don't need K8s until you start to build a half-assed K8s.

> You don't need K8s until you start to build a half-assed K8s.

which you start doing with more than 1 db server and more than one app server. until you realize you have a ansible script that is tied to your specific program. oh shit now you have two programs, and copied some stuff from ansible, but not everything is the same - damn. deployments occur a downtime (5 seconds), which some user notice - until you add like a thousand lines of ansible code. now you need monitoring and oh shit another ansible bloat, soon you outgrown k8s codebase with just ansible. (p.s. this does not account how you start your baremetal servers, etc. this would be another story)

What are you talking about? Just create two more virtual machines. Copy some files over and run `docker-compose up`. After that you only need to configure a load balancer.

>It is the job of the CTO to steer excitable juniors away from the new hotness, and what might look best on their resumes, towards what is tried, true, and ultimately best for the business.

Then they might simply join another startup or a big tech company as competition for good engineers is fierce. Startups also famously underpay versus larger companies so you need to entice engineers with something.

Well, when you pay your engineers 6-12 months of extra salary before you ship anything because they had to use Kubernetes-on-Highways to host this clever NoNoNoPleaseNoSQL DB hosted that some guy on Github wrote last week, hosted on ZeroNinesAsAService.com and with a new UI built in ThreeReact (the hot new React-based framework that implements an OpenGL interface that works on approximately 3% of devices in the wild right now, and approximately 0% of your target user base's devices), don't forget to account for that in the investor pitch and salary offers.

I mean, seriously, this is a startup killer. Our host wrote an essay a long time ago about beating standard companies stuck in boring old Java or C++ with your fast, agile Python code, but in 2020 it seems to me it's almost more important now to try to convince new startups to be a little more boring. Whatever your special sauce that you're bringing to market is, it isn't (with no disrespect to the relevant communities) that you're bringing in Rust or Nim or whatever for the first time ever, for Maximum Velocity. Just use Python, cloud technologies, and established databases. Win on solving your customer needs.

While by no means is everyone in the world using effective tech stacks well-chosen to meet the needs and without over-privileging "what everyone else is doing and what has always been done", enough people are now that it's probably not a competitive advantage anymore.

Honestly, you can beat most companies in just getting stuff out the door quickly.

(Excuse me, off to file incorporation papers for ZeroNines LLC. Why wonder whether your provider will be up when you can know? Nobody else in the business can make that promise!)

Maybe you need less engineers trained in the new hotness but just experience with, uh, older hotness. Which may be easier to find.

If they are more focused on playing with toys or polishing their resumes for their next job, then I'd want them to leave. Their goal should be understanding what users need and building it as simply and effectively as possible.

On the flip side, a lot of developers are more motivated by what they can actually build and release with their tools, rather than learning new and complicated tools for the heck of it. If I were running a company I'd much rather court devs in this group.

This is a really good argument for why startups should build the initial product with only the founding team, and hire only once you have more demand than you can possibly handle. You get mission-alignment from your technical team (because they only get paid if they ship and customers appear), and then finding and retaining engineers is a lot easier once you're clearly a rocket-ship, their stock options double in value every 6 months, and they become a manager after 6 months in the company.

It’s ok to let them go.

1000 users, almost 0 request per second / 10000 euro a month to deploy a very simple software on GKE in 3 continents and have some development instances.

Why? Because Docker and "scalability" it offered looked much better on the investor slides...

How? Instead of actually hiring someone that at least has experience with docker he decided it was very easy thing to learn so he did it him self and we ended up with thing like running two application in a same container, having database on containers that disappear (container restarts when ram is full is the best way to run a database) etc...

And after all that started talking about mirco-services and how cool are they for code decoupling... Of all the things... I don't work there anymore...

And if challenged on these reasons some people give (that supposedly have more experience) blanket statements like: "Docker is more safe by default thus we should use it..."

Maybe when you go thought these situations you get to write articles like this.

Of course containers, docker, k8 etc have their place, but in reality you can find all kinds of stunning non-sense.

I worked at a startup where the CTO was the impressionable junior and it caused all of those issues you described and more. I ended up leaving when I decided I shouldn't be having panic attacks in the middle of the night due to ridiculously tight deadlines that I couldn't meet because of the overhead introduced by k8s and microservices.

I've seen the pressure come from customers too, in the case of b2b between tech companies. My company embraced Kubernetes after years of customers asking us "what's your Kubernetes story?" and not liking the answer, "that doesn't solve any problems we have".

> It is the job of the CTO to steer excitable juniors away from the new hotness

Sometimes it's the CTO who is the excitable one pursuing new hotness...

Then the company is doomed.

Sure, it is the job of the CTO to steer juniors in an appropriate direction. But, and I hate to say this, isn't it also the job of the CTO to help source funding and it seems VCs like to go after the buzzwords?

I absolutely love Kubernetes, it makes my job so much easier...

I can’t understand for the life of me why any start up uses it, it’s insane.

The lack of type checking must have cost way more than standing up Golang services when the time came that you actually had customers though right?

People managed with dynamically typed languages for a long, long time in building pretty vast services. Static typing has its merits but it really depends on what you're building - if you're a bank, it offers excellent guarantees. If you're building something smaller scale or lower impact, you can cope if you're logical and have good tests.

Having been at a company that was starting to move things to Kubernetes, when it had absolutely no reason to, I can say that it was being done because: 1) the developers wanted to be able to say they knew how to use Kubernetes, when they applied for their next job (perhaps at a company big enough to need it) 2) the managers didn't really understand much about what it was, to evaluate if it was necessary, but 3) some of the managers wanted to say they had managed teams that used Kubernetes, for the same reason as the developers

Which is not to say that it should never be used. But we have a recurring pattern of really, really large companies (like FAANG) developing technologies that make sense for them, and then it gets used at lots of other companies that will never, ever be big enough to have it pay off. On the other hand, they now need 2-3x the developers they used to, because they have too many things going on, mostly related to solving scale problems they'll never have.

Don't use a semi-tractor trailer to get your groceries. Admit it when you're not a shipping company. For most of us, the compact car is a better idea.

Well, for engineers sometimes it's just interesting to learn new tech, you know.

And managers are ok with keeping the team motivated, especially if they can deliver new features while playing with the new tech.

UPDATE: I mean, it's not about resume in most cases I've seen. Usually, people who don't love programming do not care about what tech to use, so resume-oriented people are usually not very vocal about using new cool and shiny tech. It's nerds who are, that keeps them motivated.

Playing with new tech is fun. Using a nuclear weapon when a hammer would do is bad engineering.

All startups are simply temporarily embarrassed unicorns.

Ah, because no software project ever experienced problems due to their newly found inability to scale in any way.

Job interviews should always consider if the correct tool was used for the use case.

So, if someone used k8s where it was not needed, that experience means zilch:

1) it was the wrong tool for the job

2) it was not used at the right scale. So, if I need k8s to manage a really large deployment, someone who used k8s to manage 5 machines does not have the right experience since they never used it at my scale.

Before you get on a technical interview, an automated system, an HR person and a project manager (or similar) will have to pass on the application, which encourages putting buzzwords tech terms on a CV.

Sadly today fewer and fewer companies look at soft and engineering skills and prefer to hire people based on experience with specific tools.

> was starting to move things to Kubernetes, when it had absolutely no reason to

There is "absolutely no reason" to use a system that automatically handles blue/green deployment of your containers for free and supporting auditable and revertible deployment histories?

I'd like to hear what you consider to be operational best practices!

I think teaching devs to use k8s is generally a good thing. The patterns in k8s are very well established and a developer can learn a lot by understanding how to implement them. For basic web apps on something like GCE the time needed to get operational should be minimal.

Well-said @rossdavich... also says a lot about tech company cultures: most people are just looking for the next job. Is there anyone actually interested in creating and contributing to building great products, ones that people actually need? #rhetorical

Developers learn quickly that the only way to get a decent salary and/or job security is to cram as many buzzwords into their resume. Companies don't like to invest in training, so the only other way to get those buzzwords is to force the use of whatever cool tech into a project, whether it's appropriate or not.

And no, experience in cool buzzword tech does not count if it's a side project or open source contribution - as much as we would wish that to be the case.

We can blame developers, but they are just adapting, as humans always do, to their environment. Sometimes it is just bored devs chasing the next fad, but there is plenty of blame to be laid at the feet of modern tech companies.

For those companies i recommend rancher... It's kubernetes under the hood but a lot is stuff is abstracted away..

So docker runs a bunch of system services but abstracts them away... And kubernetes runs docker but abstracts that away... and rancher runs kubernetes but abstracts that away..

Should I just wait a year for something that lets me use rancher without knowing anything about it?

I worked at company with k8s+rancher, and was constantly bumping into rancher specific issues. I am not sure if rancher is really worth the effort.

I'm also a fan of Rancher. Especially the newer versions. It significantly simplifies the process of spawning up and managing a Kubernetes cluster.

I do think that Kubernetes is overkill if you just want to spawn a couple of server instances. But if you want to build a complex system which scales and you happen to have experienced developers on the team who understand how to build scalable systems and who have experience with Kubernetes then you'd be foolish not to use K8s IMO.

That said, having that specific talent and experience on the team is critical or else you're just wasting your time and money with K8s - And that talent is very hard to find. There is no point building some complex architecture for Kubernetes if that architecture is not designed to scale linearly from the ground up.

Kubernetes can allow you to operate highly scalable systems easily and elegantly, but simply using Kubernetes doesn't itself guarantee in any way that your systems will be scalable and will benefit from K8s at all (aside from pretty UI). Very few people can build systems that scale and also meet business requirements.

I call this "resume driven development"

You clearly understood one of the primary incentives that drives k8s adoption (career self-interest).

And then you issued advice like "Don't do this". I'm curious if you truly believe that anybody in the above class of people would change their ways on that basis, and without a greater incentive.

Doing a migration when you're not clear on what problem you're solving and why is always a bad idea. But I don't think this is a fair characterization of Kubernetes. There are lots of well supported hosted ways to use it, in which case it works a lot like other PAAS tools like Heroku or Elastic Beanstalk, except with much more powerful and better designed primitives and a big open source community of tools to make working with it even easier.

It's not like using a tractor trailer to get your groceries, it's more like using a swiss army knife to cut a piece of string. Sure you don't need all the extra accessories for that task, but they're not really getting in your way, it's still a good tool for the job. And the extras might even come in handy at some point in the future.

I am a solo developer (full stack, but primarily frontend), and Kubernetes has been a game changer for me. I could never run a scalable service on the cloud without Kubernetes. The alternative to Kubernetes is learning proprietary technologies like "Elastic Beanstalk" and "Azure App Service" and so on. No thank you. Kubernetes is very well designed, a pleasure to learn and a breeze to use. This article seems to be about setting up your own Kubernetes cluster. That may be hard; I don't know; I use Google Kubernetes Engine.

For others considering Kubernetes: go for it. Sometimes you learn a technology because your job requires it, sometimes you learn a technology because it is so well designed and awesome. Kubernetes was the latter for me, although it may also be the former for many people.

The first step is to learn Docker. Docker is useful in and of itself, whether you use Kubernetes or not. Once you learn Docker you can take advantage of things like deploying an app as a Docker image to Azure, on-demand Azure Container Instances and so on. Once you know Docker you will realize that all other ways of deploying applications are outmoded.

Once you know Docker it is but a small step to learn Kubernetes. If you have microservices then you need a way for services to discover each other. Kubernetes lets you use DNS to find other services. Learn about Kubernetes' Pods (one or more Containers that must reside on the same machine to work), ReplicaSets (run multiple copies of a Pod), Services (exposes a microservice internally using DNS), Deployments (lets you reliably roll out new software versions without downtime, and restarts pods if they die) and Ingress (HTTP load balancing). You may also need to learn PersistentVolumes and StatefulSets.

The awesome parts of Kubernetes include the kubectl exec command which lets you log into any container without almost any setup or password, kubectl logs to view stdout from your process, kubectl cp to copy files in and out, kubectl port-forward to make remote services appear to be running on your dev box, and so on.

> Once you know Docker you will realize that all other ways of deploying applications are outmoded.

This is a strong and absolute statement to be making in a field as broad and diverse as software engineering. My experience from being on both sides of these statements it that they're often wrong, or at least short sighted.

In this case, while I get the packaging benefits of Docker, there are other ways to package applications that don't require as much extra software/virtualization/training. So the the question isn't as much about whether Docker/K8S/etc. provides useful benefits as whether or not those benefits are worth the associated costs. Nothing is free, after all, and particularly for small to moderate sized systems, the answer is often that the costs are too high. (And with hardware as good as it is these days, small-to-moderate is an awful lot of capacity.)

I've personally gotten a lot of value out of packaging things up into an uber jar, setting up a standard install process/script, and then using the usual unix tooling (and init.d) to manage and run the thing. I guess that sounds super old fashioned, but the approach has been around a long time, is widely understood, and known to work in many, many, many worthwhile circumstances.

Indeed. Containers suck when your entire filesystem is 60 megabytes.

When something breaks you log in to the machine and make incremental updates to fix it, right? This approach leads to non-reproducible deployment environments. Immutable systems are better, and Dockerfile is essentially a written record of how to reproduce the environment.

Everybody feels confident in the stack they have spent time using.. You like Kubernetes because you took the time to learn it, someone else will find Elastic Beanstalk or AWS ECS equally easy to setup and scale. It's not that Docker is the only way to deploy an application either, there are virtues of learning the serverless deployment modes as well on the various clouds. For many of the "proprietary lock-ins" you run into, you often get something back.

I do agree in point that kubernetes and Docker are nice of course :)

Another advantage of Kubernetes over things like Elastic Beanstalk is portability. Your app can move from one cloud to another with minimal effort.

Yet another advantage is portability and durability of your knowledge. Kubernetes has so much momentum, so it is here to stay. It is extensible so third parties can innovate without leaving Kubernetes, which is yet another reason it is going to be around for a long time.

EB or ECS specific knowledge is AWS specific. I can (and do) run k8s on my laptop and can (and do) deploy Helm charts (the ones I wrote or 3rd party ones) on any k8s install. So that's quite different to the usual vendor lock in that comes with proprietary cloud services.

...or you could deploy your app on Google App Engine or Heroku and spend all your time developing features your customers care about.

I have no idea how to deploy my app on Google App Engine or Heroku. So instead of spending time developing features my customers care about, I'll spend time learning how to deploy my app on those services.

I'm skeptical to believe the service is any more scalable than it would be with regular instances and multi az. mainly because in my experience scalability has way more to do with network topology and the architecture of how requests flow, rather than the tech for implementation.

> I could never run a scalable service on the cloud without Kubernetes

Can you give us an indication of the scale of your app? e.g rpm.

It is still in development, so no rpm at the moment.

That’s another thing: some people think Kubernetes is something you use if you need high scalability. I disagree. Kubernetes should be the default if your app consists of more than 1 service. If you don’t have high scalability requirements you can rent a single-node GKE “cluster” for about $60 per month.

If you have just 1 service then a single Docker container is all you need, so Kubernetes not needed.

This is my experience too. I've used smaller-scale tools (such as docker-compose, Dokku, Heroku etc) but I've found them to be a mixture of unreliable or unsuitable in the case of fairly modest complexity.

Eventually I turned to Kuberenetes to see how it compared. I spent a day-ish reading through the 'core concepts' in the docs which was plenty enough to get me started on GKE. It took me a week or two to migrate our workloads over, and once everything stabilised it has been pretty much fire-and-forget.

I have about twenty pieces of software deployed for my current client and I feel that I can trust Kuberenetes to just get on with making everything run.

I've since deployed clusters manually (i.e. bare metal), but I certainly wouldn't recommend it for anyone starting-out. Personally I'm keeping a close eye on k3s.

I think my main learning during this process – at least for my situation – was to run any critical stateful services outside of Kubernetes (Postgres, message queues, etc). I think this applies less now than it did when I started out (v1.4), but non-the-less it is a choice that is still serving me well.

"I could never run a scalable service on the cloud without Kubernetes."

But also

"The alternative to Kubernetes is learning proprietary technologies like "Elastic Beanstalk" and "Azure App Service" and so on. No thank you"

So can we clarify that you truly meant: "I decided not to run a scalable service in the cloud using any of the existing cloud tools that do and have supported that scenario for years. And decided to use k8s instead" :)

> I could never run a scalable service on the cloud without Kubernetes.

I find this statement quite bizarre.

Not bizarre at all - it's perfectly fine - this poster could never run a service without kubernetes.

Doesn't make any kind of judgement, just stating their personal fact.

I could never make a souffle without a recipe. Do you find this statement bizarre as well?

I’m in a similar situation and kubernetes is honestly pretty easy to use one you get. If your team is small use a managed kubernetes Like GKE of EKS

It’s worth noting that kubernetes uses containers which can be created via docket but is not dependent on docker

Can you point me to a good doc on deploying a small production service on k8s?

The official documentation provides a super simple tutorial, and then nothing. There's not even documentation of the primary config file. Frustrating.

https://github.com/kubernetes/website/issues/19139

    If you have microservices then you need
    a way for services to discover each other

Why not run them in docker containers with fixed IPs?

What happens when the IP address changes? You need some way to lookup current IP addresses. Why re-invent DNS? Also, how do you protect these services from unauthorized access?

Because you want to scale, or roll out during a deploy. Or one goes down and you need a new host.

Do you have any resources you'd recommend to learn Docker?

So much this.

I'm also enjoying Kubernetes. I started a hobby project on GKE just to learn, but now the project has 8,000 MAU or so and will be scaling up more in the near future. K8s is totally overkill, but I've had a good time and it's worked well so far.

I run a Saas business solo, for eight years now, netting six figures, and I've been on Heroku the entire time for just under $1,000 a month. Monolithic rails app on a single database, 300 tables.

Sometimes I feel teased by 'moving to EC2' or another hot topic to save a few bucks, but the reality is I've spent at most 2 hours a month doing `heroku pg:upgrade` for maintenance once a year, and `git push production master` for deploys and I'd like to keep it that way. I just hope Heroku doesn't get complacent as they are showing signs of aging. They need a dyno refresh, http/2, and wildcard SSL out of the box. I honestly have no idea what the equivalent EC2/RDS costs are and I'm not sure I want to know.

You should look into render.com which provides a service similar to Heroku. I haven't used them myself and have no connection with them. Their name does pop up a fair bit though.

Congrats on the business taking off! What is it?

Based on jblake's profile it seems to be guestmanager.com, but I might be wrong.

(Also, for everyone who doesn't know:

- clicking on a username takes you to that users profile

- clicking on the n minutes/hours/days ago take you to a permalink directly to that comment

)

Software engineering is the perfect example of the "blind scientists and the elephant" problem. It is a very complex field, with a number of related but distinct disciplines and activities required to make it work; it's impossible to be an expert in everything, so we tend to specialise: we have back-end engineers, front-end engineers, data engineers, SRE experts, devops specialists, database experts, data scientists and so on. Additionally, the software we are building varies wildly in terms of complexity, dependencies, external requirements etc; and finally, the scale of that software and the teams building it can vary from one person to literally thousands.

Articles like this one, and even more comments on HN and similar sites, generally suffer from a perspective bias, with people overestimating the frequency of their own particular circumstances and declaring something outside of their needs as "niche" and generally misguided and "overhyped".

The reality is that various technologies and patterns -- microservices, monoliths, Kubernetes, Heroku, AWS, whatever -- are tools that enable us to solve certain problems in software development. And different teams have different problems and need different solutions, and each needs to carefully weigh their options and adopt the solutions that work the best for them. Yes, choosing the wrong solutions can be expensive and might take a long time to fix, but that can happen to everyone and actually shows how important it is to understand what is actually needed. And it's completely pointless to berate someone for their choices unless you have a very detailed insight into their particular needs.

> Articles like this one, and even more comments on HN and similar sites, generally suffer from a perspective bias, with people overestimating the frequency of their own particular circumstances and declaring something outside of their needs as "niche" and generally misguided and "overhyped".

It's my experience the opposite is true. The blindness is people overestimating their needs (or resume-padding) and using specialized, overcomplicated tools meant for traffic in the billions (e.g. cassandra, kafka, mapreduce) for 20-person startups that haven't hit rapid growth (most of which never do).

I'm afraid you might be falling into the exact trap I have described. Realistically, how many such cases have you seen? And of those you have, how many did actually implement such a complex solution and ran it for a long time without either closing down or transforming to something more suited to their needs?

I disagree with the HN consensus here: I think managed kubernetes is really useful for startups and small teams. I also commonly hear folks recommending that I use docker-compose or nomad or something: I don't want to manage a cluster, I want my cloud to do that.

We run a fairly simple monolith-y app inside kubernetes: no databases, no cache, no state: 2 deployments (db-based async jobs and webserver), an ingress (nginx), a load balancer, and several cron jobs. Every line of infrastructure is checked into our repo and code reviewed.

With k8s we get a lot for free: 0 downtime deployments, easy real time logging, easy integration with active-directory for RBAC, easy rollbacks.

Overengineering is a real problem out there. I’ve seen k8s deployed for internal back office apps that have literally 5 users - a raspberry pi could’ve hosted it. Keeping things simple and reliable is often a harder skill to learn than $BIGCO_TECH, and often confounded by political incentives.

So if you do that another internal enforcement group will come and be like "policy is that everything is cloud now, what's your migration plan?" regardless of anything else, and the only answer is to have a plan that keeps costs similar to the Raspberry Pi.

So, request budget to move the app to a cloud VM / container, and work out the security issues, etc. The latter will be expensive, but the RPi deferred the cost. Bean counters like deferred costs.

Then, ask finance to figure out the billing. It costs about $5 / month to rent a raspberry pi equivalent, but multitenancy might reduce that.

I'm getting tired of these "you don't need k8 posts". Sure, if you have a simple web application with a REST API, don't use k8, unless it's for learning purposes. But nobody does that anyway.

If you have something more complex with many moving parts that are separate services, k8 is a great option. I've been using it in production for close to 2 years now - not a single service downtime, great fault-tolerance, and absolutely zero management effort. Deploying complex applications, databases, and monitoring systems is easier than ever before. I don't think using k8 is overly complex. Yes, you need to invest some time to learn it, but that's the case for every new technology.

Practically every SaaS business could be built as a single application or a set of services, especially at the beginning when all the traffic could be handled on one server. So whether or not k8s is appropriate isn't driven by your business's complexity but rather by your architecture choices. Choosing to build microservices is what adds complexity and makes tools like k8s necessary, not the business.

That complexity can be useful. It can mean you don't need to build a simple version and a more scalable version later. It means you can replace parts as the business grows rather than the entire thing. You can outsource or buy some services. These are benefits, but they are also choices, and all of them increase the time it takes to get to market. In a very well funded startup that has years of runway sometimes choosing microservices makes sense.

In most small startups that are just proving their model they'd be much better off hacking something together that they'll throw away later in order to validate the business idea. Finding out that your business doesn't work as a business is far more useful than building something that can scale just in case it does.

The real difficulty in that is accepting that the idea you have might not actually work.

"But nobody does that anyway."

You'd be surprised, but they do.

EDIT. I work at company with < 5 devs and we are in progress of moving our services to k8s. Will se how it goes.

> But nobody does that anyway.

Please speak for yourself. In my experience, most of the software that's written using k8s/µServices could've been written using a simple Flask+Nginx+monitoring on a DO Droplet. K8s and the extra overhead leads to extra efforts in developement and testing, and many software teams are perennially behind schedule on delivering features.

There are ways to achieve fault tolerence without tying in to the complex ecosystem of K8s.

We have a possible counter-example: our service is computing AB-test results (essentially reading from a database, processing totals, writing significance back). It have no non-system users, no dependencies, etc. All the test and strangeness is handled internally.

We use k8s which is indeed over-engineered — it ran fine as a reminder and a local script for years. But the rest of the company has a release process that they like. We just integrate to it. Our service has a name in that space, ressources, a schedule that other engineers can read. Our description looks a little… film-school-credit-rolly because my name appears as the lead, architect, project, emergency contact, etc.

I think the main oversight of those “you don’t need k8s” is that most projects are part of a system and fitting in that system gives you legibility to your peers that a nginx might not.

I have ~62 apps (that's applications, not instances) deployed on kubernetes right now, for single client.

It started out on 2 VMs with I think 2-4 cpus, already running kubernetes. The actual containers inside ran lighttpd and served static files while we fixed up the sites that we have mirrored as static to run in containers.

If we had to run one, or maybe few of those sites, it would have been easy to run a single Apache + mod_php + vhost. We would have some annoying work to do on monitoring and logging side.

But we have 62. Some of them are mutually incompatible to run on "standard" distro, as they have mutually exclusive dependencies (for example, PHP versions). This meant we ended up with containers to manage this in somewhat doable way (we are two people). We can't expend manpower to do a complete redo of the apps, though we have ideas on that (to go to single common CMS system for all of them).

K8s saved our sanity. Because those "simple apps" altogether made for hard to manage setup, and the client doesn't like when they are not available, so we brought up HA as well.

Doing this as separate VMs would be hard and expensive. Doing it on Heroku is expensive - I made a calculation, and our original setup would result in somewhere around ~1800 USD a month.

Our 2016-2017 spend on GCP (GKE, Cloud SQL, a VM to host Gitlab + network traffic and DNS) was around 1000/month.

We used to manually ssh to deploy our dozens of nodes, just a handful on developers. git pull, restart service.

Then we got to hundreds of nodes. Chef, chef, and more chef. Deploys were typically run with a chef-client run via chef ssh (well, a wrapper around that for retries). With dozens of services and many dozens of engineers, this worked well enough.

Then we got to thousands of nodes. And hundreds of developers working on a multitude of services.

We've adopted k8s. It has been a lot of work, but the deploy story is wonderful. We make a PR and between BuildKite and ArgoCD we can manage canary nodes, full roll outs, roll backs, etc. We can make config changes or code changes easily, monitor the roll out easily, and revert anytime. I still don't _like_ k8s mind you - I don't think programming with templates and yaml is a good thing. But I've come to terms with that being the best we will have for now.

We deploy small clusters everywhere in the same pattern, I love argocd. This article fails to understand the use case for kubernetes, and arguably doesn't fully understand the cloud.

Kubernetes is revolutionary, to think it's not is foolish.

> Then we got to hundreds of nodes.

Until you get there, Kubernetes is most likely overkill.

Kubernetes solves very real problems in a way that handles a full suite of them.

This is very complex because the problem set is complex.

If you're running a substantially smaller system, k8s makes less sense.

That said, if you're familiar with running and monitoring k8s, a gke deploy will solve a lot of the pain a traditional LB + EC2 ASG will incur out of the gate. Let me explain:

Notionally, we need 4 basic services operationally for a single typical service deployment. 1 of FooService, 1 load balancer, 1 database, 1 monitoring/logging system. All of these should tolerate node death; this means roughly 3 pieces of hardware for this notional system. This is complexity that k8s covers, at a high cost of knowledge. If you're bought into AWS, the Beanstalk system will do this decently well, last I checked.

I think there is room for a k8s-like tool that is good for teams with < 10 services, and less than 10 engineers. Even k3s (https://rancher.com/docs/k3s/latest/en/) has substantial complexity at the networking layer that, I think, can be stripped for the "Small Team".

So I agree with the author in theory that k8s is overkill. But also other infra types can start getting difficult to deal with in time, and "just deploy onto a single big box" doesn't cover the operational needs.

Would AWS Elastic Beanstalk fit that <10 services profile?

yes, it would.

Costs start really getting heavy with EB at a certain point, since you're spinning up 1+ ASG & LB per service (a tier is an ASG and a LB, possibly a DB). I wouldn't build a microservice architecture against EB, at _all_.

I'd say EB probably is cost effective up to, IDK, maybe 3 services with 3 nodes per ASG. Then you're breaking even or worse with k8s ops cost, and now you're looking at "how much time (= money) is it to manage k8s with KOPS" vs "how much are we spending on EB". KOPS is a very low-effort solution once you get it rolling.

Probably unpopular, but I am generally opposed to using Docker/Kubernetes for ~75%+ of projects. I've been in arguments over this, but containers being unmaintained and the complexity of Kubernetes can cause major issues. It's over engineering for smaller projects. That's just my opinion. I think a flat VM is more appropriate most of the time. But there is no denying the advantages of Docker when it's done right and used right.

A developer told me just a few weeks ago that you should "always" use Docker, which I just found to be so ridiculous.

So I wasn't really on the Docker train for a good while, but using containers takes so many sysadmin and environment issues out of play that I've started to change my mind. The position I find myself in is actually that for development environments Docker Compose and similar tools are wildly convenient, but that there's often not a really obvious path from that to production at small scale low cost.

that’s not unpopular at all. everyone that has had to run k8s and keep it uptodate or deal with unmaintained docker containers understands this 100%

People who have issues with unmaintained docker containers are doing it wrong. You still need to assess the quality of your dependencies for container images just like you should be doing for any other dependency.

The issue is that docker lets some developers get in over their head very easily. Many orgs have system admins to install and configure server operating systems, but docker shifts some of those responsibilities back on to the developer.

It's not that hard to use Kubernetes and it makes the developer's life easy. It's very easy to deploy helm charts and even though that there are many gotchas and complex things, if you want to deploy something simple, it is easy and completely doable to do it even solo.

(rant)

After over 10 years in development I've done and used literally all the things people complain here a lot about: Virtual machines, Single page apps, docker, microservices, FP and the list goes on. Even though I've struggled, I feel very lucky to be able to try all those things and it's a joy to use and I've shipped shitloads of great code that is making a lot of money to a lot of people and improving businesses in general.

I don't mean you need to use K8S or even like it, but there is definitely developers which know their shit very well, and can also make great Single page apps using more than 3 different JS framework, also write good backend code and so on. And also enjoy all of this and make companies definitely successful. It sickens me a bit how so much posts of this kind get a lot of attention and could be replaced by "yes, software, like everything in life, is complex!!!11". I think the article itself is completely shallow to actually touch the difficulties there is with using kubernetes and is mostly useless information. There are at least 10 posts with a better and more structure criticism, but it's just because it's cool to complain about new things, it gets automatically traction in HN(which used to be a place where people like new things...).

So... yes, you shouldn't use K8S everywhere(also applies to everything...), but it is the new thing(well, not really new...). Should we just talk about Apache mod_php? It's natural that people want to try new stuff and actually enjoy working with software. Not everybody sees everything as problems. "Now you have eight problems, hehehehehe!!11".

Am I the only one that found this post completely useless and at some degree, toxic?

(/rant)

Well good for you that your SPAs work every time, and you never broke production with kubernetes. Here's a cookie.

Now for the rest of us who work with engineers across all skill ranges and experience levels, we actually do need to care about such factors.

The question is -- you hire a guy off craigslist to run your site, and every minute of downtime costs $1,000. Are you going to want him to use Kubernetes or a braindead simple hosted solution?

Some people are tired of acceleration and fear the industry moves too fast for them and some people are tired of the people who would like to take a step back because they feel like they're being held back. Both feelings are valid and it's good to have the full spectrum represented.

Having an industry veteran like Itamar weigh on a pointless complexity that everyone seems to be in love with right now? Extremely valuable. Possibly saves peoples' lives, financially speaking.

Old IT folks are like explosives experts: if you see them fleeing in panic, follow them!

I see the author is a proponent of docker-compose, which I use myself for small projects. I have a docker-compose configuration in all my repos, and a `docker-compose up` brings the app up on my laptop. I could use minikube in almost exactly the same way. i.e. there is effectively no difference from a development perspective.

If you are managing kubernetes yourself, on your own hardware, the moving parts can indeed be a burden for a small team - but all of these pain points go away with a managed kubernetes, as offered by most IaaS providers. i.e. if you are using an IaaS provider, there is (usually) no difference from a production perspective.

There are less moving parts in docker compose, and its easier to run on a single VM - but it doesnt offer any of the dynamic features of kubernetes that you would want at scale. The same containers can run on both.

If you need to dynamically scale your application, or grow beyond a single machine (I disagree with the vertical scaling proposed by the author - thats for a very specific use-case IMHO), then docker-compose is simply no good. Then you need to use docker-swarm. At this point, you either need to manage a docker-swarm cluster or a kubernetes one. Kubernetes is the obvious choice here. Fortunately, there is a trivial migration path from docker-compose to kubernetes.

> there is a trivial migration path from docker-compose to kubernetes

The migration path of docker-compose to swarm is basically:

eval $(docker-machine env my_cluster) docker deploy --compose-file docker-compose.yml PROJECT_NAME

I have looked into k8s and it wasn't as easy as this.

Also docker-compose doesn't have zero downtime deploys which might be a deal breaker depending on your application.

Or Nomad or Mesos!

There’s a lot of configuration to understand with k8s and even GKE. Badly configured probes, resource budgets, pod disruption budgets, node affinities etc. can have disastrous effects. I’m pushing my teams more towards serverless since it takes out nearly all ops/scaling/rollout complexities. Right now we’re seeing our serverless apps on GCF, GAE and cloud run outperform our GKE apps easily in scaling, reliability, and simplicity (configuration and time spent getting it deployed in a satisfactory manner)

This is the lesson my last company learned hard. For anything serving less than tens of thousands of requests a second, you just can't really beat GAE in terms of simplicity and cost.

Im planning to use GAE in a production environment.

Can you share the specifics on how GAE managed to scale please ?

It’s interesting that this critique of kubernetes is on a blog called “python speed” because my most recent project with kubernetes was deploying a large dask cluster. For this use case k8s was really valuable. It made the devops part so much easier than it otherwise would have been, so we could put most of our time into application logic. In other words, when we wanted to achieve substantial “python speed” kubernetes was very helpful. For data engineering projects, even with a small number of data engineers, it can be a big productivity booster.

Personally, I like kubernetes and find it easier to use than other devops tool sets, so it’s become my go-to tool. Probably wouldn’t recommend it to someone who doesn’t know it and has a simple app architecture.

I've taken over a project containing 6 DB entities. Instead of building a monolith (or normal REST API), the Architects used 7 µServices based on k8s and NoSQL DB. Now simple development tasks take extra time, and anything that affects multiple µServices needs n times the development efforts. I wish they had started with a simple monolith, and refactored to µServices if needed.

Your problem, my friend, is not Kubernetes or anything else technological. It is the people around you that call themselves architects :-)

True that, I must add that k8s added to the delay for features and enhancements.

Like most enterprise projects, by the time I got my hands on this project, all the Architecture Astronauts had already moved to their next planet :-)

I’m a very happy user of Rancher 1.6 for years. Simple, nice GUI, got everything I need, works fast, can deploy as many apps /services as you wish, no new concepts to learn (if you know Docker that is).

Used it in my previous agency to manage clients websites and use it now in my startup to manage multiple envs with few apps (api, front end, workers) and nice and easy deployments via GitLab CI.

Heh, it’s quite amusing to see the posts here arguing that “you can do the same thing with multi az deployments on aws with VMs, packer and ebs. Kubernetes needs you to learn so much shit” ... do you even read what you write?

Kubernetes is not gospel. It’s an opinionated, incomplete framework for orchestrating container workloads. There are other ways to do the same thing which are fine too. It works well for the most part but has disgusting failure scenarios. So do other techs.

People who use and like kubernetes are comfortable with its trade offs and portability. You may not be. It’s fine.

Shitting on kubernetes just because you’re comfortable with another technology just because you can: that’s not fine.

> The more you buy in to Kubernetes, the harder it is to do normal development

This demonstrates the bias and perspective of the author. The best way I can describe it is code-centric rather than system centric. If that's "normal" then the article makes some very valid points. For example, I've seen quite a few folks make the attempt to scale out badly when they could've scaled up rather easily. Very many "bigdata" problems can be handled on a single machine with a terabyte of memory.

If one shares that code-centric perspective, then yeah, k8s probably isn't for you. The real benefit in overcoming the very validly criticized complexity of k8s is the number of things that happen without intervention.

From a systems-level perspective, all these things are crucial. Services are abstracted with endpoints by default. Liveness and readiness are built in. Self-healing is built in. A consistent model by which apps are deployed is built in. Logging, metrics, and SLA monitoring while not built in can all be added and employed without intervention.

Ideally, these things abstract the infrastructure sufficiently well that it allows developers to focus on development, rather than ancillary tasks like deployment, monitoring, resilience, etc.

k8s is raw technology like linux kernel. You shouldn't use it directly which will be hard to maintain. There are bunch of packaged solutions around k8s like Google GKE or AWS EKS. By leverage them, you'll be working on a higher level of abstraction and bring productivity back.

What's the best package for running in-house?

Rancher labs have a wide offering that has worked well for me. I’m currently running a couple K3S clusters on an array of Rock64 sbcs and have used the „real“ rancher distro for a while too with no problems. But I’m hardly an expert regarding the k8s on prem market so there might be even better ones!

Not sure about your use case but you could have a look at Minikube:

https://kubernetes.io/docs/setup/learning-environment/miniku...

I’m only on the start of my k8s journey but I’m finding typhoon a nice option for on prem currently.

OpenShift is pretty neat!

it seems too me like kubernetes aims to replace the existing service-mesh consisting of de facto microservices (load-balancers, remote-logging, systemd, xinetd, ...) bonded by unixy conventions with.... a monolithic, proprietary system. Proponents are then advocating to build decoupled microservices on top of this. Am I the only one who thinks this is shizophrenic?

(on the other hand: companies claiming to make the world a better place by selling ads to the highest bidder are shizophrenic...)

I’m positively attuned to the ... de facto Microservices bonded by unixy conventions ... part. And it has worked well in the past. You had much more freedom but everyone needed to pretty much roll their own.

Kubernetes is a compromise on that. You don’t need to build you ops framework from scratch now and deploying something has very well defined APIs. OTOH you now are in a world of finding which k8s extensions/plugins/whatever you should use and which are just “fancy”. And answer questions like Is Knative V0.8 good enough for our workloads? Because Ai Defi needs that for some reason...

EDIT: Kubernetes is open source though right?

yeah it is open source, but half a million loc for a simple admin tool seems like the perfect path to vendor lockin ;)

This is exactly what lock-in looks like.

I'm curious what HN would recommend as alternatives, especially for small/early teams that are outgrowing single-machine setups.

It seems to me that there's something of a gap between "for single machine setups" (eg docker-compose) and "for 500-engineer teams" (eg kubernetes).

I would recommend two machines and a loadbalancer. Most often the thing that doesn't scale isn't the applications you're able to run in Kubernetes, at least not at first. Most customers I've dealt with who have scaling issue need take a look at their database before Kubernetes.

Kubernetes is awesome of many reasons, but it's a big step from a single server setup to full Kubernetes and there are plenty of options in between. We're able to scale large national infrastructure projects using VMs and loadbalancers, but we also deploy run stuff on Kubernetes. The thing is: when stuff breaks, you'll prefer that it's not the Kubernetes stuff.

If you run the infrastructure your self, you should be VERY sure that you know how it works, because debugging it is extremely complex.

Full-disclosure: I co-founded a company that's building a developer tool for K8s (and distributed systems in general).

But we've had a lot of success with running on GKE. The tool that we're making takes away the complexity of building, testing and deploying the stack, and GKE takes care of running it.

In fact we use GKE for both our development and staging/prod environments.

There are a lot of great tools out there that vastly improve the K8s developer experience[1] and the cloud providers take away of the pain of operating it. And with tools like Terraform and Pulumi you can codify the whole setup.

Here's an example of how you can quite easily get started on GKE: https://medium.com/garden-io/gke-and-cloud-sql-a-complete-wo...

Here's a video of the same workflow: https://www.youtube.com/watch?v=iHyeD97GrE4.

[1]

https://github.com/GoogleContainerTools/skaffold

https://github.com/garden-io/garden

https://github.com/windmilleng/tilt

Often you don't need docker-compose either as long as you aren't deploying things that have weird dependencies.

Single monolithic application? Can run on a VM.

Multiple smaller applications written in Java, C# or Go? Can probably run side by side on a VM.

Fwiw docker compose is great for running stuff side by side on a VM :-)

I work in a small team, we just install and configure everything without Docker, Kubernetes or anything else. Just install it like I would with any other software and then run it after configuration. When it's time to deploy we have a bash script that bundles the app and pushes it onto the server.

Almost too simple to work, but it does ;)

ECS works great and ties into IAM/VPC/etc.

Also you're not paying $80 per control plane, they're free.

I’ve been using Rancher for years. Version 2 is all about K8s, but version 1 is super simple to set up and manage with a nice and clean GUI and pretty much no new concepts.

Unfortunately version 1 is abandoned now (I think) but it’s stable and I haven’t had any problems with it. Give it a go.

Docker swarm?

Does anyone actually use it in anger though? I've not followed it well, but it seems to me like it's Docker Inc's failed attempt to compete with K8s, which doesn't bode well for its future.

K8s is complex. For this reason Cloud providers sell it as a service. K8s and microservices are a trend topic, so it is true you must think with your own head before creating microservices at will.

But I think the article is a bit too negative.

For instance, in my humble experience the application server is always a bottleneck before the database (i.e. if the database is Oracle or PostgreSQL).

Microservices move a bit of complexity on the client side, ask for smarter clients and offer a lot more resilience and fault tolerance.

The article focus only on scaling and forget the "Single Point of Failure" problem.

It's sold as a service because it drives compute. Compute is one of the top money makers. The more people who buy into things like k8 that are essentially VM deployment launchers the better. The providers aren't emotional about this like 90% of the posters here. If a new flavor of the week gets people to launch VMs next year then that will be sold.

> you can use docker-autoheal or something similar to automatically restart those processes

I consider it sloppy to accept that a process will crash and become unresponsive as a normal fact of life, and that subsequently they have to be automatically restarted. A process should stay put at what it was designed to do. Reasons for the crash/unresponsiveness should be investigated (memory leaks, race conditions etc) and not swept under a carpet with an automatic restart.

Restarts should go into your reporting too.

Erlang seems to take the opposite approach. Processes are cheap, when one wears out you dispose of it instead of trying to fix it.

It would be unfair to simply mention about a technology's "problems" without mentioning even a single point of "features".

IMO, Itamar Turner-Trauring has misrepresented Kubernetes.

The sole reason of Kubernetes being popular and uprising is because there are genuine pros and features that make many people's lives easier instead of more miserable.

So let me point out the pros here:

[1]: https://www.infoworld.com/article/3173266/4-reasons-you-shou...

[2]: https://hackernoon.com/why-and-when-you-should-use-kubernete...

[3]: https://opensource.com/article/19/6/reasons-kubernetes

[4]: https://www.weave.works/technologies/the-journey-to-kubernet...

I'll take kubernetes over the miriad of AWS services any day.

Kubernetes is de facto the cloud standard. If I have to know stuff about the cloud, I would like my knowledge to be transferable to the other cloud also. I understand that these clouds have to compete and so on, but why do I have to pay the price to learn their particular ways of naming things and private apis, and what not.

So of course devs like kubernetes.

We're being pushed to move to Kubernetes/EKS (or, ECS as a plan B) away from Elastic Beanstalk.

Elastic Beanstalk does the job but it's slow to deploy things, it's inflexible, and the Amazon AMIs that underly them are riddled with ancient packages that infuriate security scanning security people.

Are we making a mistake moving to Kubernetes instead of re-designing an infra-as-code using docker+terraform+ansible+a CI pipeline? We run a client-facing app but it doesn't have super low latency requirements, although it does need to be able to scale up to run jobs.

Something else. I have to be honest, the complaints here about "people are doing it for their CV," while true, need to be understood in the context of, it's extremely hard to move jobs without significant kubernetes and Docker experience.

Lol. I've been using k8 for 5+ years and am currently interviewing for more 'traditional' sys admin roles. The number of traditional problems I don't have by running even a small k8 cluster has become even more obvious as I go through the process. For every alternative you may suggest, I can point out dozens of problems you can run into that are solved with k8s. Just like any other operations tool, yes, it takes time and effort to learn...that's why sys admins exist. I always find these posts by non-sys admins humourous. Devs often have so little respect for the knowledge base required to maintain a stable, secure, scalable, and flexible system. It ain't nothing, no matter the tool you use.

> "You can get cloud VMs with up to 416 vCPUs and 8TiB RAM, a scale I can only truly express with profanity. It’ll be expensive, yes, but it will also be simple."

It's simple until you need to update. Good luck meeting any SLAs with your fleet of singletons.

We originally built OpenFaaS for Swarm, then moved to Kubernetes and support both now. The complexity of K8s is harrowing, but by and large works well, if you can keep up with the pace of change. Try running a controller you last modified 12 months ago on Kubernetes 1.17.

Now we've spent time looking into containerd and trying to provide microservices/faas on top of that instead - without the clustering (https://github.com/openfaas/faasd)

Something I do like about K8s is the ecosystem - in 5 minutes I can automate TLS with LetsEncrypt on a managed cluster.

Kube isn't for small businesses. It's for enterprises.

Most developers aren't running the clusters, they are 99% of the time managed by the cloud provider.

Why would I ever order VMs and manually run a kube cluster.

But as an operator needing to manage clusters and multiple teams, I spend my time coding automation.

I'm not saying kube is not simple, but it's a lot easier then managing application runtime on VMs.

Before kube I was managing 260+ VMs (hyperv was internal managed DCs central/east) for my products in-house app. I had to essentially build my own poor man's orchestration platform to manage applications and deploying.

I find the assumption of many companies that they NEED stuff like K8S because they are going to be so "webscale", frankly, pretty arrogant. Most systems out there can run on a 2010 laptop, if done right.

In my previous company we had 20 million daily active users and we ran that on 4x M4.large EC2 instances. 4 instances not because it had any significant load (probably ~10-15% sustained), but purely because of high-availability and the ability to do a rolling release update.

I use docker swarm (mode? I am not sure) in production and it works great.

I really like docker swarm for the on-prem stuff we have.

I'm coming from the serverless side of things where people always say that only a few companies on earth even need K8s, like cloud providers.

How do you rationalize using it in your company?

For example, a learning platform that allows to integrate code for frontend and backend into your lessons uses Docker containers for their product. They can't offer runtimes for every programming language running on the frontend and backend, so they allow the teachers to upload their own container. I'd say they are a good example of a company that could need k8s.

> there are wide variety of tools that will do just as well: from Docker Compose on a single machine, to Heroku and similar systems, to something like Snakemake for computational pipelines.

Even though it has the disadvantages of being vendor-dependent and not open source, I've found ECS to be a very nice solution. Conceptually, it's very similar to Kubernetes, with much of the plumbing that makes Kubernetes so complex baked into the AWS platform (much of which you're already using if you're on AWS)

I wouldn’t recommend ECS to anyone. It’s technically worse than k8s in every way and tied to a vendor.

For me the biggest issue is speed of deployments. In practice it’s hard to get deploys on ECS under 1 minute. With k8s, 5 seconds is easy.

+1 for ECS as well, I think it’s a good middle ground and much easier to use. Is getting better as well with spot instance termination detection in the ALB and more seem to be coming soon. If you are on AWS is worth considering rather than EKS or role your own K8s cluster.

EndpointSlice is a really bad cherry pick. I have written K8S controllers for 2+ years and only recently learned about it when I had to write an ingress controller. Funnily enough I also had to learn about externalTrafficPolicy because it turns out if you have a lot of pods and use an AWS ELB the traffic distribution can be terrible, so a daemonset with local-only routing to them and then round-robining to pods works wonders.

You need to know none of this if you're not even close to the level of scale we are.

Every time I feel secretly embarrassed for running my small projects on a simple cloud VPS VM, an article like this comes along and restores faith in my decision to not over-engineer things.

This has come up on HN before, and it's a great read - "You are not Google": https://news.ycombinator.com/item?id=19576092

You can get pretty far with docker and things like ECS / Fargate etc too.

What service would the HN folks recommend for someone who needs to run a few dozen different docker services that require persistent storage? It would be nice to just have a pool of compute resources tied to persistent storage and be able to spin up docker instances at will. K8's has been suggested as the correct solution but it sounds like a lot of overhead for services that require no scaling at all.

I feel that the pro-monolith / anti-microservice attitude has become something of a cargo cult (at least here on HN).

Cargo cults were island nations that saw cargo planes land. They didn’t understand why the planes landed, but they did want to trade with them. They built makeshift runways and put out boxes of cargo in the hope of attracting planes.

If anything, the 5 person startup with 20 microservices “because Google/Netflix” and “we want to scale” is the cargo cult in this debate.

Not saying one side’s wrong or right, just that cargo cult doesn’t seem to being used correctly here.

(I admit I’m skeptical of microservices, since they add so much complexity, and even Netflix suffers partial service outages on a regular basis...)

Most of the "You don't need kubernetes" posts should be "you don't need docker".

There is something amusingly ironic about a python blog complaining k8's being overly popular relative to how difficult it is to actually use. K8's is extremely complex sometimes, but at least it maintains some semblance of semantic logical consistency, unlike certain other tools.

Great tools make hard problems approachable. They also reduce impossible problems to hard ones.

But, it takes experience (having solved things with easy and hard ways) to prefer easy problems and easy solutions.

It's a good time to be a consultant where you get to solve the same problems using different approaches.

Its also more common now to add on 3rd party functionality like a service mesh, various serverless implementations, secrets management, logging frameworks, etc. Making it even more complex. Not disputing some of these add value, but the number of moving parts is high.

How about this rule of thumb when it comes to the question of "Should you Kube"

How many developers in your organization?

0-10: No

10-100: Maybe

100-1000: Yes

1000+: Definitely

You are the man. Preach on.

I wonder how many teams with active users in the 1000s have fully dockerized/Kubernetes/microservice type shit designed for 10000x load that they will likely never get to because they didn't spend their time iterating on product.

I think the network part of Kubernetes is hard todo right and it’s very complex.

Further more I ponder on the performance if you compare a local monolith service on metal with full local cpu cache vs a distributed network requests Microservices.

Disclosure I run Kubernetes in Production.

It's IMO much easier if you don't run complex CNIs, but unfortunately not everyone can afford that :(

We use k8s at $JOB so I decided to look into it on my own time. A wasted weekend trying to install it and a profanity laden #ragequit later I moved all my stuff over to OpenBSD instead.

Never been happier.

In the case of k8s: ignorance truly is bliss. Keep it simple people.

So if Kubernetes makes management simpler and more robust for teams of 500+, but is overly complex for teams of 5, what solution would people recommend for teams of 5?

Docker compose and a bunch of shell scripts?

Yeah always seemed like madness to me. Docker compose seems to be the sweet spot. Still sorta infrastructure as code via yaml without the fleet/swarm logic overkill

There is something amusingly ironic about a python blog complaining k8's being overly popular relative to how difficult it is to actually use. To be fair, I've had nothing but mediocre experiences with Python, so I'm a bit jaded.

On the actual content of the article....well it gets worse somehow. There are good arguments against using K8's (or any tool, really) but I don't think any of them made it into this article. "Why scale with microservices when you can just get a single massive VM" was probably my fav.

If your solution comprises only of one or few systems, and primary reason for which you are considering k8s is just to tackle clustering/scalability/ service discovery then you can always just try to start by building simple clustering into your system.

Here is how I built it into mine: https://www.titanoboa.io/cluster.html

Obviously this will not always be the right solution, but in some cases might be better fit than k8s...

Kubernetes local environment setup

Kubernetes debugging

Too many configurations to worry about

Ever evolving features

No good practices

All these apply for small teams who wanted to get the products out to the market

For our team with many containers scattered around ElasticBeanstalk and ECS, K8S makes everything much cleaner.

Flash News! Software engineering is hard.

So, Kubernetes is the 2020 version of the enterprise application server of the '00s ?

they say kube is greek for 'pilot' but it also means 'dice'

are you feeling lucky punk?

Because Greek y and u are the same, "cyber" is from the same word as "kube". "Cybernetics" was supposed to be the art of piloting, but it was very loosely defined and the term was deliberately overhyped.

the proper way to use kubernetes is:

- if your org is big enough: hire/train your devops engineers to manage the kubernetes cluster(s)

- if your org is small or waaay too big: use some form of managed kubernetes cluster (aws, gke, do-k8s etc)

- don't

I will in the future on my CV also have a "Will Not Work With Skillz-Matrix" Kubernetes goes on first... Unless I'm applying to Google or something of similar size.

A lot of the problem with using Kubernetes is it appears to be the only option for running microservices in a cloud environment. People choose it because they think there's no other option (and they're somewhat right). But there's Nomad, DC/OS, Docker Swarm (for a little bit anyway), ECS, GKE, etc. That's still not a ton of options, but there are options.

That's just microservice orchestration. That's a small part of the totality of things needed to implement a full-out SDLC. You can't just build Kubernetes and think you're done; your code will need to integrate into a lot more stuff, and you'll end up writing 10 layers of glue because that's just how many use cases you have to support.

And it's weird that all that glue doesn't use standards. I mean, we have TCP/IP & RPC & REST, we have pipes & filehandles, we have the OCI specs. That gets us to a point where (at most) half of the stack of an architecture is portable and interoperable with any system following those standards. But then there's every other component of the architecture that connects all the pieces together, meaning you're writing glue that will only work for one implementation. Change your implementation, and you have to change your glue, and probably more stuff.

I think a lot of that non-reusable glue could be erased if it all followed standards, such that the configuration and operation of each part followed a standard interface, set of data types, etc. Tools and libraries could just "talk container orchestrator" or "talk load balancer" or "talk object storage" or "talk secrets management", and virtually any component could be integrated into any other, by virtue of either a system-wide or application-specific configuration.

You could argue we have something like that now with a "kubectl file" or similar, but that's not only still platform-specific, but other tools don't speak it, so K8s has to do everything, because it's the only thing that speaks its language (config file/backend data store/IAM/secrets/roles/etc).

Rather than resign ourselves to those limitations, we could bundle everything in an implementation-agnostic standard way with standard interfaces. The exact same configuration (as code) could be used to run the same complete architecture on a dozen different platforms, because every component would speak the same language and handle all the other components in the same ways. The backend services could all translate the standard based on how they were configured, such that generic instructions are then translated into implementation-specific actions. You could really write your architecture once and run it anywhere, without the caveat of "anywhere on this platform only".

I feel like we're not talking about doing that because we keep getting caught up in "Fuck, Kubernetes is pretty hard" conversations. Yeah, it's hard; building and operating an 18-wheeler is hard. But what about the roads? What about the gas stations? What about the containers we put on the trucks? All that stuff is standard, and so we don't have to worry about what implementation of gas station or road we use. I feel like we still don't have those things in the cloud, and it's just weird.

Then dont use it. Like wtf.

Once you configure the kubernetes network layer with whatever hosting platform you’re using, it’s really not difficult to administrate. It’s funny to me how much kubernetes hate there is on hn.

Until need to debug an issue and you're way over your head due to all the moving pieces.

Then assign someone to debug it who understands that kubernetes is a wrapper of common linux functionality.

It’s not that hard to debug issues in kubernetes. Check status of pods, memory levels, storage mounts, network configurations, and the stacktrace you’re debugging. Not that difficult.

I’m not saying there aren’t edge cases, but if you set up your system with centralized logging (filebeat) and have some way to scrape metrics (jmx, built in tooling) you’ll be fine.

For my personal projects, k8s is so useful that I wouldn't ever build a server by hand again. I can spin up my blog or whatever easily on one cluster, and if it becomes too expensive I can just move elsewhere, or if I want to reduce my costs, I could just run a single-node-cluster (I don't need HA) on a DO droplet or something and still get the ease of being able to destroy and rebuild my apps anytime I want to. It might be "overkill", but so are most of the tools I use each day. Of course, I never create my own clusters, but it isn't that hard to follow a tutorial if I had to.

Reply on news.ycombinator.com