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

Re: Kubernetes is a red flag signalling premature optimisation

#81

Post by jhoelzel » Mon, Jul 04, 2022, 9:10 AM UTC

Guys Kubernetes is a container platform for multiple nodes. I know it seems hard to understand from the outside, but its really not. You would naturally come up with ALL the same componets if you were to take your container strategy onto multiple computers.

What if you dont need multiple servers? Well go the single node approach and have a flexible, true and tested way to spin up containers, which can and should be able to crash whenever they have to.

Using Containers is pre mature optimization too? maybe I should get my typewriter.

Re: Kubernetes is a red flag signalling premature optimisation

#82

Post by rahen » Mon, Jul 04, 2022, 9:11 AM UTC

lmm wrote: post #47

nicoburns wrote: post #41

Earlier quoted context omitted.

That assumes it’s harder to build it in the other language though. Maybe if that language is C then that will the case, but building in say Go may be just as easy as building in JavaScript (or close enough that it doesn’t really matter), whereas rewriting it later would be a massive undertaking. This I very different to say starting a with a micro service architecture which imposes relatively high overheads, with lit…

> That assumes it’s harder to build it in the other language though. Maybe if that language is C then that will the case, but building in say Go may be just as easy as building in JavaScript (or close enough that it doesn’t really matter) The cases where Go is significantly faster than JavaScript are vanishingly small. > whereas rewriting it later would be a massive undertaking. This is vastly overstated IME. Porting…

> The cases where Go is significantly faster than JavaScript are vanishingly small.

It's not only about performance but also energy and resource efficiency.

Re: Kubernetes is a red flag signalling premature optimisation

#83

Post by jrumbut » Mon, Jul 04, 2022, 9:11 AM UTC

davnicwil wrote: post #25

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…

How do you know what the performance will be in what language or needs to be, in numerical terms, before you are running the system in practice?

For a lot of applications there are pretty straightforward calculations to meet a desired frame rate.

Also I've seen UX research that established some guidelines for how long something can take while still feeling responsive allowing a user to remain focused.

Knowing you can achieve the required/desired performance in any given language is mostly a matter of experience solving similar problems.

Re: Kubernetes is a red flag signalling premature optimisation

#84

Post by pritambarhate » Mon, Jul 04, 2022, 9:11 AM UTC

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 a technology which is best suited for the product your are trying to build. For example, if you are building a managed cloud service, then building on top of K8S, or FireCracker or Nomad can be a good choice. But then it means you need to learn the tech being used inside out.

