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

181–190 of 558 posts

Re: Kubernetes is a red flag signalling premature optimisation

#181

Post by jq-r »

pas wrote: post #105
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…

could you elaborate on the "ideal" argocd workflow? let's say devs push to gitlab, which starts a pipeline, tests run, container images get built, then in the last step in the gitops repo a version bump happens and then argocd will pick it up automatically? (and if one wants to be able to rollback then that's the same workflow just instead of version "bump" the pipeline tags images with the commit hash and at the las…

Not the parent, but this is exactly what happens. ArgoCD is pointed to an "application" chart which just points to a path of a helm chart (of your app/sevice) in Git. So when your CI changes the image hash in the values file in your helm chart, ArgoCD with notice that, and change the deployment resource's image hash. It is just a nice system to have resources in sync between your git repo and what you have live in the cluster. Of course, if you change anything else, ArgoCD will change it too.

You're also right, rolling back just includes changing the hash back to whatever you had, or to a new hash which was a result of a git revert or whatever. Also the good thing is that if that newly deployed service is very broken (that it doesn't pass the k8s health check), ArgoCD will hold on to the old ReplicaSet and will not let your service die because of it.

What's also nice about ArgoCD is that you can play a bit with some service/application in a branch. Say you have some live service, and you want to adjust some configuration of it. Usually third party services have a lot of options to set. The problem is that you're not 100% sure how to get what you want, so doing a pull request for every small change can be very slow and exhausting. To work around that, you can point your ArgoCD's application chart to a chart which is in a branch, test/dev/fiddle with just pushing to that remote branch, and when you're satisfied, you merge your branch, and at the same time point your ArgoCD application manifest to point to the master/HEAD for that chart. In effect, at this step, only your Git repo will be updated, your service already has all the changes so ArgoCD will do nothing. That way you can iterate faster, and undo whatever regression you've introduced just by pointing ArgoCD to watch the master, not your branch (or you can just reset your branch to be indentical to master).

Re: Kubernetes is a red flag signalling premature optimisation

#182

Post by clubdorothe »

Tim Hockin (one of kubernetes creator) supports the idea to use something as much managed and automatic as possible if you don't have time for it [1]. He probably refers to use Cloud Run [2], over a (managed?) Kubernetes cluster (such as EKS or GKE)

[1] https://twitter.com/thockin/status/1539987108521054208

[2] https://twitter.com/the_thagomizer/status/153975704907180032...

Re: Kubernetes is a red flag signalling premature optimisation

#183

Post by ramraj07 »

jpgvm wrote: post #151
ramraj07 wrote: post #123

Earlier quoted context omitted.

I have made a good faith attempt at using it, yes. Is spending an entire week on it good faith? I did get everything running but also saw so many settings and features I had to take on faith as being handled without understanding it. I just chose not to bother further because this seems like a minefield of problems in the future as we on boarded other engineers. The number of times I’ve seen production deployments go…

So what you are saying is everything worked? That sounds like k8s did its job. You aren't meant to fully understand it in a week, anymore than you are expected to fully understand all of sysadmin in a week. Just because you don't know what every single directive in nginx config does doesn't mean you can't use it effectively and learn what they mean when the time comes. k8s isn't much different. You don't need to know…

You’re right that nginx is also complicated , but seems like we are talking about different alternatives.

The solution I went with, given my limited knowledge of some of these things, was to use elastic beanstalk. You write your flask application, upload the zip and that’s it pretty much. You get a UI to do all the configurations and for the most part nothing there is hard to decipher or google. The only hiccup might be when you’re trying to connect it to RDS and to the external internet but even that is straightforward as long as you follow the right instructions. We run apps that power entire SaaS organizations and this system seems to be more than sufficient. Why complicate further? We have other fish to fry anyway.

Re: Kubernetes is a red flag signalling premature optimisation

#184

Post by okamiueru »

wrnr wrote: post #175
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…

How long did it take him to do this setup, a year you say, and that is impressive? I am not trying to be cute here, my question comes from a genuine place of curiosity. I've love to learn to spin-up a system like that, but from the tech/sales talks I see I am made to believe this can be done in a day. Expectation management is important, if people say ops is just a solved problem then I expect this to take very littl…

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 this is because of a "super-developer". In fact, he had no prior k8s experience. But rather that there are thousand upon thousand of infrastructure hours devoted to the helm charts, often maintained by the people who develop the services themselves. It is almost mind boggling how much you get for almost free. Usually with very good and sensible default configurations.

In my precious work place, we had a team of 5 good engineers purely devoted to infrastructure, and I honestly believe that all five would be able to spend their time doing much more valuable things, if k8s had existed.

As for whether or not such devops solutions could be done in a day. Hm. I don't know. These things should be tailored to the problem. If you've done all of this a few times, then maybe you can adjust a bunch of charts that you are already familiar with and do what took a couple of months and impressed me, in a couple of weeks. It's a lot more than just "helm install. Done", that goes into architecting a scalable solution. Implementing monitoring, alerting and logging. Load testing stuff. Etc.

Re: Kubernetes is a red flag signalling premature optimisation

#185

Post by quickthrower2 »

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…

Kubernetes is the React of devops. You wont get fired for picking it. And there will be a tonne of support available online, as well as courses, and experienced people you can hire. Also there is cloud managed k8s which takes most of the pain out of it. And plenty of out the box stuff.

It is not a bad choice if you want to do the ops yourself for some reason. If you don't then use a BaaS or PaaS, that might be easier and probably not much more expensive, but will lock you in.

Re: Kubernetes is a red flag signalling premature optimisation

