Kubernetes is a red flag signalling premature optimisation • Hacker News Board

Re: Kubernetes is a red flag signalling premature optimisation

#291

Post by sudarshnachakra » Mon, Jul 04, 2022, 12:58 PM UTC

movedx wrote: post #273

sudarshnachakra wrote: post #265

While I tend to agree to the conclusion on premature optimization - I disagree with the assumption that it is premature for most startups. In fact it's a reasonable insurance for startups (that is - if at all they succeed) it'll solve the problem of scale at that point without needing to make huge changes. BTW Google open-sourced Kubernetes not for charity (like all businesses they also want to make money), they knew…

> ... it'll solve the problem of scale at that point without needing to make huge changes. This is incorrect. It's a common mistake to pre-optimise for a future that may never come. I call it "What-If Engineering". You should always just build a monolith and scale it out as and when you understand what it is that needs scaling. Choosing the right languages and frameworks is where you need to put your effort. Not K8s.…

What you say is true, but that is how insurance works - you pay a premium for "What if something unexpected happens", there is a 9 nines chance that it'd not happen but still we keep paying. K8s is similar.

Re: Kubernetes is a red flag signalling premature optimisation

#292

Post by adwn » Mon, Jul 04, 2022, 12:59 PM UTC

candiddevmike wrote: post #245

mattlondon wrote: post #229

Earlier quoted context omitted.

In my mind it is not code reuse between frontend and backend, but expertise and standard library reuse that is the winner. Better to have a full stack developer that can concentrate on becoming an expert and fluent in just one language rather than being kinda-ok in 3 or 4 IMHO.

You really think programming languages are that different?

It's not a question of "if" a developer can learn a new language, but of "how long" it takes. And it's not a question of how long it takes to become moderately productive, but how long it takes to reach an expert level of proficiency.

Re: Kubernetes is a red flag signalling premature optimisation

#293

Post by j_m_b » Mon, Jul 04, 2022, 1:00 PM UTC

Kubernetes seems like subversion before git came out. Overly complex but got the job done. When git came out, all other VCSs were quickly abandoned. Just waiting for the day when the git of container management comes out.

Re: Kubernetes is a red flag signalling premature optimisation

#294

Post by politician » Mon, Jul 04, 2022, 1:04 PM UTC

Jistern wrote: post #288

movedx wrote: post #278

I agree entirely. I like to call what the author is referring to as, "What-If Engineering". It's the science of thinking you'll be Google next week, so you build for that level of scale today. It involves picking extremely complicated, expensive (both in compute and skilled labour) technologies to deploy a Rails app that has two features. And it all boils down to, "But what if..." pre-optimising. It happens at all le…

>> I agree entirely. I agree entirely too. >> Start with a monolith on two VMs and a load balancer. Chips and networks are cheaper than labour, Kudos to you! You are a dangerous man for you opine the truth. My advice is generally, "Build something. Then see if you can sell it." or "Sell something and then go build it." Either way, it all starts soooo small that the infrastructure is hardly a problem. If you "get luck…

You can’t just hire 1 DevOps superstar though because they need to sleep and not burnout. You’ll need ~7 people on a rotation if you need to really support anything worth really supporting. DevOps is about giving Developers a dedicated System Operations job for some small fraction of their time.

Re: Kubernetes is a red flag signalling premature optimisation

#295

Post by ckdarby » Mon, Jul 04, 2022, 1:04 PM UTC

pjmlp wrote: post #20

ale42 wrote: post #17

Why should using different languages for front-end and back-end be a problem? I rather think that it is better to use languages that are appropriate for the given problem. It is not premature optimization to have parts of a back-end implemented in C/C++/Go/whatever else if high performance is needed. It would rather be a waste of resources, money and energy not to use an high-performance language for high-performance…

Its seems to be a new thing with younger generations. We never had an issue with multiple languages across tier-n architectures. Suddenly with the uptake of HTML 5, it became an issue not being able to use JavaScript everywhere.

It's about hiring talent that can drive customer value without concern for anything else and the business can eventually hire more experienced individuals to fix the mud mountain if there's market fit and continued need.

It is extremely easier to find more affordable talent that has come out of a boot camps knowing javascript but more specifically "react/nodejs" which lets them work both frontend and backend. They rarely know best practices, how to properly debug & troubleshoot a problem that isn't a Google search away, etc, but they will be hungry and work their butts off to ship their CRUD style features.

Re: Kubernetes is a red flag signalling premature optimisation

#296

Post by Jistern » Mon, Jul 04, 2022, 1:12 PM UTC

politician wrote: post #294

Jistern wrote: post #288

Earlier quoted context omitted.

