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

471–480 of 558 posts

Re: Kubernetes is a red flag signalling premature optimisation

#471

Post by 0xCAP »

zinclozenge wrote: post #444
moomoo11 wrote: post #390

Earlier quoted context omitted.

Please don’t do this. I’m dealing with the mess caused by following this line of thinking. One guy (okay it was two guys) set up all the infrastructure and as soon as it was working bounced to new jobs with their newfound experience. The result is that dozens of engineers have no idea what the heck is going on and are lost navigating the numerous repos that hold various information related to deploying your feature.…

The mistake people make thinking about Kubernetes is that it's about scale, when really it's just a provider for common utility, with a common interface, that you need anyway. You still need to ingress traffic, you still need to deploy your services, etc.

This, so much...

Re: Kubernetes is a red flag signalling premature optimisation

#472

Post by mirceal »

0xCAP wrote: post #470
mirceal wrote: post #468

Earlier quoted context omitted.

Level 1) you package your service into a zip/rpm/deb/etc and have an agent on the machine that periodically pulls Level 2) you pack your software into an ami and use the update the asg config. You can periodically "drain" the asg of old instances Level 3) you deploy your stack again with the new stack having the ami that you've build at level 2 referenced. You start shifting traffic between the old stack and the new…

Worst solutions I've heard in a while, no offense...

sure thing. share your solutions and why the are better?

Re: Kubernetes is a red flag signalling premature optimisation

#473

Post by Scotrix »

movedx wrote: post #271
Scotrix wrote: post #262

Earlier quoted context omitted.

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…

That’s all solved for you, helm upgrade in ci/cd and bump of versions has been straight forward, if not snapshot rollback via Longhorn, also for DR. Accidentally deleted data => get the last snapshot, 5 minutes it’s back (except that there is of course CI/CD in place for new code + no write permissions for devs on the cluster and „sudden“ data deletion somewhat rare).

Elastic usecase is for crawling crazy amount of data and make it searchable and aggregatable and historically available, don’t know any other solution than elastic who has reasonable response times and easy-to-use access (plus we can add some application logging and APM).

> Puppet Bolt, Ansible, Chef, ...

Helm chart values.yaml and you’re all set, security + easy version bump included.

Re: Kubernetes is a red flag signalling premature optimisation

#474

Post by pessimizer »

okamiueru wrote: post #281
lr4444lr wrote: post #253

Earlier quoted context omitted.

That isn't the point. If he had a whole year, was there a tangibly better use of his time to get a product to market faster? What might the business implications be for doing or not doing so?

It seems many are focused on the time estimate. That was in creating the overall solution. About two months was to set up the infrastructure mentioned. These often get developed side by side. GitLab, unit tests, api-server, nginx, cert-manager, deployments, integration tests, prometheus, metrics in services, grafana, alert-manager, log consolidation, work services and scaling, etc. Just spinning up a cluster, nodepoo…

I think that people are focusing on the time estimate just to estimate a cost, and asking what the return was. The material return.

Re: Kubernetes is a red flag signalling premature optimisation

#475

Post by okamiueru »

noogle wrote: post #306
okamiueru wrote: post #210

Earlier quoted context omitted.

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.

I should perhaps have clarified, but the 10-15 are not self maintained services. You need nginx for routing and ingress, set up cert-manager and other ingress endpoints are automatically configured to have TLS, deploy prometheus, which comes with node-exporter and alert-manager, deploy grafana.

So far, we're up at 6 services, yet still at almost zero developer overhead cost. Then add the SaaS stack for each environment (api, worker, redis) and you're up at 15.

Re: Kubernetes is a red flag signalling premature optimisation

#476

Post by nouveaux »

grog454 wrote: post #300
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…

> 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 through nginx and cert-manager, do full integration tests, etc. > I found that to be quite impressive, for one person, one year, and would probably be completely impossible if it wasn't for k8s. I've always found this interesting about web based development. I have…

I dont know AWS ec2 apis and for sure I'm not capable of writing auto-scaling architecture. This is the reason why I default to K8s. I have used it easily and successfully by myself for the last 4 years. It just keeps on running and hasn't given me any problems.

Re: Kubernetes is a red flag signalling premature optimisation

#477

Post by movedx »

osigurdson wrote: post #298
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…

>> Helm and the likes make it possible to spin up these kinds of solutions in a heart beat Genuine question, why is this bad? Is it because k8s can spin it up but becomes unreliable later? I think the industry wants something like k8s - define a deployment in a file and have that work across cloud providers and even on premise. Why can't we have that? It's just machines on a network after all. Maybe k8s itself is jus…

Oh it's most certainly NOT bad! It's very, very good. But it's not the end of the story. Imagine if you could press a button in a recipe book and a stove, pan, some oil, and some eggs appeared and the eggs started cooking... amazing! But that's not the end of the story. You don't have scrambled egg yet. There's still work to be done and after that, there's yet more work to be done - the washing up being one of them.

It's everything that comes afterwards that gets neglected. Not by everyone, granted, but by most.

Re: Kubernetes is a red flag signalling premature optimisation

#478

Post by nouveaux »

mirceal wrote: post #472
0xCAP wrote: post #470

Earlier quoted context omitted.

Worst solutions I've heard in a while, no offense...

sure thing. share your solutions and why the are better?

I'll be honest I haven't fully explored AMIs as a solution but how do you run the AMI in your local dev environment? I can replicate the same K8s with docker images easily in local dev.

Re: Kubernetes is a red flag signalling premature optimisation

#479

Post by movedx »

preommr wrote: post #299
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…

> It's the science of thinking you'll be Google next week, There's other reasons to use K8s than just thinking of massive scale. Setting up environments becomes a massive PITA when working directly with VMs. The end result is either custom scripts, which is a messier version of terraform, which ends up being messier than just writing a couple of manifest files for a managed k8s. > anyone with K8s experience is demand…

> Setting up environments becomes a massive PITA when working directly with VMs.

I guess I've just never found this to be true.

My main goal when engineering a solution is always, "Keep It Super Simple (KISS), so that a junior engineer can maintain and evolve it."

Working directly with operating systems, VMs, networking, etc. (purely in Cloud - never on-prem... come on it's 2022!) is the simplest form of engineering and is much easier than most claim.

Re: Kubernetes is a red flag signalling premature optimisation

#480

Post by movedx »

nouveaux wrote: post #478
mirceal wrote: post #472

Earlier quoted context omitted.

sure thing. share your solutions and why the are better?

I'll be honest I haven't fully explored AMIs as a solution but how do you run the AMI in your local dev environment? I can replicate the same K8s with docker images easily in local dev.

If you can't run your software locally without Docker, I'd be worried.

But to answer the question, VMs have been a thing on the desktop for a very long time.

Post reply on HN