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

Re: Kubernetes is a red flag signalling premature optimisation

#351

Post by mountainriver » Mon, Jul 04, 2022, 2:28 PM UTC

ryanbrunner wrote: post #312

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…

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.

Yeah but k8s isn’t hard at all if you know it, it’s actually substantially easier than a couple web servers and dbserver and provides a whole lot more

Re: Kubernetes is a red flag signalling premature optimisation

#352

Post by nprateem » Mon, Jul 04, 2022, 2:31 PM UTC

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.

Just keep it simple, and if you take off scale vertically while you then work on a scalable solution. Since most businesses fail, premature optimisation just means you're wasting time that could have gone on adding more features or performing more tests.

It's a trap many of us fall into - I've done it myself. But next time I'll chuck money at the problem, using whatever services I can buy to get to market as fast as possible to test the idea. Only when it's proven will I go back and rebuild a better product. I'll either run a monolith or 1-2 services on VPSs, or something like Google cloud run or the AWS equivalent.

Scaling something no one wants is pointless.

Re: Kubernetes is a red flag signalling premature optimisation

#353

Post by mountainriver » Mon, Jul 04, 2022, 2:32 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…

Sorry but managed k8s is really simple and wildly a better pattern than just running VMs. You don’t need google scale for it to help you, and spinning things up without understanding the maintenance cost is just bad engineering

Re: Kubernetes is a red flag signalling premature optimisation

#354

Post by jhugo » Mon, Jul 04, 2022, 2:33 PM UTC

K0SM0S wrote: post #225

jhugo wrote: post #156

Earlier quoted context omitted.

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

> if you were smart about how you used k8s, you'll be glad that you can relatively easily move between clouds or move to bare metal. I'd argue you should definitely consider multi-cloud strategy from the get-go indeed in 2022. Something like Terraform helps statically setting k8s clusters on most clouds. Especially for startups, it's better to default to vanilla stuff and only complicate on a need-to basis.

Yes, completely agreed. Multi-cloud is really not that difficult nowadays, and it puts you in a better negotiating position (when you end up spending enough to be able to negotiate), as well as giving you more location flexibility and the ability to pick and choose the best services from each cloud.

Re: Kubernetes is a red flag signalling premature optimisation

#355

Post by nprateem » Mon, Jul 04, 2022, 2:36 PM UTC

sk0g wrote: post #261

wrnr wrote: post #175

Earlier quoted context omitted.

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…

With 1YoE I did most of that in about 3 months. Had a deadline of 6 months to get something functional to demonstrate the proposed new direction of the company, and I did just that. If I were to do it today I could probably rush it to a week, but that would mean no progress on the backend development that I was doing in parallel. A day is probably doable with more on-rails/ batteries included approaches. Not because…

The problem is never spinning things up, it's in maintenance and ops. K8s brings tons of complexity. I wouldn't use it without thinking very carefully for anything other than a very complex startup while you're finding product-market fit.

Re: Kubernetes is a red flag signalling premature optimisation

#356

Post by ohgodplsno » Mon, Jul 04, 2022, 2:36 PM UTC

dj_brown_sugar wrote: post #309

gls2ro wrote: post #236

Earlier quoted context omitted.

What is a huge company? Here is an example of a team that is doing great work in mobile, frontend and backend: 3 people doing native iOS, 2 people doing native Android, 3 backend engineers, 1 frontend and 1 QA. Two engineering managers/team leaders: one for mobile and one for web. Of course this is one single product offering native mobile apps and some limited web app functionalities. The apps are great, smooth, nic…

But you could also have 2 people working on React Native and have 1 person each for getting it to play nice with iOS/Android, and eliminate the need for an extra engineer.

And end up with a subpar product because of your decision to use terrible tech that can't hold 60 FPS while scrolling a list

Re: Kubernetes is a red flag signalling premature optimisation

#357

Post by mountainriver » Mon, Jul 04, 2022, 2:42 PM UTC

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…

We’ll see if octopus deploy is around in 10 years

Re: Kubernetes is a red flag signalling premature optimisation

#358

Post by javajosh » Mon, Jul 04, 2022, 2:42 PM UTC

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.

What's your plan when (not if) Google deprecates GAE?

Re: Kubernetes is a red flag signalling premature optimisation

#359

Post by dasil003 » Mon, Jul 04, 2022, 2:45 PM UTC

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…

> Either you don't succeed, in which case it doesn't matter what your stack was, or you do, in which case you'll be glad that you can scale up easily

This take brushes right past the causes of success and failure. Early stage success depends on relentless focus on the right things. There will be 1000 things you could do for every 1 that you should do. Early on this is going to tend to be product-market fit stuff. If things are going very well then scalability could become a concern, but it would be a huge red flag for me as an investor if an early stage company was focusing on multi-cloud.

Re: Kubernetes is a red flag signalling premature optimisation

#360

Post by CRConrad » Mon, Jul 04, 2022, 2:45 PM UTC

jsiepkes wrote: post #61

Izkata wrote: post #54

Earlier quoted context omitted.

The impression I've gotten from some of my co-workers is that in bootcamps and college they only learned one language, remember the time and effort that went into that, and assume learning another language will take the same time and effort. Because they haven't really put effort into a second one, they don't yet realize just how much conceptually transfers between the languages.

While concepts transfer over between languages the language is only 10% of it. The rest of it is the standard library, ecosystem, buildsystem and all kinds of intricacies you have to know about and what not which is specific to the language (ecosystem).

> ...the standard library, ecosystem, buildsystem and all kinds of intricacies you have to know about and what not which is specific to the language (ecosystem)

IME a lot of the conceptual stuff transfers pretty well there too.