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

Kubernetes is a red flag signalling premature optimisation

jeremybrown.tech

Post reply on HN
Print view View original

311–320 of 558 posts

Re: Kubernetes is a red flag signalling premature optimisation

#311

Post by osigurdson »

ClumsyPilot wrote: post #178
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…

The Whole advice of using same language is especially silly - iOS is stuck with Swift, and the web is stuck with JS, and maybe you need an applitation that scales using actors across mutiple machines with Golang or Java, or maybe you need to plug into Windows tightly and need C#. Kubernetes is not 'harder' if all you need is to host a webapp. Where it falls on the hardness spectrum depends on what you are trying to d…

Complexity is often conflated with lack of familiarity.

Re: Kubernetes is a red flag signalling premature optimisation

#312

Post by ryanbrunner »

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…

The thing is, unless using those technologies was somehow core to what the single engineer was trying to, it might be technically impressive but might not have actually provided value for users.

Users don't really care if you have a really impressive stack with cool technologies if it doesn't offer anything more than a couple of web servers and a DB server.

Re: Kubernetes is a red flag signalling premature optimisation

#313

Post by ImPleadThe5th »

I think it depends on where your "target" architecture is no? If you're doing monolith-first but know you eventually need to move to microservices, it might make sense to put in some effort to learning k8s in the simplest case first and expanding it out.

I think the issue with people that use k8s first is that they go for super trendy architectures before really nailing down the business logic first. This leads to technical debt and a lot of confusion around the tool.

Re: Kubernetes is a red flag signalling premature optimisation

#314

Post by mwcampbell »

chrisweekly wrote: post #246
AgentME wrote: post #214

Earlier quoted context omitted.

Even when using Nextjs, it's still pretty common to have a separate API backend that doesn't also have to be in Javascript/Node. There are parts of backend code (HTML generation) that very strongly benefit from being unified with the frontend code, and there are parts of backend code (like database persistence code) that much less strongly if at all in some cases benefit from unification with the frontend code. Many…

This. I like how the Remix.run devs frame the "BFF" (Backend-For-Frontend) pattern: https://remix.run/docs/en/v1/guides/bff

That document starts with this:

> While Remix can serve as your fullstack application,

Isn't that where most teams should start, and where they should stay unless they have a really good reason to get more complicated? This is what I was thinking of while reading the GP comment about Next.js.

Re: Kubernetes is a red flag signalling premature optimisation

#315

Post by _gabe_ »

morelish wrote: post #302
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'll make these four lines of code a function in case I need to call it more than once later on - you know, what if that's needed? The code example is not always right. Beware, if you know it will be needed, you might as well make it a function now. Likewise if you think probably it will be needed, why not make it a function now? It’s not a good review comment or rejection to say “yeah but I don’t want to do that b…

> Sure, but what if you are just being lazy and you don’t appreciate what it should look like long term?

I wasn't aware that some devs have a side hustle as fortune tellers?

On a more serious note, you should take a look at Sandi Metz's "the wrong abstraction". https://sandimetz.com/blog/2016/1/20/the-wrong-abstraction

Re: Kubernetes is a red flag signalling premature optimisation

#316

Post by SOLAR_FIELDS »

movedx wrote: post #270
okamiueru wrote: post #106

Earlier quoted context omitted.

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…

> 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 through nginx and cert-manager, do full integration tests, etc. I found that to be quite impressive, for one person, one year,…

I was able to do something similar by myself in only about a month or so (ops and production ready with backups etc) using https://www.digitalocean.com/community/tech_talks/getting-st...

Once you understand the concepts it's not hard to debug. It's fair to acknowledge that kubernetes is complex, but also we should not ignore the real work that has been done in the past few years to make this stuff more accessible to the developers that want to learn it.

Also, saying it's not "alone" in this example I think is not fair. What would you count as "alone"? Setting up the kubernetes cluster from scratch and writing your own helm charts? Using that same logic, I can't say that because someone else designed and built the hardware it's running on. I think it's fair to say that if someone, independent of coaching, regardless of the underlying infrastructure produced some production grade infrastructure by themselves, they certainly did it alone.

Re: Kubernetes is a red flag signalling premature optimisation

#317

Post by ryanbrunner »

jhugo wrote: post #156
john_the_writer wrote: post #134

Earlier quoted context omitted.

Right.. But scale? I've seen places hire a dev that write all the OPS stuff and they scaled awesomely.. I mean if they had purchased 100servers full time on amazon, they would have spent a fraction of the cost to scale, but they could scale. In 5 years I think they've never once had to reach even near the 100servers. At the same time. I can scale heroku to 500 servers, and still be under the cost of one ops person. I…

> At the same time. I can scale heroku to 500 servers, and still be under the cost of one ops person. I can make that change and leave it there. I can do that all in under 30 seconds. Oh. And CICD is built in as a github hook. Even with blue-green deploys. And then Heroku shuts down. If you're building something that needs to scale up rapidly if it succeeds, k8s is worth thinking about. Either you don't succeed, in w…

Success is rarely so rapid that you can't throw money at a problem temporarily and build something more robust.

No one is advocating for a single server running in your closet, but a large and well funded PaaS can handle any realistic amount of growth at least temporarily, and something like Heroku is big enough (and more importantly, owned by a company big enough) that shutting down without notice is not a possibility worth considering.

Re: Kubernetes is a red flag signalling premature optimisation

#318

Post by politician »

Jistern wrote: post #296
politician wrote: post #294

Earlier quoted context omitted.

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.

I’ve run DevOps and know from experience the pitfalls. I’m sorry that you’ve interpreted my general agreement and elaboration of your comment as nitpicking foolishness.

Re: Kubernetes is a red flag signalling premature optimisation

#319

Post by JohnHaugeland »

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…

> But the next advice about not using a different language for frontend and backend is wrong.

Er.

I read this as him saying "one of the things I've seen as a bad reason to use Kubernetes is that there are multiple languages in use."

I've seen people do this. Frontend in one container, backend in another, Kube to manage it.

If that's what author meant, author is right, that's a profoundly stupid (and common) reason to involve Kube.

Re: Kubernetes is a red flag signalling premature optimisation

#320

Post by JohnHaugeland »

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…

Basically none of that needs, or is helped by, kube
Post reply on HN