Some day I would like a powwow with all you hackers about whether 99% of apps need more than a $5 droplet from Digital Ocean, set up the old-fashioned way, LAMP --- though feel free to switch out the letters: BSD instead of Linux, Nginx instead of Apache, PostgreSQL instead of MySQL, Ruby or Python instead of PHP.

I manage dozens of apps for thousands of users. The apps are all on one server, its load average around 0.1. I know, it isn't web-scale. Okay, how about Hacker News? It runs on one server. Moore's Law rendered most of our impressive workloads to a golf ball in a football field, years ago.

I understand these companies needing many, many servers: Google, Facebook, Uber, and medium companies like Basecamp. But to the rest I want to ask, what's the load average on the Kubernetes cluster for your Web 2.0 app? If it's high, is it because you are getting 100,000 requests per second, or is it the frameworks you cargo-culted in? What would the load average be if you just wrote a LAMP app?

EDIT: Okay, a floating IP and two servers.

Yeah, you probably don't. And not only that, but it probably makes your life harder. I've interviewed for a tech lead position at a company working with freelancers and I'm pretty sure the reason they ended up rejecting me was that I mentioned the technical interviewer that I think containers, container infrastructures (like Kubernetes) and even cloud infrastructure is being overused/used without giving too much thought about it as if it came free (in the sense of setup and operating complexity). Too bad the interviewer started rambling about how he was into Kubernetes those days :). (Actually, this was the most technical part of the interview.)

I'm mostly working with startups and small companies creating MVPs and that was their client base too. Now most of the time these are just building CRUD apps, most of the time these apps don't see heavy usage for years (maybe never). Developers love technology, love to play with new(ish) things so quite a few of us will prefer using whatever is new and hip for the next project. Now it's containers and microservices. And it feels safe, because done right, these will give you scalability. And once you convince the client/boss that you need it it's unlikely that anyone will come back in a year and say: hey, it seems that we'll never need this thing that made the development $X more expensive. (Partly because they won't know the amount.) So actually politically it is the safe choice. But professionally and cost wise it's usually worse. It's a lot better to have to transition after seeing the need (preferably from the projected growth numbers). At least you minimize the expected value of the costs (bacause YAGNI).

"Anyways, the point I am trying to make is you should use whatever is the easiest thing for your use case and not just what is popular on the internet. "

This is good advice in theory but in the real employment world you are killing your own career that way. At some point you get marked as "dinosaur" that hasn't "kept up". Much better to jump on the latest tech trend.

Most organizations don't need to manage servers or Ansible playbooks either.

The reason Kubernetes became so popular is because the API was largely application-centric, as opposed to server-centric. Instead of conflating the patching and configuration of ssh and kernels with the configuration of an application, you had clearly separate objects meant to solve different application needs.

The problem with Kubernetes is that to gain that API you need deploy and manage etcd. To bring your API objects to life you need the rest of the control plane, and to let your objects grow into your application you need worker nodes and a good grasp of networking.

This is a huge burden in order to gain access to K8's simple semantics.

GKE helps greatly, but the cluster semantics still come to the forefront whenever there's a problem, or upgrade, or deprecation, or credential rotation.

Of course there's always a time for worrying about those semantics. Specialized workloads might have some crazy requirements that nothing off the shelf will run. However I think the mass market is ready for a K8s implementation that just takes Deployments and Services, and hides the rest from you.

In lieu of that, people will just continue adoption of App Engine and other highly-managed platforms, because while you might not need Kubernetes, you almost certainly don't need to go back to Ansible.

I honestly don't understand the amount of negativity towards dockers and kubernetes sometimes.

All major cloud providers have a managed k8 service, so you don't have/need to learn much about the underlying system. You can spend a few days, at most, to learn about dockers, k8 configuration files and helm and you're pretty much set for simple workloads (and even helm might be overkill).

Afterwards, deploying, testing, reproducing things is, in my opinion, much better than managing your applications on random servers.

Might I be wasting some money on a k8 cluster? Maybe. Do I believe the benefits outweigh the money? Absolutely.

