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

Re: Kubernetes is a red flag signalling premature optimisation

#11

Post by k8sToGo » Mon, Jul 04, 2022, 8:22 AM UTC

mschuster91 wrote: post #5

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…

Running a self-hosted Kubernetes is indeed ... questionable, but a managed Kubernetes? That's a pretty sane thing to do IMO. The alternatives are running your Docker containers either manually on some EC2 or other bare-metal server which is a nightmare to do deployments, or using something like Elastic Beanstalk which is even worse. For me at least, Kubernetes has become something like an universal standard: if you'r…

A managed cluster is not as much managed as you would think. Still have to configure and install a lot of things yourself.

Re: Kubernetes is a red flag signalling premature optimisation

#12

Post by te_chris » Mon, Jul 04, 2022, 8:23 AM UTC

k8s can be easy to set up, and if you know how to use it then you should. You shouldn't go to the trouble of learning it, but if you do know it already, then there is no reason not to go with services like gke autopilot.

Re: Kubernetes is a red flag signalling premature optimisation

#13

Post by k8sToGo » Mon, Jul 04, 2022, 8:24 AM UTC

WatchDog wrote: post #10

ocius wrote: post #7

Our startup has a webapp that acts as a UI for a machine learning application. We have two different types of heavy workloads (ML and something else). The workers for these run on Kubernetes, which makes them easy to scale (which we do a lot, automatically). The app itself doesn't run on Kubernetes yet (simple VM). It would be better if it did, though! We keep building a lot of functionality ourselves (e.g. deploymen…

What is it giving you over an ec2 auto scaling group or ECS/Fargate? Both can scale as much as you like, your config can live as cdk/cloudformation/terraform code?

Being independent of AWS stuff. Kubernetes community is much larger than ECS/Fargate, so many things already have been solved by others.

Also something like karpenter.sh is much nicer than ec2 autoscaling group.

Re: Kubernetes is a red flag signalling premature optimisation

#14

Post by sorry_outta_gas » Mon, Jul 04, 2022, 8:26 AM UTC

I don't use it much right now but I've found kubernetes (at least the managed service variety) fairly staright forward compared to some of the altearntives

it beats the pants off the the random rubricks of ansible and puppet projects I've run into the past anyway

Re: Kubernetes is a red flag signalling premature optimisation

#15

Post by moomin » Mon, Jul 04, 2022, 8:28 AM UTC

I feel like this is probably good advice for startups and AWS-using companies. But there remains a lot of us who have, for many reasons, some good, some bad, a lot of investment in physical infrastructure already. For those, the Hashicorp or Kubernetes stack makes a lot of sense, if only to help standardise the insanity of what you’re running in-house.

Re: Kubernetes is a red flag signalling premature optimisation

#16

Post by Dave3of5 » Mon, Jul 04, 2022, 8:28 AM UTC

Sort of agree. There are caveats of course but I tend to think if you can just start with a bunch of manually setup instances and roll from there. If you find yourself spending hours per day starting up and shutting down instances manually then yes, automate that part.

Nothing I've ever done has taken off at all so automating DevOps would have been a total waste of time. Then again the projects themselves have been a complete waste of time.

Re: Kubernetes is a red flag signalling premature optimisation

#17

Post by ale42 » Mon, Jul 04, 2022, 8:29 AM UTC

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 applications. Of course using the same language for the front-end might make no sense at all.

Re: Kubernetes is a red flag signalling premature optimisation

#18

Post by dj_mc_merlin » Mon, Jul 04, 2022, 8:29 AM UTC

k8sToGo wrote: post #11

mschuster91 wrote: post #5

Earlier quoted context omitted.

Running a self-hosted Kubernetes is indeed ... questionable, but a managed Kubernetes? That's a pretty sane thing to do IMO. The alternatives are running your Docker containers either manually on some EC2 or other bare-metal server which is a nightmare to do deployments, or using something like Elastic Beanstalk which is even worse. For me at least, Kubernetes has become something like an universal standard: if you'r…

A managed cluster is not as much managed as you would think. Still have to configure and install a lot of things yourself.

Of course, managed means you don't take care of say, creating your own X.509 CA and issuing certificates, tending to their expiry, installing Tiller, setting up pod networking etc. etc.

All of these much more annoying and harder than `helm update --install`ing some charts to your own cluster.

Re: Kubernetes is a red flag signalling premature optimisation

#19

Post by carom » Mon, Jul 04, 2022, 8:30 AM UTC

cube2222 wrote: post #4

Having worked with Kubernetes, it's great - I think even smaller setups can benefit from it and its approach (especially when using a managed provider). But for startups and/or simpler setups, ECS/Lambda is so much less work, while usually being powerful enough.

I've looked at it a few times but haven't been able to get my head around the concept. Reading the intro documentation I haven't been able to map the concept of "nodes" to a server, database, and GPU server.

Re: Kubernetes is a red flag signalling premature optimisation

#20

Post by pjmlp » Mon, Jul 04, 2022, 8:32 AM UTC

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…

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.