>> I agree entirely. I agree entirely too. >> Start with a monolith on two VMs and a load balancer. Chips and networks are cheaper than labour, Kudos to you! You are a dangerous man for you opine the truth. My advice is generally, "Build something. Then see if you can sell it." or "Sell something and then go build it." Either way, it all starts soooo small that the infrastructure is hardly a problem. If you "get luck…

You can’t just hire 1 DevOps superstar though because they need to sleep and not burnout. You’ll need ~7 people on a rotation if you need to really support anything worth really supporting. DevOps is about giving Developers a dedicated System Operations job for some small fraction of their time.

Good grief. First and foremost I was simplifying to make a point.

>> You can’t just hire 1 DevOps superstar

Secondly, that assertion is not necessarily true. Obviously, you should just hire 1 DevOps superstar... in some cases.

Don't nitpick and don't argue foolishly.

Re: Kubernetes is a red flag signalling premature optimisation

#297

Post by d23 » Mon, Jul 04, 2022, 1:12 PM UTC

I wanted to agree with this, but this line (mentioned as a premature optimization) is absolutely baffling to me:

“More than one language for your application. For example, a backend in Golang, Ruby, PHP etc. and a Frontend Web App in React, Vue etc.”

When would your front end and backend ever be in the same language? I guess JavaScript would be your only option?

Re: Kubernetes is a red flag signalling premature optimisation

#298

Post by osigurdson » Mon, Jul 04, 2022, 1:12 PM UTC

movedx wrote: post #278

I agree entirely. I like to call what the author is referring to as, "What-If Engineering". It's the science of thinking you'll be Google next week, so you build for that level of scale today. It involves picking extremely complicated, expensive (both in compute and skilled labour) technologies to deploy a Rails app that has two features. And it all boils down to, "But what if..." pre-optimising. It happens at all le…

>> Helm and the likes make it possible to spin up these kinds of solutions in a heart beat

Genuine question, why is this bad? Is it because k8s can spin it up but becomes unreliable later? I think the industry wants something like k8s - define a deployment in a file and have that work across cloud providers and even on premise. Why can't we have that? It's just machines on a network after all. Maybe k8s itself is just buggy and unreliable but I'm hopeful that something like it becomes ubiquitous eventually.

Re: Kubernetes is a red flag signalling premature optimisation

#299

Post by preommr » Mon, Jul 04, 2022, 1:14 PM UTC

movedx wrote: post #278

I agree entirely. I like to call what the author is referring to as, "What-If Engineering". It's the science of thinking you'll be Google next week, so you build for that level of scale today. It involves picking extremely complicated, expensive (both in compute and skilled labour) technologies to deploy a Rails app that has two features. And it all boils down to, "But what if..." pre-optimising. It happens at all le…

> It's the science of thinking you'll be Google next week,

There's other reasons to use K8s than just thinking of massive scale.

Setting up environments becomes a massive PITA when working directly with VMs. The end result is either custom scripts, which is a messier version of terraform, which ends up being messier than just writing a couple of manifest files for a managed k8s.

> anyone with K8s experience is demanding $150k + 10% Superannuation here in Australia... minimum!

sheds a tear for CAD salaries and poor career decisions

Re: Kubernetes is a red flag signalling premature optimisation

#300

Post by grog454 » Mon, Jul 04, 2022, 1:14 PM UTC

okamiueru wrote: post #106

pritambarhate wrote: post #84

Doesn't look like the author knows what he is talking about. His point about early stage startup should not use K8S is fine. But the next advice about not using a different language for frontend and backend is wrong. I think the most appropriate advice is to choose a stack which the founding team is most familiar with. If that means RoR then RoR is fine. If it means PHP then PHP is fine too. Another option is to use…

I don't think their advice about not using it in a startup is correct either. You just need to somewhat know what you're doing. I know of such a case, where a single engineer could leverage the helm chart open source community, and set up a scalable infrastructure, with prometheus, grafana, worker nodes that can scale independently of web service, a CI/CD pipeline that can spin up complete stacks with TLS automated t…

> with prometheus, grafana, worker nodes that can scale independently of web service, a CI/CD pipeline that can spin up complete stacks with TLS automated through nginx and cert-manager, do full integration tests, etc.

> I found that to be quite impressive, for one person, one year, and would probably be completely impossible if it wasn't for k8s.

I've always found this interesting about web based development. I have no idea what Prometheus, grana, etc do. Ive never used k8s.

And yet, as a solo dev, I've written auto-scaling architecture using, for example, the AWS ec2 apis that let you launch configure and shutdown instances. I don't know what else you need.

Really the only advantage I see to morass of services is you get a common language so other devs can have a slightly easier time of picking up where someone left off. As long as they know all the latest bs.