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

511–520 of 558 posts

Re: Kubernetes is a red flag signalling premature optimisation

#511

Post by jhugo »

foobiekr wrote: post #454
jhugo wrote: post #156

Earlier quoted context omitted.

> At the same time. I can scale heroku to 500 servers, and still be under the cost of one ops person. I can make that change and leave it there. I can do that all in under 30 seconds. Oh. And CICD is built in as a github hook. Even with blue-green deploys. And then Heroku shuts down. If you're building something that needs to scale up rapidly if it succeeds, k8s is worth thinking about. Either you don't succeed, in w…

Almost every k8s project I've looked at in the last few years is database bound. k8s is not really going to solve their scaling needs. They needed to plan more up front about what their application needed to look like in order to avoid that. Yes, if your application looks like a web application that is cache friendly, k8s can really take you a long way.

In case it's not clear, nothing in my comment suggests that k8s will magically solve all your problems. It just provides abstractions that make growth (in size and complexity) of systems easier to manage, and helps to avoid lock-in to a single cloud vendor. The wider point is that thinking about architecture early will make scaling easier, and for most companies, k8s is likely to end up being a part of that.

The "web application" / cache-friendly part of your comment doesn't make much sense to me; k8s is pretty well agnostic to those kinds of details. You can orchestrate a database-bound system just as well as you can anything else, of course.

Re: Kubernetes is a red flag signalling premature optimisation

#512

Post by osigurdson »

jbverschoor wrote: post #490
osigurdson wrote: post #298

Earlier quoted context omitted.

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

We had J2EE almost 30 years ago. 1 file which described everything and contained everything

According to the following link, that literally sounds nothing like Kubernetes. Perhaps a more appropriate analogy to older tech is something like LSF or Slurm.

https://www.webopedia.com/definitions/j2ee/

Re: Kubernetes is a red flag signalling premature optimisation

#513

Post by Spooky23 »

hotpotamus wrote: post #445
Spooky23 wrote: post #424

Earlier quoted context omitted.

Who would you prefer to pay rent to? The reality is unless you’re some rich dude who can borrow dad’s datacenter (And that’s cool if so), you’re either going to be renting colo space, virtual servers, etc. It’s always a challenge in business to avoid the trap of spending dollars to save pennies. IMO, you’re better off working in AWS/GCP/Azure and engineering around the strengths of those platforms. That’s all about t…

> Who would you prefer to pay rent to? I'm aware that no man is an island in some sense, but I'm not comfortable with locking myself into one of 3 companies who need to increase their revenue by double digits year over year. And as you say, a lift and shift is basically setting money on fire. Currently I run sort of a hybrid approach with a small IaaS provider and a colo. It seems to work well for us both technically…

That’s awesome. The most important thing is to understand why you’re making the decisions that you do.

