Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

“You don't need this overengineered goo for your project.”

twitter.com

Post reply on HN
Print view View original

61–70 of 107 posts

Re: “You don't need this overengineered goo for your project.”

#61

Post by reacharavindh »

bsaul wrote: post #2

recently facing the dilemma of choosing between k8s vs something more basic. Features that seemed to be advocating for k8s were not server provisionning, but instead : log management, easy setup of blue/green & canary deployment, not having to restart a vm upon new code deployment, etc... How would you do those things as easily with other techs ?

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.

Re: “You don't need this overengineered goo for your project.”

#62

Post by fabian2k »

tester34 wrote: post #55
sofixa wrote: post #54

Earlier quoted context omitted.

Updated my comment for clarity - yes, SQL Server and Windows for their .NET app. Maybe they've moved to Linux if they have finished their migration to .NET Core, but even if they did, it's a fairly recent thing.

> Maybe they've moved to Linux if they have finished their migration to .NET Core, As far as I know they have been using .NET Core (or just EF Core? would be weird to go EF Core + .NET Framework, I guess?) on prod in 2018: >This is the query pattern that caused StackOverflow.com to go offline yesterday: https://github.com/dotnet/efcore/issues/13524 So maybe they used some things on Linux and some things on Windows -…

They're using .NET Core, and I think even .NET 5 in the meantime though I couldn't find a clear confirmation for that. But they're still on Windows, looking at Linux and containers for potentially in the future.

Re: “You don't need this overengineered goo for your project.”

#63

Post by Aeolun »

monus wrote: post #5

‪That’s not an architecture diagram though, so it doesn’t represent the complexity at all. I’m sure a troubleshooting map for bare linux server wouldn’t be less complicated than that.‬

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.

Re: “You don't need this overengineered goo for your project.”

#64

Post by cameronh90 »

lmilcin wrote: post #58
cameronh90 wrote: post #37

Earlier quoted context omitted.

"Nowadays, everybody insists on putting stuff on K8s regardless of how large or small it is." But if you already have the tooling, experience and support for k8s, why wouldn't you use it? I can fire up a k8s cluster on any major cloud provider in minutes (or bare metal in slightly longer), and deploy almost any web app using a standard interface that has extremely wide adoption. K8s supports a ton of things, but you…

> It can be complicated, but usually it's not. The usual story. Everything works, until it doesn't. If you are a huge corp with good engineering you can have people dedicated to understanding k8s and then it kinda makes sense. They can spend time to learn it really well so that they have necessary chops to deal with problems when they happen. On the other hand, if you are smaller company, you are more likely embracin…

"The usual story. Everything works, until it doesn't."

But the same is true of all the other orchestration tools isn't it?

I've had similarly complicated problems with Terraform, Ansible, Chef and Puppet and just plain Linux as I have had with Kubernetes. Meanwhile K8S saves a lot of time when things do work properly - which is nearly always.

A while ago, we had an issue with dotnet where the JIT was sometimes emitting bad instructions and crashing the process. That was an absolute bloody nightmare to debug and reproduce, it took weeks - but nobody would say running a high level language is bad because the compiler might have a bug, right?

We are a small company (under 20 developers), we have one dedicated ops person and one devops, and have never had any issues with k8s that couldn't be resolved by one of them within a few hours. We run a monorepo with 6 app services as part of our core product, 10 beta/research services, then a handful more infrastructure services (redis etc.), and honestly it's been the smoothest environment I've ever worked with. All the infrastructure is defined in code, can be released onto a blank AWS account (or k3s instance) in minutes, all scales up and down dynamically with load, and most of the time something goes wrong it's a bug in our code.

Maybe the problem with your system was more about the excessive use of microservices and general system architecture rather than Kubernetes itself?

Re: “You don't need this overengineered goo for your project.”

#65

Post by p_l »

JimDabell wrote: post #39
Cthulhu_ wrote: post #34

Earlier quoted context omitted.

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 li…

> 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 Which of these do you think most organisations most closely resemble? I don’t think anybody would disagree if y…

Stack Overflow is also a) old system built before a lot of current management tech was available openly b) Very single-application centered.

EDIT: To expand on it - they had to manually build a lot of what could be much easier handled today, and thus had no incentive to change later. Interestingly enough, SO has a lot of moving parts distributed over multiple servers, even if all of those servers used to fit into 1-3 racks per DC.

Re: “You don't need this overengineered goo for your project.”

#66

Post by piva00 »

tester34 wrote: post #51
Cthulhu_ wrote: post #34

Earlier quoted context omitted.

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 li…

>A junior dev can build an alternative Of course junior dev can do it, the same way junior dev can make Youtube it'll work as long as there's less than 100 concurrent users on SO and less than 50 4K 20min videos on youtube

