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

141–150 of 558 posts

Re: Kubernetes is a red flag signalling premature optimisation

#141

Post by angio »

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…

In my latest project I skipped the managed database and started using a postgres operator. So far the dev experience and performance is good.

Re: Kubernetes is a red flag signalling premature optimisation

#142

Post by regularfry »

discordianfish wrote: post #137

I feel like most of these rants come from people who never built the alternative to kubernetes to support a modern workflow (CI/CD with branch deploys, monitoring, access control etc). I love kubernetes because I don't need to build bespoken platforms at every company I join. I probably would have switched careers by now if I still had to deal with site specific tooling that all essentially implement a worst version…

Except that he's not arguing to build the alternative to k8s. He's arguing to buy a higher-level abstraction.

Re: Kubernetes is a red flag signalling premature optimisation

#143

Post by politelemon »

almostdigital wrote: post #139

I can't recommend docker swarm enough, it does 95% of what you need in k8s without requiring someone full-time just to manage it.

Agreed, it's a shame that k8s won the mindshare, and other solutions don't get a second glance. Swarm will do most of what you need, and can help avoid the premature optimisation trap. Going from Swarm to Fargate or K8S is a small step on a journey.

Re: Kubernetes is a red flag signalling premature optimisation

#144

Post by ratww »

jalk wrote: post #125
ratww wrote: post #97

Earlier quoted context omitted.

Most developers don't seem to want to learn more than "one" thing. Once they do one tutorial, it seems they're done for life with learning. And they don't really have time to learn new stuff, as they spend too much of their time on Hacker News complaining there's too many new frontend frameworks or something like that.

I have never met such a developer - most devs I have met, are way more eager to learn the next shiny thing than just getting the job done.

I know a lot of them, it's easy to identify as they constantly complain about shiny things.

Re: Kubernetes is a red flag signalling premature optimisation

#145

Post by alpaca128 »

varispeed wrote: post #66
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…

> It would rather be a waste of resources, money and energy not to use an high-performance language for high-performance applications. Given that probably most developers support the push to tackle the climate change, they seem to be making no effort to ensure their apps execute in as short time as possible using as little resources as possible. You would expect that people would actually embrace doing things in C or…

Just like with code optimization we should first make sure making code run slightly more efficient really has an impact on the climate. Because I very much doubt it does.

When you want to save the climate there are many, many low-hanging fruits. The choice of programming language is likely not one of them, as much as I like efficient code.

Re: Kubernetes is a red flag signalling premature optimisation

#146

Post by AtNightWeCode »

The same language argument is plain wrong. It is easier to change between languages within the same domain than to swap domains using the same language. If you done web services programming with NodeJS you can easily switch to GO. Starting with React will be much harder.

Re: Kubernetes is a red flag signalling premature optimisation

#147

Post by grumpy-de-sre »

angio wrote: post #141
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…

In my latest project I skipped the managed database and started using a postgres operator. So far the dev experience and performance is good.

The PostgreSQL operators are definitely usable, pretty much none of their limitations are going to hit you on an MVP. I think a lot of the FUD about "don't run databases on kubernetes" came from a time before we had statefulsets and persistent volumes.

Which operator did you go with out of curiousity?

Re: Kubernetes is a red flag signalling premature optimisation

#148

Post by regularfry »

gjulianm wrote: post #85
moreira wrote: post #8

Earlier quoted context omitted.

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?

The question is how much you need to know. You need much less knowledge to run something in Heroku than in k8s; dramatically less in the "onboard a CRUD app" case. I'd argue that running k8s effectively is no less knowledge-intensive than running VMs.

Re: Kubernetes is a red flag signalling premature optimisation

#150

Post by grumpy-de-sre »

isbvhodnvemrwvn wrote: post #135
Chilinot wrote: post #126

Earlier quoted context omitted.

For deployments using Argo, yea that's pretty much it. You can set it to automatically deploy to your target environment as soon as it detects changes to your k8s mainfests, or you can require a manual "approve" step which is a push of a button for configs that are out of sync with what is applied to k8s. For rollbacks, you have a button in argo that lists previous deployments and you can just choose which previous d…

Can it run smoke and acceptance tests? Or does it require calling external services?

For automated testing the argo-workflows project is amazing and worth looking into.

I think when you look at the entire argo suite you start seeing something that could really disrupt the way we use products like gitlab, particularly for startups.

Post reply on HN