Where I work, we can deliver most services cheaper on-prem due to our relative scale and cloud margins. But… we’re finding that vendors in the hardware space struggle to meet their SLAs. (Look at HPE — they literally sold off their field services teams and only have 1-2 engineers covering huge geographic regions. So increasingly critical workloads make the most sense in the cloud.

Re: Kubernetes is a red flag signalling premature optimisation

#514

Post by moomoo11 »

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.

Thank you for putting it so simply! I agree.

Re: Kubernetes is a red flag signalling premature optimisation

#515

Post by pjmlp »

hadlock wrote: post #502
pjmlp wrote: post #36

Earlier quoted context omitted.

So much for theory. I just came out of a project where Kubernetes performance issues involved wild guess and blind tuning until the so called experts actually found out why the cloud cluster was behaving strangely, including support from Cloud vendor. And good luck making sense of all the YAML spaghetti available for bootstrapping the whole cluster from scratch. 72 hours? They better be 10x DevOps team.

If your devops guys are struggling, you are hiring the wrong devops folks, or at the wrong end of the pay band. Most devops guys I know are paid in the same band as a senior developer.

Sure, it is like bug free C code. It is only a matter of having the top of the cream. Pity there aren't enough of them in the world, including on cloud vendor support team.

Re: Kubernetes is a red flag signalling premature optimisation

#516

Post by likortera »

javajosh wrote: post #358
danielvaughn wrote: post #287

Earlier quoted context omitted.

I've told this story before on HN, but a recent client of mine was on Kubernetes. He had hired an engineer like 5 years ago to build out his backend, and the guy set up about 60 different services to run a 2-3 page note taking web app. Absolute madness. I couldn't help but rewrite the entire thing, and now it's a single 8K SLOC server in App Engine, down from about 70K SLOC.

What's your plan when (not if) Google deprecates GAE?

It is very likely that GAE will last a lot more than the Kubernetes cowboy you hired to set up the undocumented and untested version of it in house.

Re: Kubernetes is a red flag signalling premature optimisation

#517

Post by paskozdilar »

vbezhenar wrote: post #394
bheadmaster wrote: post #159

Earlier quoted context omitted.

Plan9 has basically invented the idea of namespaces, which are fundamental building blocks of containers. Plan9 also invented 9P file protocol which is used in WSL2. Plan9 is the ultimate distributed OS. Running programs on different computers is as easy as mounting a remote /dev/cpu file to your process' namespace. Virtual desktop is as easy as mounting /dev/draw. And so on. Many such complicated things that require…

Distributed OS hides distributed nature from the application. Kubernetes does not try to hide it. It allows developer to embrace it. Hiding network latency is leaky abstraction. Kubernetes does it right. It does not pretend that there's no network between your services. It's the other way around: there's always network between your services. Sometimes it's loopback network, sometimes it's real network, but you're awa…

I don't think that that engineers who built Kubernetes were looking at Plan9 and saying "ok guys, it's too easy to do things, we must make it harder so people are aware of the network".

I think the more believable scenario is "hey let's see what we can do with the existing Linux systems and sockets and stuff" and then importing the network into the model because it was the simplest solution.

Then again, whether or not should applications be network-transparent-by-default is a discussion for itself. I believe they should. Every program (that does not drive hardware directly) is just a piece of code that glues various OS APIs together. In the case of Plan9, the APIs are the filesystem, and the filesystem can be modified with 9P protocol. If we can use the same local program to perform an operation on a remote machine without any modification, why the hell shouldn't we.

Re: Kubernetes is a red flag signalling premature optimisation

#518

Post by onion2k »

nprateem wrote: post #410
onion2k wrote: post #223

Earlier quoted context omitted.

Obviously not. You don't pay someone to just set it up. You pay to help do what you'd do if you had a dedicated devOps teams. You pay someone to set up the system with your team so they understand it , train your team to use it, write some documentation about it, script a rollback procedure, maybe help on developing playbooks, etc. Besides, there are people out there who offer on-call services for a small retainer.

This is optimistic to say the least. I've worked as an SRE for 5 years and apart from the others in the team the devs don't have nearly as much knowledge. There's no way I'd rely on them to fix an outage. And even on a small retainer you'd better hope they retained the knowledge of how all that stuff works if you're only calling on them every now and again.

And even on a small retainer you'd better hope they retained the knowledge of how all that stuff works if you're only calling on them every now and again.

This is why we document things at the company I work for. If you're serious about a project and want it to exist for a long time there will be things that only come up every few years, and you won't remember them. You can either write things down or you have to relearn how things work every time. Wroting things down is much easier.

Re: Kubernetes is a red flag signalling premature optimisation

#519

Post by K0SM0S »

jhugo wrote: post #354
K0SM0S wrote: post #225

Earlier quoted context omitted.

> if you were smart about how you used k8s, you'll be glad that you can relatively easily move between clouds or move to bare metal. I'd argue you should definitely consider multi-cloud strategy from the get-go indeed in 2022. Something like Terraform helps statically setting k8s clusters on most clouds. Especially for startups, it's better to default to vanilla stuff and only complicate on a need-to basis.

Yes, completely agreed. Multi-cloud is really not that difficult nowadays, and it puts you in a better negotiating position (when you end up spending enough to be able to negotiate), as well as giving you more location flexibility and the ability to pick and choose the best services from each cloud.

Oh yes, negotiation is a strong argument in that context. One that makes or breaks a CTO's mission, me thinks, if that company expects a lean path to ROI.

A multi-cloud paradigm is also a great way to teach you about your application and about those clouds themselves. A good reminder that "implementation is where it's at", and "the devil is in the details".

Re: Kubernetes is a red flag signalling premature optimisation

#520

Post by osigurdson »

wahnfrieden wrote: post #203
okamiueru wrote: post #184

Earlier quoted context omitted.

It took a year, but that was somewhat on the side of also building an OpenAPI based Web service, the gRPC based workers. So, it wasn't just the infrastructure stuff. If I were to estimate how much time for just the infrastructure and devops tooling, then two months. It's been up and running with less than 15 minute downtime over the course of two years. I do consider this impressive. And, to be clear, I wouldn't say…

Sounds like a waste of months that could have gone into building product by choosing simpler operational tech

How would you possibly know one way or the other?
Post reply on HN