Sometimes I question myself if people posting these "a junior dev can build this product" haven't really worked with systems at scale and all of the myriad of issues that scale brings or if they are being the usual hyper-optimistic-dev that isn't considering much past the proof-of-concept point of a product.

Either way is quite baffling how common this kind of comment is, almost a decade reading Hacker News and it pops up constantly.

Re: “You don't need this overengineered goo for your project.”

#67

Post by OJFord »

slooonz wrote: post #32
szszrk wrote: post #27

Earlier quoted context omitted.

Exactly. That twitter thread is just pure rage based on no data. Sum up resources from that page - we are talking around 6500GB* of RAM worth of servers. That is no homelab. * Maybe a bit more/less, because it's not clear to me if DB RAM is per server, or per cluster. Likely server, as on other servers. There is also no data on how big is their haproxy.

And yet the main point stand : they don't need K8s to manage this application running on 23 servers.

And yet it wouldn't be out of place either.

Re: “You don't need this overengineered goo for your project.”

#68

Post by lmilcin »

cameronh90 wrote: post #64
lmilcin wrote: post #58

Earlier quoted context omitted.

> It can be complicated, but usually it's not. The usual story. Everything works, until it doesn't. If you are a huge corp with good engineering you can have people dedicated to understanding k8s and then it kinda makes sense. They can spend time to learn it really well so that they have necessary chops to deal with problems when they happen. On the other hand, if you are smaller company, you are more likely embracin…

"The usual story. Everything works, until it doesn't." But the same is true of all the other orchestration tools isn't it? I've had similarly complicated problems with Terraform, Ansible, Chef and Puppet and just plain Linux as I have had with Kubernetes. Meanwhile K8S saves a lot of time when things do work properly - which is nearly always. A while ago, we had an issue with dotnet where the JIT was sometimes emitti…

> But the same is true of all the other orchestration tools isn't it?

Of course. The difference being how complicated it is to deal with problems.

For example I find it is way easier to deal with problems with Ansible compared to Chef.

So, assuming that both get me what I need, I prefer Ansible because it is less drag for when I have least time available to babysit it (which usually happens at least opportune moment).

What I am trying to say is that, just because it works for you now doesn't mean it will not end in a disaster at some time in the future. It is not my position to tell you if the risk is acceptable for you. But I personally try to avoid situations from which I cannot back easily.

If I have a script that starts an application on a regular VM I KNOW I can fix it whatever may happen to it. Not that I advocate running your services with a script, I just mean there is a spectrum of possible solutions with tradeoffs and it is good to understand those tradeoffs.

Some of those tradeoffs are not easily visible because they may only show themselves in special situations or, opposite, be so spread over time and over your domain that you just don't perceive the little drag you get on everything you do.

I find that if there is any overarching principle to build better solutions it is simplicity.

Presented with two solutions to the problem, the simpler solution is almost always better (the issue being the exact definition what it means to be simpler).

For example, I have joined many teams in the past that had huge problems with their applications. I met teams that were very advanced (they liked overcomplicating their code) and I met teams that could barely develop (they had trouble even writing code, did not know or use more advanced patterns).

I found that it is easier to help teams that had huge problems but wrote stupid code because it is easier to refactor stupid simple code that beginner developers write than it is to try to unpack extremely convoluted structures that "advanced" developers make.

I think similar applies to infrastructure.

For example, when faced with an outage I would usually prefer simpler infrastructure that I know I understand every element of.

Re: “You don't need this overengineered goo for your project.”

#69

Post by hughrr »

necrobrit wrote: post #6
monus wrote: post #5

‪That’s not an architecture diagram though, so it doesn’t represent the complexity at all. I’m sure a troubleshooting map for bare linux server wouldn’t be less complicated than that.‬

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

Unfortunately as a k8s user in the real world every container is slightly different and has numerous hacks in it to make it compatible with k8s in some way or another. So no.

Re: “You don't need this overengineered goo for your project.”

#70

Post by actually_a_dog »

codeulike wrote: post #40
corobo wrote: post #10

I love these Twitter takes. They say something to get attention but if you look at it for more than a second it's.. it's just nothing data Comparing a troubleshooting guide to running a site on a couple of servers is a bit too different for me. Compare it to a troubleshooting guide for those two servers, let's see how they stack up. No using any "ask {specific person}" either Don't get me wrong, kubernetes is overkil…

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...

You left off 10 servers: 2 Redis servers, 3 tag engine servers, 3 Elasticsearch servers, and 2 HAProxy servers. So, that's 23 servers in total, which is not a trivial amount, but also not a huge number, either.
Post reply on HN