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

271–280 of 558 posts

Re: Kubernetes is a red flag signalling premature optimisation

#271

Post by movedx »

Scotrix wrote: post #262
okamiueru wrote: post #106

Earlier quoted context omitted.

I don't think their advice about not using it in a startup is correct either. You just need to somewhat know what you're doing. I know of such a case, where a single engineer could leverage the helm chart open source community, and set up a scalable infrastructure, with prometheus, grafana, worker nodes that can scale independently of web service, a CI/CD pipeline that can spin up complete stacks with TLS automated t…

I agree with that, setting up k8s on bare-metal took me 2 days, and we needed it to deploy elastic and some other helm charts as quickly as possible without loosing our minds maintaining nodes with some clunky shell scripts. Also we bought us immediately an easy approach to build gitlab ci/cd pipelines + different environments (dev, staging, production) on the same cluster. Took me a week to set everything up complet…

> deploy elastic and some other helm charts as quickly as possible

Bad culture alert! No one needs Elastic "as quickly as possible" unless their business, or the business they work for, is being very poorly run.

I would also argue that you might have got it running quickly, but how are you patching it? Maintaining it? Securing it? Backing it up? Have you got a full D/R plan in place? Can you bring it back to life if I delete everything within 3-6 hours? Doubt it.

> maintaining nodes with some clunky shell scripts.

Puppet Bolt, Ansible, Chef, ...

There are so many tools that are easy to understand that solve this issue.

Re: Kubernetes is a red flag signalling premature optimisation

#273

Post by movedx »

sudarshnachakra wrote: post #265

While I tend to agree to the conclusion on premature optimization - I disagree with the assumption that it is premature for most startups. In fact it's a reasonable insurance for startups (that is - if at all they succeed) it'll solve the problem of scale at that point without needing to make huge changes. BTW Google open-sourced Kubernetes not for charity (like all businesses they also want to make money), they knew…

> ... it'll solve the problem of scale at that point without needing to make huge changes.

This is incorrect. It's a common mistake to pre-optimise for a future that may never come. I call it "What-If Engineering".

You should always just build a monolith and scale it out as and when you understand what it is that needs scaling. Choosing the right languages and frameworks is where you need to put your effort. Not K8s.

https://martinfowler.com/bliki/MonolithFirst.html

Re: Kubernetes is a red flag signalling premature optimisation

#274

Post by m0llusk »

Comparison to internationalization might be interesting. Supporting multiple languages almost always expands the potential customer base, sometimes by a large amount. But even with the potential business impact it is extremely rare for applications to be localized early on. Doing the work early makes it much easier and pays off in organizing communication with users. Is this because the tools that are used are not impressive or powerful enough? Maybe needing to know multiple languages and team up with others is the blocker? Working on localization it is often remarkable how great effort often gets put into pretty much everything else and then translations are added hastily and with as little sophistication as possible.

Re: Kubernetes is a red flag signalling premature optimisation

#275

Post by ki_ »

personally i believe you should try to avoid as many services as possible. Why do you want to rely on a service? What if the service says "bye bye", you'd be like.. ok i guess our software doesnt work anymore.. RIP. I also feel like many developers use services to hide the fact they just suck at solving certain problems. E.g. we need to deploy.. ok we need this 3rd party service that will deploy for us, we will give them access to all our servers and therefore all data and that's absolutely not weird, + you'll have to read their docs for a few hours to know how it works... ok.. how about i write a simple deploy script in 5 minutes? "NO WTF! Are u insane??? Everything will crash and burn unless we use this service". :: So that's basically how my conversations go with these other devs. Really annoying, i just gave up on them, i just let them do what they want, you cant change their mind.

Re: Kubernetes is a red flag signalling premature optimisation

#276

Post by p_l »

wiredone wrote: post #177

I'll be honest - i've worked places where kubernetes was a thing, and places where it wasn't. Both within the last 5 years. Kubernetes is a layer of complexity that just isn't warranted for most companies. Hell even Amazon still sticks with VMs. Autoscaling and firecracker solve most things. Its nice to have cluster (pod?) management as a first-class concept, but you get that with tagging of instances just as well fo…

Amazon is IMHO an anti-example - they have huge installed base of tooling to handle VMs, and most importantly, they have huge scale of capital available. Throwing single-use VMs at the wall is cheap for them.

Meanwhile, I was chugging around with k8s because it was balance between "easy to deploy our workloads with minimal time spent" vs "increasing the cost by few pizzas will cause noticeable loss so pack those VMs tight".

Re: Kubernetes is a red flag signalling premature optimisation

#277

Post by huffmsa »

hsn915 wrote: post #200
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…

> 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. This is a huge redflag. It's basically admitting that you expect most later employees to not understand k8s or how its being used. You may think they don't need because it works, but you have to think about w…

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.

Re: Kubernetes is a red flag signalling premature optimisation

#278

Post by movedx »

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 levels.

At the individual unit level: "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?"

It also happens at the database level: "What if we need to change the schema later on? Do we really want to be restricted to a hard schema in MySQL? Let's use MongoDB".

What's even worse, is Helm and the likes make it possible to spin up these kinds of solutions in a heart beat. And, as witnessed and evidenced by several comments below, developers think that's that... all done. It's a perfect solution. It won't fail because K8s will manage it. Oh boy.

Start with a monolith on two VMs and a load balancer. Chips and networks are cheaper than labour, and right now, anyone with K8s experience is demanding $150k + 10% Superannuation here in Australia... minimum!

https://martinfowler.com/bliki/MonolithFirst.html

Re: Kubernetes is a red flag signalling premature optimisation

#279

Post by ratww »

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...

The concepts still roughly translate and help, though. You have projections/mappings in FP. Or if you want to go deeper, recursion. Understanding loops before those will definitely make them easier since they are equivalent.

The argument that learning a second language is as difficult as learning the first doesn’t really hold water in practice as well, lots of people have done so.

Re: Kubernetes is a red flag signalling premature optimisation

#280

Post by p_l »

iasay wrote: post #206
Noughmad wrote: post #201

I really don't understand all these complaints about how Kubernetes is so complex, how it's an investment etc. I am a single developer that uses Kubernetes for two separate projects, and in both cases it has been a breeze. Each service gets a YAML file (with the Deployment and Service together), then add an Ingress and a ConfigMap. That's all. It's good practice so still have a managed DB, so the choice of Kubernetes…

It’s really complicated when something goes wrong. That is my only criticism. Particularly in the various CNI layers out there. You really have to know exactly how everything works to get through those days and that is beyond the average person who can create a docker container and push it into the cluster which is the usual success metric.

Networking is complex, unfortunately, and cloud networking has a legacy of trying to support things that never should be supported (stretched L2s, 10./8 everywhere, etc.)

Things get much simpler if you try to limit CNI complexity by going towards at least conceptually simpler tooling that matches original, pre-CNI design of k8s, IMHO.

Post reply on HN