#186

Post by lucideer »

pritambarhate wrote: post #84

Doesn't look like the author knows what he is talking about. His point about early stage startup should not use K8S is fine. But the next advice about not using a different language for frontend and backend is wrong. I think the most appropriate advice is to choose a stack which the founding team is most familiar with. If that means RoR then RoR is fine. If it means PHP then PHP is fine too. Another option is to use…

Agree the author is wrong on that specific point, though thankfully the bulk of the article content deals with the headline, and is mostly fine wrt k8s.

Rather than the author "not knowing" what they're talking about, I suspect they're taking narrow experience and generalising it to the entire industry. Their background is selling k8s as a solution to small/medium enterprises: it strikes me that there may be a strong correlation between startups interested in that offering and those deploying failed overengineered multilang micro-architectures. Suspect the author has seen their fair share of bad multilang stacks and not a lot of counter examples.

Re: Kubernetes is a red flag signalling premature optimisation

#187

Post by jhugo »

gjulianm wrote: post #170
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…

I think the set of cases where "we need to scale up rapidly if it succeeds" and "Kubernetes solves all of our scaling needs and we aren't going to have problems with other components" is almost empty. On the other hand, there are quite a lot of startups that fail because they put too much focus on the infrastructure and Kubernetes and the future and too little on the actual product for the users. Which is the point o…

> I think the set of cases where "we need to scale up rapidly if it succeeds" and "Kubernetes solves all of our scaling needs and we aren't going to have problems with other components" is almost empty.

I agree, but so what? K8s isn't magic, it won't make all your problems go away, but if you have people who are genuinely skilled with it, it solves a lot of problems and generally makes scaling (especially if you need to move between clouds or move onto bare metal) much smoother. Of course you'll still have other problems to solve.

Given that most startups never need to scale up much, it's not surprising that k8s is mostly used where it's not needed. But people usually prefer not to plan for failure, so it's also not surprising that people keep using it.

Re: Kubernetes is a red flag signalling premature optimisation

#188

Post by twawaaay »

The startup I am working for has seen entire engineering fired after they hired a lot of people and spun an enormous amount of infrastructure, spent tons of cash and produced absolutely nothing useful to the company (presumably because they were engrossed in spinning the infrastructure). The company isn't very large and does not provide software products to the clients. The systems are mostly business intelligence, billing, ERP-like, etc.

Now we are restarting lean (but wiser for the experience). 10x less people and technology accomplishes more and faster.

Most companies with that kind of problem DO NOT need Kubernetes because they don't have problems for which Kubernetes is the cheapest solution.

Most companies do need focus on keeping things simple, minimise amount of stuff to make it possible to hire a development team that has a shot at understanding what is happening.

For example, we made decision to restrict ourselves to only one cloud provider (AWS), to only one backend language, one frontend language, etc.

Our prod environment is simple, too. No effing microservices. One application on one application server easily serves the needs of a company of over 200 employees and our clients.

Simplifying the environment made wonders to productivity in many different ways, the most important being that the discussion now focuses on what the company needs and the functionality that would solve the problem rather than on technical trivia.

All this makes possible following things:

* having one development team where everybody can contribute to everything (no need to Zoom with local K8s guru to accomplish anything or spend time in endless meetings with "frontend people".)

* hiring a relatively simple developer profile. This does not mean hiring bad developers. But it means I am looking for people who know X and Y very well rather than X, Y, Z, A, B, C each a little bit... It is stupid to assume a person will know well every one of 50 different technologies listed on their LinkedIn profile -- most likely they only really know couple of things and everything else only superficially.

* hiring from talent pool that has a lot of experience but not necessarily in the stuff that other companies require. Other companies may hive overlooked them because they don't know a bunch of new tech, but we don't care. We only care that they are great people that get shit done, fit our company, and know how to design and implement functionality in their core programming language.

* engineers being able to accomplish their individual tasks from start to end, right after joining the company. No need for a long learning period.

* company needs main center of attention rather than spending large part of the effort on technical trivia.

My take? If you need to add something, first ask yourself what are the costs and better understand what you get in return for that cost.

Re: Kubernetes is a red flag signalling premature optimisation

#189

Post by andybak »

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…

> Kubernetes is actually pretty great for the vast majority of use-cases.

From my brief glances at it, it seems like a great solution for very complex use-cases. But "vast majority"? The cost-benefit seems way off unless you have a very different sense of "typical use-cases" to me.

Most people are building simple web sites and apps that run on a single server, surely?

Re: Kubernetes is a red flag signalling premature optimisation

#190

Post by lebowen »

clubdorothe wrote: post #179
lebowen wrote: post #138

I'm a developer that uses Kubernetes in production purely because I want to be able to use the same Docker images that I use in development. I am not a Kubernetes advocate but what else is there that handles all of the issues faced when deploying containers? Such as scaling, deployment, configuration etc? There are alternatives such as Hashicorps Nomad, but I don't see how this is any better/worse that K8s.

Check into Amazon ECS or Google Cloud Run. It's basically a higher level of managed Kubernetes ( EKS or GKE ). You give your containers, and they take care of running it. Tim Hockin (one of kubernetes creator) support the idea to use something as much managed and automatic as possible : https://twitter.com/thockin/status/1539987108521054208

I'm aware of these products, but do not fit my use case.

I need to run some services on premises and have set up a self hosted Kubernetes instance on a physical server in a rack.

It could be overkill and maybe I could use something like Docker Swarm. Apart from this I am unsure what I can use that isn't K8s to orchestrate my containers on site.

Post reply on HN