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

Re: Kubernetes is a red flag signalling premature optimisation

#441

Post by Dan_Sylveste » Mon, Jul 04, 2022, 5:25 PM UTC

K0SM0S wrote: post #431

Dan_Sylveste wrote: post #378

Earlier quoted context omitted.

>infra like k8s even under-the-hood for intermediaries (like web agencies) is still not always the norm That's because 'the norm' for web agencies is a site that does basically zero traffic. If a company hires a 'web agency' that's by definition because the company's business model does not revolve around either a web property or app. Whether that's a gas station company or a charity or whatever, the website is not k…

I very much agree with you. I must have been unnecessarily critical in my initial comment, I did not mean it as a rant, more like an observation about where-we're-at towards what seems an inevitable conclusion to me. Sorry that came out wrong, clearly I got carried away. In asking if "Kubernetes is a red flag signalling premature optimisation", you correctly explain why we're yet on the "yes" side for the typical web…

>My unspoken contention was that eventually, we move to a world where k8s-like infra is the de facto norm for 99% of infrastructure out there, and on that road we move to the "no" side of the initial question for e.g. web agencies (meaning, we've moved one notch comparable to the move from old-school SysAdmin to DevOps maybe, you know those 10 years circa 2007-2018 or so).

This is very very hard to parse BTW. I don't want to reply to what you've written because I can't determine for sure what it is that you're saying.

Re: Kubernetes is a red flag signalling premature optimisation

#442

Post by marcosdumay » Mon, Jul 04, 2022, 5:27 PM UTC

maverwa wrote: post #42

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.

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…

> which is a fair point

It's a very effective way to make sure your team is only composed by junior developers.

Re: Kubernetes is a red flag signalling premature optimisation

#443

Post by ezekiel11 » Mon, Jul 04, 2022, 5:27 PM UTC

likortera wrote: post #198

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…

> I started out with Iaas namely Google App Engine and we suffered a ton with huge bills especially from our managed db instance Are you factoring in the salaries of the people setting up Kubernetes? And the cost of those people/salaries not working on the actual product? And the cost of those people leaving the company and leaving a ton of custom infrastructure code behind that the team can't quickly get up to speed…

If setting up a PostgreSQL behind VPC with an EC2 in front of it was too difficult, there is now a serverless database product from AWS that costs 90% less what it used to.

No more load balancers, no more VMs, no more scaling up or down to match demands.

Re: Kubernetes is a red flag signalling premature optimisation

#444

Post by zinclozenge » Mon, Jul 04, 2022, 5:28 PM UTC

moomoo11 wrote: post #390

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…

Please don’t do this. I’m dealing with the mess caused by following this line of thinking. One guy (okay it was two guys) set up all the infrastructure and as soon as it was working bounced to new jobs with their newfound experience. The result is that dozens of engineers have no idea what the heck is going on and are lost navigating the numerous repos that hold various information related to deploying your feature.…

The mistake people make thinking about Kubernetes is that it's about scale, when really it's just a provider for common utility, with a common interface, that you need anyway. You still need to ingress traffic, you still need to deploy your services, etc.

Re: Kubernetes is a red flag signalling premature optimisation

#445

Post by hotpotamus » Mon, Jul 04, 2022, 5:29 PM UTC

Spooky23 wrote: post #424

hotpotamus wrote: post #417

Earlier quoted context omitted.

So question then - is it possible to found a tech startup without paying rent to a FAANG? Before I get the answer that anything is possible, I should say is it feasible or advisable to start a company without paying rent to the big guys?

Who would you prefer to pay rent to? The reality is unless you’re some rich dude who can borrow dad’s datacenter (And that’s cool if so), you’re either going to be renting colo space, virtual servers, etc. It’s always a challenge in business to avoid the trap of spending dollars to save pennies. IMO, you’re better off working in AWS/GCP/Azure and engineering around the strengths of those platforms. That’s all about t…

> Who would you prefer to pay rent to?

I'm aware that no man is an island in some sense, but I'm not comfortable with locking myself into one of 3 companies who need to increase their revenue by double digits year over year. And as you say, a lift and shift is basically setting money on fire. Currently I run sort of a hybrid approach with a small IaaS provider and a colo. It seems to work well for us both technically and financially though that seems to go contrary to what is considered conventional wisdom these days.

Re: Kubernetes is a red flag signalling premature optimisation

#446

Post by rfoo » Mon, Jul 04, 2022, 5:30 PM UTC

musingsole wrote: post #338

huffmsa wrote: post #277

Earlier quoted context omitted.

Just like how you don't really expect later devs to learn the intricacies of your hand rolled deployment setup. The difference is, kubernetes is pretty standardized and therefore learnable in a repeatable way, unlike the Frankenstein of tooling you might otherwise cobble together.

> kubernetes is pretty standardized Sure. Though the standard changes weekly.

My favorite Kubernetes joke can be told in one word:

v1alpha1

Re: Kubernetes is a red flag signalling premature optimisation

#447

Post by jakupovic » Mon, Jul 04, 2022, 5:32 PM UTC

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…

>Doesn't look like the author knows what he is talking about.

This was my first thought, and I was to comment so, but saw you already did. The only reason we see this comment is because HN has an irrational hate of K8s, for us that do run things in production at scale, k8s is the best option. The rest is either wrapped in licenses or lacks basic functionality.

Re: Kubernetes is a red flag signalling premature optimisation

#448

Post by bg24 » Mon, Jul 04, 2022, 5:32 PM UTC

The author has given 1 specific example:

  "Another time our Data Science team told us that they needed an orchestration tool for their data pipelines. I steered the selection process towards Argo Workflows (which runs inside Kubernetes) instead of Prefect (a SaaS offering), which they already used for a PoC. There were all sorts of justifications in my head for this decision. Unfortunately, they were all based on premature optimisations. In the end, our team needed to build a new set of Terraform and Helm charts to automate the deployment of Argo Workflows and integrate it into our SSO etc. I regret this decision. I think we lost weeks or even months shipping something to end-users because of this decision. Premature optimisation!"

There is absolutely NO issue in adopting kubernetes, and then using SAAS for everything possible. In the above case, if you had a data pipeline proficient engineer in the team, you would not spend months to set up one. It comes down to making decisions based on your current situation (business urgency, team skills, future plans).

Re: Kubernetes is a red flag signalling premature optimisation

#449

Post by zinclozenge » Mon, Jul 04, 2022, 5:33 PM UTC

steveBK123 wrote: post #382

mixedCase wrote: post #373

I'm getting tired of the "You don't actually need Kubernetes while starting out!" crowd, despite being part of it. Of course you don't. Of course if you don't know Kubernetes, learning it as you try to get a company going on a minimum headcount is not the most efficient approach. But for pete's sakes man, if you have used K8s before, know what you're doing and you're running on cloud, just shove a couple off-the-shel…

I think it still bears repeating.. I've seen projects fail or take 10x as long due to choosing to go with k8s day 1 instead of starting with even a basic VM. It may be easy enough to get k8s itself setup. However, without an in-house expert sat within the dev team, all the access/permissions to resources to/from the cluster were hell. NFS disk Read/Write, S3 Read/Write/List, RDS DB access, Kafka access, corp network…

Don't you have to do all of this stuff even if you're not running k8s? Or are you complaining about a re-write/replacement of something that didn't need to be?

Re: Kubernetes is a red flag signalling premature optimisation

#450

Post by marcosdumay » Mon, Jul 04, 2022, 5:36 PM UTC

biztos wrote: post #52

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…

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

I have been very successful in replacing a JS browser application with Rust. It has been great, because Rust is much easier to change, and since the application is complex, I need to change it a lot.

But I wouldn't recommend it in general, because JS (and for slightly more complex things, TS) is much easier to create because of all the old Rust features that surface every time you mention it. And most GUI code is simple enough that you only have to write once, maybe fix a few details, and forget about it.

Wasm would be much more compelling if it was target by higher level languages.