I am interested in people's opinion on the "break even point" between using Kubernetes and not using Kubernetes. Let's pretend that the only options are Kubernetes and something substantially less powerful.

What is the simplest/easiest personal project where using Kubernetes might be justified?

I am a junior software engineer trying to figure out how to contextualize all of these container/container management systems.

Maybe someone here can help me figure out what I need, since the world of containers is growing faster than I can understand.

I have one code base that I run on multiple servers/containers independently of each other. Think Wordpress style. I used to run it on Heroku but I switched to Dokku because it's substantially cheaper and I don't mind taking care of the infrastructure. I like Dokku but I do worry about being tied to just one server and not being able to horizontally scale or easily load balance between multiple servers/regions. Ideally what I'd like is Dokku with horizontal scaling built in. I've seen Deis and Flynn but they seem less active/mature even than Dokku, which is saying something.

Is Kubernetes the right answer here or should I stick with Dokku and forget about horizontal scaling?

You probably don't need microservices either - it's insane how much money and time is being thrown away to these industrial strength hammers by companies that simply don't need it.

Depends on the scale. If I only have 10 containers to manage I'd throw them on a m4 and let it be. Benefit of using k8s kicks in when your use case gets complicated.

Its a bit funny to ask this question in this thread, but here we go:

What are the important topics & technologies to learn about with these types of topics? My uni experience didn't really include things like distributed systems or containerization.

Ideally fundamentals that won't be invalidated in 5 years when 'the new thing' becomes something else.

(Love good book recommendations on any subject a new grad should learn, not just this topic)

Kubernetes may be overkill for small projects and it's actually hard to setup for a single-machine cluster, but the idea of container orchestrators (k8s, docker swarm, nomad, etc...) is extremely useful, I understand that some abuse the word "scale", but for me container orchestration is far bigger than just scaling, these features include:

1. rolling updates

2. decoupling configs and secrets from code and mounting/changing config files easily

3. robust and predictable testing/production environments

4. centralized logging

Also microservices's goal isn't really about just "scaling" in my opinion, there are other important advantages even if you have no intention to scale, aspects like modularity, separation of concerns, robustness and lowering the technical debt are still as important whether your app serves 1 or a 10000 users at the same time. Of course you can pull your python app from your repo or even rsync it (just like you can just develop any software without using git or any revision control) and just execute it might work very well, but sooner or later you are going to regret it if you're a business

It was interesting to note about workers and using web assembly together within V8 as this scenario could bypass the need for complexity and memory overhead, while combining different programming languages on the server-side. Not that it could replace Kubernetes as that is an amazing technology but if you are in a scenario where your tech could fit within workers, could be interesting. https://blog.cloudflare.com/introducing-cloudflare-workers/. I was amazed to think web assembly would be used for that purpose but i guess it does make sense in reading about how it is put together.

What bothers me about k8s is that it promises a lot ("15 years of experience of running production workloads at Google" at your fingertips! yay!) but it's in fact still a young, ever-changing solution.

Even developing an app locally with minikube is a PITA for a lot of reasons. From Helm to Telepresence to Skaffold, every tool out there is just unpolished and overambitious.

Don't want to imagine how those problems might amplify in production.

Sometimes choice of technology acts as a signifier. If you're building a startup, and you want to communicate to investors that "hey, we may not have the users yet, but we're built to scale!", Kubernetes and microservice architectures and sophisticated ETL pipelines convey that image better than saying "we've built for the minimal load that we're currently experiencing with a LAMP-based monolith.". The reality may be that your product's consumption patterns will never necessitate having anything more than that, even at a large scale. Your product may be great, you might easily be able to scale manually, but someone who holds the purse strings who knows just enough to be dangerous, might decide that if you're not using the "hot" technologies, you must not know what you're doing.