Also he talks about all of this and then gives example of WhatsApp at the end. WhatsApp chose Erlang for the backend and their front end was written in Java and Objective-C. They could have chosen Java for backend to keep frontend language same but they didn't. They used Erlang because they based their architecture on Ejabberd which was open source and was built with Erlang. Also WhatsApp managed all their servers by themselves and didn't even move to managed cloud services when they became available. They were self hosting till FB acquired them and moved them to FB data centres later on (Source: http://highscalability.com/blog/2014/2/26/the-whatsapp-archi...).

Re: Kubernetes is a red flag signalling premature optimisation

#85

Post by gjulianm » Mon, Jul 04, 2022, 9:12 AM UTC

moreira wrote: post #8

mattbillenstein wrote: post #3

In the limit, there are some startups that could run production on a single Linux host - I recently helped one get off Heroku and their spend went from ~$1k/mo to ~$50/mo and it made debugging and figuring out performance issues so much easier than what they were doing previously...

I'm very much with you on this, but I do understand that it's one of those things that is just not feasible when your team has no sysadmin/devops experience. You were able to do it, but what happens to them when you're not around? Does their team have the required experience to handle it? That's the difference in cost. It's like DYI - yes, if I have all the skills and experience I can do everything myself incredibly…

> I'm very much with you on this, but I do understand that it's one of those things that is just not feasible when your team has no sysadmin/devops experience.

But this applies to everything. You also need Heroku or Kubernetes or whatever experience to maintain those systems, right?

Re: Kubernetes is a red flag signalling premature optimisation

#86

Post by ramraj07 » Mon, Jul 04, 2022, 9:12 AM UTC

xyzzy123 wrote: post #6

tenfourty wrote: post #2

[OP here] It feels bizarre saying this, having spent so much of my life advocating for and selling a distribution of Kubernetes and consulting services to help folks get the most of out it, but here goes! YOU probably shouldn't use Kubernetes and a bunch of other "cool" things for your product. Most folks building software at startups and scale-ups should avoid Kubernetes and other premature optimisations. If your co…

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.

Re: Kubernetes is a red flag signalling premature optimisation

#87

Post by waffles2021 » Mon, Jul 04, 2022, 9:12 AM UTC

The most starry of starry eyed startups will want a team that is already fit for scale, so they build for scale before they need it. Possibly convinced by VC behaviour and getting as much from each funding round as possible. If you have to scrap your 1st round team and re-employ for 2nd at scale its going to be a hard sell.

Re: Kubernetes is a red flag signalling premature optimisation

#88

Post by ramraj07 » Mon, Jul 04, 2022, 9:15 AM UTC

jpgvm wrote: post #80

gjulianm wrote: post #65

Earlier quoted context omitted.

From what I've seen with Kubernetes, the problem is that in order to define the resources and links with a schema, it needs several abstractions and extra tooling. So you not only need to define the schema (which isn't that trivial) but also understand what Kubernetes does, how to work with it, and how to solve problems. It's a tool that adds complexity and difficulty, if you're not using the advantages it provides (…

This is a common misconception. k8s isn't about scale, multi-node or even reliability/resiliency. We had solutions for all of that before it came along. It's about having a standard API for deployment artifacts. The k8s manifests are trivial (if verbose) the complexity comes from running the underlying layer which when you are small you simply outsource to AWS or GCP. There is some k8s know-how that is table stakes f…

It would be great if otherwise smart people Also learn to know when what’s trivial to them is not trivial to the masses. K8s is not trivial, not to me at the least. I’m not some super duper engineer but I do alright? That’s all I can say at the least.

Re: Kubernetes is a red flag signalling premature optimisation

#89

Post by zo1 » Mon, Jul 04, 2022, 9:16 AM UTC

moreira wrote: post #8

mattbillenstein wrote: post #3

In the limit, there are some startups that could run production on a single Linux host - I recently helped one get off Heroku and their spend went from ~$1k/mo to ~$50/mo and it made debugging and figuring out performance issues so much easier than what they were doing previously...

I'm very much with you on this, but I do understand that it's one of those things that is just not feasible when your team has no sysadmin/devops experience. You were able to do it, but what happens to them when you're not around? Does their team have the required experience to handle it? That's the difference in cost. It's like DYI - yes, if I have all the skills and experience I can do everything myself incredibly…

I say it's over-rated. You don't need a huge amount of "sysadmin/devops", that's only now becoming a thing since we started calling it that. Before it used to be that backend devs just had intimate knowledge of how their service was running on a system, and most likely had to login and debug a multitude of issues with it. 99% of backend devs used to (maybe not so anymore now with "devops" et al) be more than capable of administering a system and keeping it chugging along as well as setting it up. It might not be 100% bulletproof or consistent or whatever, but more than enough for a company or service starting up.

We've lost that, and now everyone thinks we need "sysadmin/devops" for simple and moderately complicated deploys. Heck, most of the guides are out there, follow them. Also, ready-made images and docker containers are amazing these days with config built in. If you look-for or hire devops, you get K8s and all the "formal" items they'll bring with them. You don't need CI/CD for the first 6 months, just PoC the damn thing, get an MVP out and start getting users/customers, the rest will follow.

Re: Kubernetes is a red flag signalling premature optimisation

#90

Post by RapperWhoMadeIt » Mon, Jul 04, 2022, 9:16 AM 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…

I also thought WhatsApp is a bad example. They not only hosted themselves, but they used solely FreeBSD (as far as I know) in their servers. (which don't get me wrong, I find great as a FreeBSD sysadmin myself).