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

251–260 of 558 posts

Re: Kubernetes is a red flag signalling premature optimisation

#251

Post by jpgvm »

iasay wrote: post #206
Noughmad wrote: post #201

I really don't understand all these complaints about how Kubernetes is so complex, how it's an investment etc. I am a single developer that uses Kubernetes for two separate projects, and in both cases it has been a breeze. Each service gets a YAML file (with the Deployment and Service together), then add an Ingress and a ConfigMap. That's all. It's good practice so still have a managed DB, so the choice of Kubernetes…

It’s really complicated when something goes wrong. That is my only criticism. Particularly in the various CNI layers out there. You really have to know exactly how everything works to get through those days and that is beyond the average person who can create a docker container and push it into the cluster which is the usual success metric.

99% of people aren't going to use a different CNI plugin to what their managed distribution ships with. Same goes for peeking under the covers of storage plugins, kubelet config, etc.

You pay AWS/GCP for that these days and just use the API.

Re: Kubernetes is a red flag signalling premature optimisation

#252

Post by pjmlp »

snorremd wrote: post #211
waffles2021 wrote: post #77

Earlier quoted context omitted.

There is also an issue with conceptual leakage, most noticeably I've found with devs well versed in one language bending another language into behaving like the former.

Agreed. You see this a lot with people with a C# and/or Java background using TypeScript with annotation based decorators and libraries/frameworks that implement dependency injection, etc. They don't really embrace the nature of the new language and ecosystem. And I can sympathise, it is simpler to do things as you have been doing them before. You also see it when people who've mostly done imperative programming trie…

Well, that is the reason why outside HN bubble, Angular still wins the hearts of most enterprise consulting shops, as its quite close to JEE/Spring and ASP.NET concepts.

Re: Kubernetes is a red flag signalling premature optimisation

#253

Post by lr4444lr »

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…

That isn't the point. If he had a whole year, was there a tangibly better use of his time to get a product to market faster? What might the business implications be for doing or not doing so?

Re: Kubernetes is a red flag signalling premature optimisation

#254

Post by dinkleberg »

ramraj07 wrote: post #86
xyzzy123 wrote: post #6

Earlier quoted context omitted.

Doesn't it depend what staff you have? I would have agreed with this in 2018 but the world has moved on. If you have a bunch of people who know it, you can deploy a cluster into gcloud or aws with a few clicks or lines of IaC. Would I recommend a startup team learn kube while trying to ship a product? No. Would I think it's a red flag if a team who already know it choose it as their preferred platform? Also no.

Even if they know it, unless they absolutely need to implement it, why would you waste such valuable resources on of all things infra? (Unless your product IS infra). No engineer I know who’s smart enough to effortlessly deploy k8s on their own would want to do that as the job. There’s a million other interesting things (hopefully?) that they can be doing.

Not at all. If you know Kubernetes well and your needs are fairly simple it takes no time at all.

On a project a couple of years ago my cofounder and I opted to use Kubernetes after running into constant frustration after following the advice to keep it as simple as possible and just use VMs.

Kubernetes makes many complicated things very easy and lets you stop worrying about your infra (provided you’re using a managed provider).

On our next project we used a PaaS offering because we had a bunch of credits for it and it was painful in comparison to what we had with Kubernetes. It was way more expensive (if we didn’t have credits), the deployments were slow, and we had less flexibility.

Kubernetes isn’t perfect, far from it. But for those who know it well it is usually a good option.

Re: Kubernetes is a red flag signalling premature optimisation

#255

Post by jrimbault »

lima wrote: post #213
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…

You have this with literally every deployment mechanism, except with Kubernetes the boundary is standardized and you can easily find/hire/teach new team members to work on the complicated parts. Custom VM/cloud/$randomSaaS deployments are much worse when it comes to "the one guy who understands the intricate details is on vacation".

At some point, this becomes the dividing line between a "nu-ops" team and the dev team.

Re: Kubernetes is a red flag signalling premature optimisation

#256

Post by iasay »

jpgvm wrote: post #251
iasay wrote: post #206

Earlier quoted context omitted.

It’s really complicated when something goes wrong. That is my only criticism. Particularly in the various CNI layers out there. You really have to know exactly how everything works to get through those days and that is beyond the average person who can create a docker container and push it into the cluster which is the usual success metric.

99% of people aren't going to use a different CNI plugin to what their managed distribution ships with. Same goes for peeking under the covers of storage plugins, kubelet config, etc. You pay AWS/GCP for that these days and just use the API.

It was AWS who had trouble fixing our CNI issues…

Re: Kubernetes is a red flag signalling premature optimisation

#257

Post by KaiserPro »

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

Its a pain in the arse, and you're on the hook for looking after it.

I'm captain infra, so when Managed DBs came along, I felt threatened. But then when I used it, I realised that, yes, they are expensive, but I don't have to fucking worry about them. One touch deploy, proper backups are an option away, as is proper role based auth. K8s is like having a DB admin. Everything revolves around them, and it can be limiting, unless you have a specific use case.

K8s is useful for a specific role, but for most people who've outgrown a single machine/bunch of machines, ECS is good enough. Yes, there are fancy things you can't natively do, but you probably shouldn't do those just yet anyway.

Where K8s comes in useful is probably limited to:

1) mixture of real steel and cloud

2) A cluster shared with a large number of team, each deploying services that rely on other people's stuff

I've been managing clusters in one for or another for many years. K8s is certainly better than swarm, but its really not that great as a general purpose "Datacentre OS".

in short, K8s is your generation's XML.

Re: Kubernetes is a red flag signalling premature optimisation

#258

Post by pjmlp »

szundi wrote: post #124
biztos wrote: post #52

Earlier quoted context omitted.

And isn’t Wasm supposed to (some day) free us from the need to pick JS for the front end?

I am waiting to be able to run the JVM and have client side swing again in WASM

Why waiting when it is already available?

Re: Kubernetes is a red flag signalling premature optimisation

#259

Post by criley2 »

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…

>That's seems like a very negative take in my opinion. This 'simpler operational tech' would still need to be able to scale, correct?

Premature optimization is a top problem in startup engineering. You have no idea what your startup will scale to.

If you have 1,000 users today and 5 year goal of 2,000,000 users, then spending a year building infrastructure that can scale to 100,000,000 is an atrociously terrible idea. A good principal can setup a working git hook, circleci integration, etc capable of automated integration testing and rather close to ci/cd in about a weekend. Like you can go from an empty repo to serving a web app as a startup in a matter of days. A whole year is just wasteful insanity for a startup.

The reality for start-ups running on investor money with very specific plans full of OKRs and sales targets is very different: you need to be building product as fast as possible and not giving any fuck about scale. Your business may pivot 5 times before you get to a million users. Your product may be completely different and green-fielded two times before you hit a million users.

I can't imagine any investor being ok with wasting a quarter of a million+ and a year+ on a principal engineer derping around with k8s while the product stagnated and sales had nothing to drive business -- about as useful as burning money in a pit.

You hire that person in the scale-up phase during like the third greenfield to take you from the poorly-performing 2,000,000 user 'grew-out-of-it' stack to that 100,000,000+ stack, and at that point, you are probably hiring a talented devops team and they do it MUCH faster than a year

Re: Kubernetes is a red flag signalling premature optimisation

#260

Post by okamiueru »

KptMarchewa wrote: post #222
okamiueru wrote: post #210

Earlier quoted context omitted.

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.

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.
Post reply on HN