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

551–558 of 558 posts

Re: Kubernetes is a red flag signalling premature optimisation

#551

Post by heurist »

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

There is very little software development that does not rely on the products of open source communities these days...

Re: Kubernetes is a red flag signalling premature optimisation

#552

Post by wahnfrieden »

okamiueru wrote: post #475
noogle wrote: post #306

Earlier quoted context omitted.

> good and easier way to deploying 10-15 services Why are so many micro-services needed? Could the software be deployed in a more concise manner? Not getting into the whole monolith-vs-services arguments. In both cases, complexity of deployment is part of the cost of each option.

I should perhaps have clarified, but the 10-15 are not self maintained services. You need nginx for routing and ingress, set up cert-manager and other ingress endpoints are automatically configured to have TLS, deploy prometheus, which comes with node-exporter and alert-manager, deploy grafana. So far, we're up at 6 services, yet still at almost zero developer overhead cost. Then add the SaaS stack for each environme…

those are basically all things that can be outsourced and not for much money (cloudflare etc)

Re: Kubernetes is a red flag signalling premature optimisation

#553

Post by chrisweekly »

mwcampbell wrote: post #314
chrisweekly wrote: post #246

Earlier quoted context omitted.

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.

For greenfield projects, yes. But for projects where there's already a decent backend API, it's a reasonable approach to use Remix "only" as a BFF.

Re: Kubernetes is a red flag signalling premature optimisation

#554

Post by wahnfrieden »

osigurdson wrote: post #520
wahnfrieden wrote: post #203

Earlier quoted context omitted.

Sounds like a waste of months that could have gone into building product by choosing simpler operational tech

How would you possibly know one way or the other?

the heck?

Re: Kubernetes is a red flag signalling premature optimisation

#555

Post by noogle »

neurostimulant wrote: post #333
noogle wrote: post #306

Earlier quoted context omitted.

> good and easier way to deploying 10-15 services Why are so many micro-services needed? Could the software be deployed in a more concise manner? Not getting into the whole monolith-vs-services arguments. In both cases, complexity of deployment is part of the cost of each option.

Sometimes it's faster to implement certain features in another languages and deploy it as microservice instead of fighting your primary language/framework to do it. Deploying microservices in k8s is as easy as writing a single yaml file.

Makes sense, though 15 different languages?

I am not privy to the details of the case, but a rule-of-thumb I heard once is that if it's far enough from your core, a SaaS can be used (obviating the whole question), and if it's part of the core, start by developing it as a separate functionality before moving it to another service.

Re: Kubernetes is a red flag signalling premature optimisation

#556

Post by the_scoop »

Build for today's needs but have a notional roadmap for how to scale your architecture as the company grows. The author is mostly correct that K8 is complete overkill for most early/mid stage companies and startups, however extensibility is a key architectural concern and one that cannot afford to ignored at the outset. If you need to re-write large amounts of code from scratch every time your business scales up that's a good sign that you aren't thinking far enough ahead. For instance here are some straight-forward things you can probably do today that require little additional effort but will make a migration to k8 much less painful down the road (should you ever get there): 1) Use domain driven design to properly abstract your code 2) Make services and auth stateless where-ever possible/practical 3) Containerize your codebase and leverage a container registry as part of your CI/CD process

BLUF always have both a current state architecture as well as a future state architecture in mind and a plan for how to gradually evolve from one to the other over time.

Re: Kubernetes is a red flag signalling premature optimisation

#557

Post by orange-mentor »

AtNightWeCode wrote: post #435

The part of Kubernetes and startups is 100% correct I believe. It is very hard for some people to not own a thing. People can be very narrow-minded about buying a service. Even though they at the same time gladly buys work-hours to offload their personal workload. To set up complete envs for dev, test and prod with GIT, full CI/CD and everything you need like databases and storage is less than 20 hours work in a mode…

This person gets it.

Re: Kubernetes is a red flag signalling premature optimisation

#558

Post by aabbcc1241 »

danielvaughn wrote: post #287
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've told this story before on HN, but a recent client of mine was on Kubernetes. He had hired an engineer like 5 years ago to build out his backend, and the guy set up about 60 different services to run a 2-3 page note taking web app. Absolute madness. I couldn't help but rewrite the entire thing, and now it's a single 8K SLOC server in App Engine, down from about 70K SLOC.

That is a real life story of "drink too much kool-aid"
Post reply on HN