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

221–230 of 558 posts

Re: Kubernetes is a red flag signalling premature optimisation

#221

Post by thathndude »

quickthrower2 wrote: post #185
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…

Kubernetes is the React of devops. You wont get fired for picking it. And there will be a tonne of support available online, as well as courses, and experienced people you can hire. Also there is cloud managed k8s which takes most of the pain out of it. And plenty of out the box stuff. It is not a bad choice if you want to do the ops yourself for some reason. If you don't then use a BaaS or PaaS, that might be easier…

This has always been my observation/thought as well. It’s “ no one ever got fired for picking IBM” all over again. Cute advertisement slogan, but it’s based on a true/real mentality, and a dangerous one at that (in terms of reaching potential and managing burn).

Re: Kubernetes is a red flag signalling premature optimisation

#222

Post by KptMarchewa »

okamiueru wrote: post #210
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

That's seems like a very negative take in my opinion. This 'simpler operational tech' would still need to be able to scale, correct? If you think that there is a good and easier way to deploying 10-15 services, all of which can scale, and all of it defined in rather neat code, to be anything but "simple operational tech", then I believe you are confusing "solving a complex problem", with "simplifying the requirements…

>This 'simpler operational tech' would still need to be able to scale, correct?

Only if "scaling" is the problem that your startup is solving.

Re: Kubernetes is a red flag signalling premature optimisation

#223

Post by onion2k »

nightpool wrote: post #212
onion2k wrote: post #32

Earlier quoted context omitted.

You were able to do it, but what happens to them when you're not around? This is why you pay someone. Saving $950/month means it's well worth spending $500 for a day of someone's time occasionally. You don't have to do everything internally when you run a startup. Buying in services that you only need occasionally is well worth the money.

Are there contractors out there that will take on call shifts? Because it seems unlikely, and if your proposal is "put into a production a system that you will have to spend $500/day every time it goes down and wait 2-4 business days for a resolution" then you're a braver person than I am.

Obviously not. You don't pay someone to just set it up. You pay to help do what you'd do if you had a dedicated devOps teams. You pay someone to set up the system with your team so they understand it, train your team to use it, write some documentation about it, script a rollback procedure, maybe help on developing playbooks, etc.

Besides, there are people out there who offer on-call services for a small retainer.

Re: Kubernetes is a red flag signalling premature optimisation

#224

Post by afiori »

andybak wrote: post #189
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…

> Kubernetes is actually pretty great for the vast majority of use-cases. From my brief glances at it, it seems like a great solution for very complex use-cases. But "vast majority"? The cost-benefit seems way off unless you have a very different sense of "typical use-cases" to me. Most people are building simple web sites and apps that run on a single server, surely?

> Most people are building simple web sites and apps that run on a single server, surely?

I believe so, which makes a comparison between k3s and docker-compose very interesting.

Re: Kubernetes is a red flag signalling premature optimisation

#225

Post by K0SM0S »

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…

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

Re: Kubernetes is a red flag signalling premature optimisation

#226

Post by philliphaydon »

lbriner wrote: post #194
tr33house wrote: post #180

As a startup founder that's not VC funded, I would totally recommend you look into building with kubernetes from the get go. 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. Knowing that rollouts won't bring down prod and that they can be tested in different…

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 setup a new Octopus Deploy quickly, it would be like you setting up something in AKS. We are both good at the tools we know. But saying my way or your way is wrong - is the thing thats wrong.

Re: Kubernetes is a red flag signalling premature optimisation

#227

Post by wahnfrieden »

okamiueru wrote: post #210
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

That's seems like a very negative take in my opinion. This 'simpler operational tech' would still need to be able to scale, correct? If you think that there is a good and easier way to deploying 10-15 services, all of which can scale, and all of it defined in rather neat code, to be anything but "simple operational tech", then I believe you are confusing "solving a complex problem", with "simplifying the requirements…

for example lambda (not microservices, running mini monoliths per lambda function)

yes by simple I mean covering high availability requirements, continuous deployment, good DORA measures - not simple as in half-baked non-functional operations (such as manually sshing to a server to deploy)

Re: Kubernetes is a red flag signalling premature optimisation

#228

Post by K0SM0S »

jhugo wrote: post #187
gjulianm wrote: post #170

Earlier quoted context omitted.

I think the set of cases where "we need to scale up rapidly if it succeeds" and "Kubernetes solves all of our scaling needs and we aren't going to have problems with other components" is almost empty. On the other hand, there are quite a lot of startups that fail because they put too much focus on the infrastructure and Kubernetes and the future and too little on the actual product for the users. Which is the point o…

> I think the set of cases where "we need to scale up rapidly if it succeeds" and "Kubernetes solves all of our scaling needs and we aren't going to have problems with other components" is almost empty. I agree, but so what? K8s isn't magic, it won't make all your problems go away, but if you have people who are genuinely skilled with it, it solves a lot of problems and generally makes scaling (especially if you need…

Meanwhile, random_pop_non-tech_website exploding in traffic wasn't setup to scale despite years actively seeking said popularity through virtually any means and spending top dollar on hosting, and it slows down to crawl.

"Why no k8s?", you ask, only to be met with incredulity: "We don't have those skills", says the profiteering web agency. Sure, k8s is hard… Not. Nevermind that it's pretty much the only important part of your job as of 2022.

Re: Kubernetes is a red flag signalling premature optimisation

#229

Post by mattlondon »

cryptonym wrote: post #60
pjmlp wrote: post #20

Earlier quoted context omitted.

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.

That's sad, JavaScript was already not great for front-end and we now get it in backend and even the edge. Most job offers are for a mythical full-stack developper that'll master web design, CSS/HTML, front-end interactions and code, networking, back-end architectures, security,... You end-up with people who don't have time to get enough expertise and write and build clean stuff. Hacking poor JavaScript code everywhe…

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.

Re: Kubernetes is a red flag signalling premature optimisation

#230

Post by philliphaydon »

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…

If you are building a SaaS company and build your site in RoR, but also have experience in say Go, and decide 'hmm instead of using RoR ill use Go for this backend thing so its faster'

That's fine.

Premature optimization would be saying:

I don't know Go/C++/C... but I know its fast, so instead of using what I know to get up and running quickly, i'll waste time building it in something I don't know which probably wont be as fast as doing it in something I know well.

The thing is, when you're building it, no one is using it! If it's slower in RoR than Go, who cares, get it up and running, and fix it later when people are actually using it.

Post reply on HN