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

Re: Kubernetes is a red flag signalling premature optimisation

#301

Post by MaKey » Mon, Jul 04, 2022, 1:15 PM UTC

lebowen wrote: post #190

clubdorothe wrote: post #179

Earlier quoted context omitted.

Check into Amazon ECS or Google Cloud Run. It's basically a higher level of managed Kubernetes ( EKS or GKE ). You give your containers, and they take care of running it. Tim Hockin (one of kubernetes creator) support the idea to use something as much managed and automatic as possible : https://twitter.com/thockin/status/1539987108521054208

I'm aware of these products, but do not fit my use case. I need to run some services on premises and have set up a self hosted Kubernetes instance on a physical server in a rack. It could be overkill and maybe I could use something like Docker Swarm. Apart from this I am unsure what I can use that isn't K8s to orchestrate my containers on site.

Which features do you need that docker compose can't meet?

Re: Kubernetes is a red flag signalling premature optimisation

#302

Post by morelish » Mon, Jul 04, 2022, 1:16 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…

> I'll make these four lines of code a function in case I need to call it more than once later on - you know, what if that's needed?

The code example is not always right.

Beware, if you know it will be needed, you might as well make it a function now. Likewise if you think probably it will be needed, why not make it a function now?

It’s not a good review comment or rejection to say “yeah but I don’t want to do that because it’s not yet needed”. Sure, but what if you are just being lazy and you don’t appreciate what it should look like long term?

The “I don’t want to write a function yet not needed” is not a clear cut example.

Re: Kubernetes is a red flag signalling premature optimisation

#303

Post by spoiler » Mon, Jul 04, 2022, 1:18 PM UTC

I disagree.

There are a lot of valid reasons why a start-up might prefer Kubernetes to other solutions.

A simple and good enough reason is the need for variable compute:

You might need more computing sporadically (say for example you're doing software in the sports industry; your demand changes with the number and size of events, as well as on weekends).

Another reason might be a start up that allows their customers to execute some type of arbitrary code (eg a no-code product). This can vary from customer to customer, and it can also vary within the customers use cases.

Imagine having to manage all these storage, networking and compute resources manually... Or going full circle and managing it with a bunch of puppet/ansible/shell scripts. Now you slap some automated scale triggers on top that fires off these scripts.

Congratulations! We've built something that looks like Kubernetes; if we squint. There's some smoke coming out of it. Documentation? Lol, we don't have time for that. we are a company that gets shit done, we don't toy around with Shcubernetes and documentation! Error handling/monitoring/reporting? Eh, just read the code if something fails. Need to add cert issuance? Yeah let's implement our own ACME integration. Network ingress? Let's just have a 500line haproxy infront of an 2000line nginx config; no big deal. DNS? just append to named; who cares?

The name for the "we get shit done" crowd should probably be "we don't give a shit about anything and have others solve problems we created because of our lack of thinking and foresight", but it doesn't sound quite as memorable.

It's just people who are comfortable cutting corners at other people's expenses. When they have to own the shit they made, they start blaming others and leave the company.

Sorry for the rant.

Re: Kubernetes is a red flag signalling premature optimisation

#304

Post by wizofaus » Mon, Jul 04, 2022, 1:18 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…

"I think the most appropriate advice is to choose a stack which the founding team is most familiar with." I'd think that's exactly what typically happens most of the time. But the degree of stack-lockin that occurs with startups still surprises me even when it's clear a better choice might have been made. Mostly due to management not being prepared to grant the necessary rewrite time.

Re: Kubernetes is a red flag signalling premature optimisation

#305

Post by d23 » Mon, Jul 04, 2022, 1:19 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…

The truth is at scale the last thing you want is a nest of unmanaged complexity, so it’s also the wrong instinct there. It’s usually contact with the real world that dictates what needs the extra engineering effort, and trying to do it ahead of time just means you’ll sink time up front and in maintenance on things that didn’t turn out to be your problem.

Re: Kubernetes is a red flag signalling premature optimisation

#306

Post by noogle » Mon, Jul 04, 2022, 1:19 PM UTC

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…

> good and easier way to deploying 10-15 services

Why are so many micro-services needed? Could the software be deployed in a more concise manner?

Not getting into the whole monolith-vs-services arguments. In both cases, complexity of deployment is part of the cost of each option.

Re: Kubernetes is a red flag signalling premature optimisation

#307

Post by justinsb » Mon, Jul 04, 2022, 1:21 PM UTC

The problem with this sort of argument is that it sets up a straw-man, without describing what you should do instead. Kubernetes could be better - of course - but what better approach is the author recommending to use instead? It would be better if we could use one language on frontend and backend - of course - but what is this one language that works everywhere? It would be better - of course - if there was a SaaS that could do everything for us, is cheap and is open source - but what is that SaaS?

It's very easy to say something could be improved, but much harder to propose something to replace it that doesn't have its own shortcomings.

It's a pity because this article actually makes a good point, that we should think about what the actual user/business goal is before making technical decisions, and be careful lest we spend all our time on technology. I've heard this idea described as "innovation tokens". It's disappointing that the article chose to wrap this idea in clickbait, but I guess we wouldn't be talking about it otherwise!

Disclaimer: I have no end of personal biases in favor of kubernetes!

Re: Kubernetes is a red flag signalling premature optimisation

#308

Post by Beltalowda » Mon, Jul 04, 2022, 1:25 PM UTC

cpursley wrote: post #264

Beltalowda wrote: post #234

Earlier quoted context omitted.

I think a lot of people here have been doing this programming thing for so long we've forgotten we once had trouble understanding things like: x = 1 for i in [1, 2, 3] { x = i } What is the value of "x" at the end? Assuming block scope, it will be 1, or assuming it doesn't have block scope (or that it uses the already defined "x" in this pseudo-example) it will be 3. A lot of beginning programmers struggle with this…

Well, loops are not loops in functional languages...

I'm not saying there are zero differences or that $other_language never has any new concepts to learn, but in functional languages variables are still variables, functions are still functions, conditionals are still conditionals, etc. Important aspects differ, but the basics are still quite similar as is a large chunk of the required reasoning and thinking.

Re: Kubernetes is a red flag signalling premature optimisation

#309

Post by dj_brown_sugar » Mon, Jul 04, 2022, 1:26 PM UTC

gls2ro wrote: post #236

sofixa wrote: post #208

Earlier quoted context omitted.

> The Whole advice of using same language is especially silly - iOS is stuck with Swift, and the web is stuck with JS, and maybe you need an applitation that scales using actors across mutiple machines with Golang or Java, or maybe you need to plug into Windows tightly and need C# And you're also forgetting Android and macOS and Linux. That's why cross-platform frameworks like Electron and React Native are so popular…

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.

Re: Kubernetes is a red flag signalling premature optimisation

#310

Post by ryanbrunner » Mon, Jul 04, 2022, 1:27 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…

> But the next advice about not using a different language for frontend and backend is wrong.

Being charitable, what I think they are getting at is maybe more about having fully separated frontend and backend applications (since the front-end examples he gives are not languages but frameworks / libraries). Otherwise it seems really backwards - I'm definitely an advocate of not always needing SPA-type libraries, but using literally zero Javascript unless your backend is also JS seems like it goes to a too-far extreme.