“You don't need this overengineered goo for your project.” (opens in new tab)

Here's the stats on Stackoverflow

https://stackexchange.com/performance

1.3 billion page views per month, 9 web servers, 4 sql servers

Stackoverflow is notable because they went down the C#/MVC/SQL Server route from the start, which meant much better performance per server. Thats why they make an interesting counterexample to the usual way...

> No using any "ask {specific person}" either

It's worth mentioning that the diagram is explicitly incomplete. The yellow endpoints are fixes but except for "END" the other endpoints are all either "unknown state" (i.e. "I have no idea what's broken") or problems that aren't addressed in further detail like "The issue could be with Kube Proxy" or even "Consult StackOverflow".

I'm not sure what a complete diagram would even look like but I don't think there's any way to infer complexity by looking at them in comparison.

People do tend to cherry pick, don't they? Most of Stack Overflow's workload is returning a blob of html for a given url, to a not-logged-in user. Where that html doesn't even have to be the most recently saved copy.

It's taking one source - look at how these people solved it! - and trying to apply it to others.

SO is relatively simple; it's basically customized forum software which is a solved problem that has been around for decades. A junior dev can build an alternative, and it can be built using tried and true solutions like MySQL + PHP, which are horizontally scalable with database sharding, read replicas, and maybe stuff like memcached to accumulate votes before updating the database or a CDN for caching static files.

Google has different problems and different workloads, and they have hundreds of times more applications with thousands of times more load. Apples and oranges.

This is the proper reason why so many orgs are considering/using something as complex as Kubernetes. It is not such a easy comparison of 10 servers running K8S versus 6 servers running KVM. There is more to it. Once you do config management, safe deployment mechanisms, observability setup, network management, secrets, RBAC, identity mgmt etc the "just a few servers running Linux" setup looks almost as complicated as Kubernetes and you've created a bespoke setup that only you know how to operate. If you go the Kubernetes route, sure there are bells and whistles that are not needed for your use case, but it standardises the operations such that you can hire a new team member and supply K8S documentation to them and expect them to do things in your infra setup.

It is a choice. I have personally moved on from the "Kubernetes is never a good choice over running things yourselves" camp.

Nomad all the way. It's much easier and lighter than Kubernetes, but it does 3/4 of what Kubernetes does. The ecosystem is much lighter but depending on your needs it could be entirely sufficient.

I've written about Nomad vs k8s on my blog if that might interest you:

https://atodorov.me/2021/02/27/why-you-should-take-a-look-at...

And I've also written about some common things, like Traefik for ingress, Loki for logs, etc. to supplement the pretty complete Hashicorp tutorials.

It's all trade-offs. k8s is feature-rich, flexible and configurable but that also means high complexity. Simpler tools might not tick all the feature boxes.

As long as your applications follow 12-factor principles it shouldn't be too hard to move between different orchestration tools and you can pick the one that best suits your needs.

why don't you consider nomad[0] in your evaluations. i think it should fit your requirement.

[0] - https://www.nomadproject.io

aws elastic beanstalk

all what a modern web app needs out of the box with 1 day to learn instead of years... and the best? you don't have to modify your code to work on it, ie environment and code are separate.

> I’m sure a troubleshooting map for bare linux server wouldn’t be less complicated than that.‬

Except your k8s runs on a Linux server, so this is just an addition. (Unless you're using a fully managed k8s cloud offering, but then you have an even bigger toubleshooting flowchart to navigate the provider's management interface: at least that's my experience with GKE, maybe Amazon and others are better)

100% and one of the great things about k8s is that this diagram applies to essentially any application. Standardisation is awesome.

To be fair, the steps seem to map pretty well to the number of kubernetes resources you would need to create to do basic things like add a persistent disk, or get traffic to your application.

When I first saw it K8S reminded me a lot of systemd. I wouldn't be surprised if over the next few years each grow the features of the other.

Yes it does: https://stackexchange.com/performance

Pretty impressive I think.

Or a couple of servers running IIS with a handful of web apps, maybe a reverse proxy.

I think number of features have little to do with the situation.

Nowadays, everybody insists on putting stuff on K8s regardless of how large or small it is.

An application is an application for the purpose of running it on a server. It doesn't really matter how much functionality it has.

It is microservices "revolution" (quotes intentionally) that caused larger applications to be split a lot of small ones and complicated the execution environment to the point that a lot of people spend a lot of time just trying to figure out how to run their applications reliably.

That is not necessary.

If you can have multiple microservices, more likely than not you can have them as separate libraries used by single application or a separate modules of a single application. Just make sure to put the same thought into modularizing it as you would designing microservices APIs and you can have the same but much easier and with much better performance (no serialization/deserialization, no network hops, no HTTP stack, no auth, etc.)

I don't think this really does justice to what Stack Overflow does. They're probably the most visited engineering-related site on any given day. They have their widely known Q&A, live updates and notifications, chat rooms, a blog, job listings with email updates, review queues, moderator tools, and so forth. Perhaps you only use three features, but the site does a tremendous amount, and that's not even thinking about all the cross Stack Exchange network functionalities.

I hate it when people act like every other project has different constraints. For most web projects that is simply not the case. Maybe in some cases there are small differences which won't be noticed by any run of the mill setup. If your constraints are different but you have 100 members and never more (like most startups) your constraints generally don't matter even if they are radically different. Most people here are overarchitecting for the "chance of becoming Facebook"; personally I rather make a lot more profit (from day 1) by using cheap stuff and simple setups and when we accidentally make it to Facebook size, we will revisit. We can move it to Amazon to keep running and in the meanwhile rearchitect. But chances are against us, and all of you here, that we will ever reach anything close to this. Even with investor money (just did 2 raises) we have better stuff to do.

Just like there are people that love to setup an Hadoop cluster for data that fits into a USB pen, there are others that love to ramp up a Kubernetes cluster for what is a typical three tiered application.