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

321–330 of 558 posts

Re: Kubernetes is a red flag signalling premature optimisation

#321

Post by ryanbrunner »

preommr wrote: post #299
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 demand…

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

The author advocates using a high-level PaaS. For sure working directly with VMs is the wrong answer to premature optimization, but as an early stage startup, there's plenty of services around that you basically just need to point your Git repo at and you'll have a reasonable infrastructure set up for you.

Re: Kubernetes is a red flag signalling premature optimisation

#322

Post by muskmusk »

I guess you wanted attention, congratulations you got it.

As far as the advice goes. No not really, lots of people are familiar enough with Kubernetes that it makes it the fastest choice possible for them. Engineers like to pretend that tech choices are oh so important and can be discussed in a vacuum, but really most tech choices are made once you know the people who are working on the project.

Pick stuff that is familiar to you unless you have a good reason to do otherwise.

Re: Kubernetes is a red flag signalling premature optimisation

#323

Post by neurostimulant »

wrnr wrote: post #175
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…

How long did it take him to do this setup, a year you say, and that is impressive? I am not trying to be cute here, my question comes from a genuine place of curiosity. I've love to learn to spin-up a system like that, but from the tech/sales talks I see I am made to believe this can be done in a day. Expectation management is important, if people say ops is just a solved problem then I expect this to take very littl…

It's actually pretty easy to do these days, even on bare metal servers. My go to setup for a small bare metal k8s cluster:

- initial nodes setup: networking configuration (private and public network), sshd setup (disallow password login), setting up docker, prepping an NFS share accessible on every nodes via private network

- install RKE and deploy the cluster, deploy nginx ingress controller

- (optional) install rancher to get the rest of the goodies (graphana, istio, etc). These ate a lot of resources though, so I usually don't do this for small clusters

Done in a single afternoon.

Re: Kubernetes is a red flag signalling premature optimisation

#324

Post by mgkimsal »

okamiueru wrote: post #260
KptMarchewa wrote: post #222

Earlier quoted context omitted.

>This 'simpler operational tech' would still need to be able to scale, correct? Only if "scaling" is the problem that your startup is solving.

Any startup that knows what their product is and are done with PoCs, should be able to deal with the consequence of succeeding, without failing. Scaling is one of those things that should be in place before you need it. In our case, scaling was a main concern.

> In our case, scaling was a main concern.

and ... you might be justified in that concern. However... after having been in the web space for 25+ years, it's surprising to me how many people have this as a primary concern ("we gotta scale!") while simultaneously never coming close to having this concern be justified.

I'm not saying it should be an either/or situation, but... I've lost count of how many "can it scale?" discussions I've had where "is it tested?" and "does it work?" almost never cross anyone's lips. One might say "it's assumed it's tested" or "that's a baseline requirement" but there's rarely verification of the tests, nor any effort put in to maintaining the tests as the system evolves.

EDIT: so... when I hear/read "scaling is a main concern" my spidey-sense tingles a bit. It may not be wrong, but it's often not the right questions to be focused on during many of the conversations I have.

Re: Kubernetes is a red flag signalling premature optimisation

#325

Post by boloust »

philliphaydon wrote: post #226
lbriner wrote: post #194

Earlier quoted context omitted.

Totally agree! Kubernetes isn't just about global scale that most people will never need, which would agree with the article. It is about deploying new apps to an existing production system really quickly and easily. We can deploy a new app alongside an old app and proxy between them. Setting up a new application on IIS or a new web server to scale is a mare, doing the same on AKS (managed!) is a breeze. It is also r…

> Setting up a new application on IIS or a new web server to scale is a mare. I disagree. With octopus deploy I can add a step, set a package and hostname, and press a button, and have a new deployment of a new api or website in IIS pushed out to how ever many servers currently exist in a few minutes. There are many ways to manage deploying services, and scaling, without K8S or containers in general. While I could se…

That is very interesting, I'd love to know more about how this works.

- How does it decide which servers to deploy to?

- Does it scale up the number of servers if the deployment is too large?

- What happens when a server dies?

Re: Kubernetes is a red flag signalling premature optimisation

#326

Post by bob1029 »

grumpy-de-sre wrote: post #92

At this point I'm pretty much convinced these repeated "Kubernetes is bad for startups" rants are some kind of FUD campaign (probably grass roots from people who've missed the containerisation and declarative infra train). Kubernetes is actually pretty great for the vast majority of use-cases. Sure if you don't have experience with kubernetes leave learning it until after you've hit product-market fit. But rejecting…

> probably grass roots from people who've missed the containerisation and declarative infra train

I am curious. How much work would it take to get on this train in 2022? Sounds like more of a cult than a valuable technology proposition when presented in this manner.

Re: Kubernetes is a red flag signalling premature optimisation

#327

Post by ryanbrunner »

engineeringwoke wrote: post #267
hsn915 wrote: post #200

Earlier quoted context omitted.

> The biggest learning curve is for the person setting up the initial deployments, services, ingress etc Most other team members may just need to maybe change the image name and kubectl apply to roll things out. This is a huge redflag. It's basically admitting that you expect most later employees to not understand k8s or how its being used. You may think they don't need because it works, but you have to think about w…

It's healthy to depend on your coworkers for their specific knowledge. The landscape is too large for everyone to know everything, and honestly if I heard someone say this in an interview I would chalk it down to social deficits because this is not how life, businesses, etc. work

I think the key with this though is that it's good when everyone on a team has a working knowledge of something, and one person has expert knowledge. If one person knows everything there is to know, and everyone else knows nothing, you've created a massive dependency on the single person (which in the case of infrastructure code, could easily be a near existential problem for the company).

Re: Kubernetes is a red flag signalling premature optimisation

#328

Post by mwcampbell »

jpgvm wrote: post #71
maverwa wrote: post #42

Earlier quoted context omitted.

I think the argument was/is not "its a problem we cannot have javascript" but "if we can have javascript everywhere, we only need to hire javascript devs and only need to care about javascript tooling", which is a fair point. That does ignore the fact that an experienced frontend JS dev is not necessarily also a good productive backend JS dev, but at least they know the language basics, can use the same IDE, etc. If…

I think this has been a huge failing of our industry of late. The rise of the "fullstack developer" has mostly reduced quality across the board. When you hire a "fullstack developer with 5 years experience" you aren't getting someone who is as good as a frontend developer with 5 years AND a backend developer with 5 years but someone that adds up to 5 years split between those 2 endeavors but probably with less depth…

> The rise of the "fullstack developer" has mostly reduced quality across the board.

Having a solo developer that can do it all well enough also allows useful products to reach users faster (and for me it's really about solving user problems, not just making money), without getting derailed by communication overhead, bureaucracy, fighting within the team, etc. Just make sure you don't pick a developer who cares too much about things that mostly matter to other nerds, because then they might get derailed with premature optimization. Yeah, I've been there.

Re: Kubernetes is a red flag signalling premature optimisation

#329

Post by [deleted] »

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…

[deleted]

Re: Kubernetes is a red flag signalling premature optimisation

#330

Post by tenfourty »

ryanbrunner wrote: post #321
preommr wrote: post #299

Earlier quoted context omitted.

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

> 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. The author advocates using a high-level PaaS. For sure working directly with VMs is the wrong answer to premature optimization, but as an early stage startup, there'…

OP here, I agree. You can get super far with a service like fly.io/Heroku/Netlify/Vercel etc. (pick the one that works with your stack). VMs are an anti-pattern as well for the early stages of an application or startup.
Post reply on HN