My experience is that Kubernetes is too complex for the average functioning product. At our company, everyone is obsessed with it because it promises no cloud vendor lock ins! But at what cost? The complexity. Also the direction cloud vendors are going in my opinion, is more hardware-centric (eg. TPUs). How will you avoid the cloud lock in when only Azure offers the image tagging machine learning as a service? How will Kubernetes solve that? I believe a balance between a small bit of lock-in, but retain environment freedom (free programming languages like python, javascript...) is the sweet spot for cloud, eg. PaaS like appengine or azure app service or beanstalk.

If you’re looking for a simple way to manage web apps on Linux, check out https://github.com/rcarmo/piku

I wrote it as a sort of micro-Heroku/Dokku replacement to run on small ARM boards, and ended up deploying a few apps with it on Intel boxes (I also use Docker Compose, but for simple stuff it’s overkill).

It uses uWSGI and is heavily Python-oriented, but I’ve run other stuff on it (it’s basically a supervisor with automatic reverse proxy setup and a Procfile approach to specifying what to run - git push to it and you’re in business).

If you're going to use Kubernetes it's good to look at your business case or other need. Don't use a hammer if you need to unscrew something.

Kubernetes has it's place... I recently wrote a post on that... https://codeengineered.com/blog/2018/kubernetes-biz-case/

But, there are many times you just don't need it. Like, for my personal sites... just isn't a need there.

Yeah, but... Nobody ever got fired for using K8s.

I do my level best to stay away from containers. I don't think most people even need them. It's a fad of sorts. I tend to stick with the tried and true and not follow trends, cloud or otherwise. Nothing worse than having your data on someone else's HW and losing connectivity through no fault of your own. Years ago, I worked for UUNET in Reston/Ashburn, VA, and built web servers and the attendant HW/SW that ran them (usually Sun Solaris/Apache/Oracle). We always had a "back net" into every device. Now? One NIC, one way in. I always like having more than one way to get to a device, be it local or remote. With the cloud, you tend to give this up. I recommend VMs over the cloud using someone else's data and data centre. Nothing worse than going to a tech conference with your boss, and him being the "deer in the headlights" as it were with regard to buying into what's being sold by the vendors. Last time we went, it took me the entire 3-hour car ride home to convince him we didn't need half of what was on offer. I tend to be old school and prefer to make do with Linux/FreeBSD VMs, and whatever software is needed to make something work. I like being in control of my own architecture.

If you don't have microservices/soa architecture then you don't need k8s. Most people don't need skyscrapers. But yet there's a lot of them in the world. Just because you don't need one and don't have one doesn't mean that other's don't

What bothers me the most is the assumption that adopting Kubernetes will solve all design problems.

Unfortunately standalone Docker container don‘t allow to inject secrets (keys, passwords, etc) in a secure way for your app in the container. For doing this it seems to be necessary to use a orchestration solution like swarm or kubernetes.

As much as I agree with the fact that for 95% of the cases k8s is not needed, the problem most likely lies in the overengineerin around it. Take a managed k8s solution setup a deployment that serves through an ingress controller. Done.

You most likely need few cheap servers, a loadbalancer and great team. So yeah no Kubernetes, no microservices nor chaos monkey. What you need is to know, really deeply know your technology stack. This is where boring software helps.

What is wrong with running your app on a managed kubernetes? Of course the cost of maintaining your own cluster is overwhelming for a company with less than 1k servers, but if Google is taking care of this for you, why not?

If you are writing "business" apps (for some definition of business), you should probably use a PaaS.

If you want to create a PaaS, Kubernetes is an excellent foundation (see Knative).

I just create a container image for my service and run it via the heroku container registry. Zero setup. I think it has auto scaling as well but I never needed that.

If you think you need kubernetes, docker, etc., you are wrong. This is the only thing you need to know about these technologies.

Isn‘t Kubernetes of today the same thing Tomcat used to be fo Java web applications yesterday?

A lot of people don't have a choice.

K8S is too complex. I just want a small and easy to use cluster toooool

This is another way of saying "You might need Kubernetes."

You don't need K8S, you don't need microservices.

Buy this danger hypnotism

Buy this danger hypnotism https://play.google.com/store/apps/details?id=com.rishibhaka...

You don’t.