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

31–40 of 558 posts

Re: Kubernetes is a red flag signalling premature optimisation

#31

Post by jpgvm »

I disagree.

K8s signals the team values infra and sees it as an important part of delivering their product.

It's an investment like any other and for some teams it makes sense to set infra on a solid path sooner rather than later.

You can move fast on things like serverless but the limitations of those systems can force architecture decisions that are sub-optimal whilst control of your own infrastructure can allow broader interpretation of problems and enablement of more wholistic solutions.

i.e it opens up building things "the right way" sooner in many cases and that can save a ton of time and frustration.

Also in the case where it's obvious you will outgrow serverless it also saves on a sometimes painful migration effort.

Re: Kubernetes is a red flag signalling premature optimisation

#32

Post by onion2k »

moreira wrote: post #8
mattbillenstein wrote: post #3

In the limit, there are some startups that could run production on a single Linux host - I recently helped one get off Heroku and their spend went from ~$1k/mo to ~$50/mo and it made debugging and figuring out performance issues so much easier than what they were doing previously...

I'm very much with you on this, but I do understand that it's one of those things that is just not feasible when your team has no sysadmin/devops experience. You were able to do it, but what happens to them when you're not around? Does their team have the required experience to handle it? That's the difference in cost. It's like DYI - yes, if I have all the skills and experience I can do everything myself incredibly…

You were able to do it, but what happens to them when you're not around?

This is why you pay someone. Saving $950/month means it's well worth spending $500 for a day of someone's time occasionally. You don't have to do everything internally when you run a startup. Buying in services that you only need occasionally is well worth the money.

Re: Kubernetes is a red flag signalling premature optimisation

#33

Post by sorry_outta_gas »

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…

it's not but this article is just blogspam

Re: Kubernetes is a red flag signalling premature optimisation

#34

Post by FridgeSeal »

carom wrote: post #19
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.

The nodes are just the individual machines in your K8s cluster.

Which one(s) run your API/server, your database, etc is basically arbitrary. You’re free to let the K8s scheduler do as it see fits, or you can get increasing degrees of control by adjusting things like node and pod affinity/anti-affinity, etc.

Re: Kubernetes is a red flag signalling premature optimisation

#35

Post by angio »

carom wrote: post #19
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.

Kubernetes is fairly simple:

* You describe what type of state you need (Deployment = one or more Pods running your container, Service = expose the deployment) * Kubernetes runs a control loop that reconciles the current cluster's state with your desired state

Nodes are the virtual machines on which everything runs, you don't need to interact with them unless you have special requirements (e.g. GPU instances). In that case, you annotate GPU instances with some type of label (like `has-gpu=true`), then in your deployment you add a node affinity saying it needs to run on nodes that have that label. Kubernetes will schedule it for you if there's any node matching.

Re: Kubernetes is a red flag signalling premature optimisation

#36

Post by pjmlp »

hadlock wrote: post #9
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…

You can get away without an orchestrator right up until about when your ARR hits $10mm Hiring people with k8s experience in 2022 is not a difficult task, it's not an obscure technology anymore, and when your initial crop of devops decides to leave, the new guys coming in can scan your deployments and namespaces and pretty much hit the ground running within 48-72 hours. That's a big, important part of running a busine…

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.

Re: Kubernetes is a red flag signalling premature optimisation

#37

Post by pantulis »

mattbillenstein wrote: post #3

In the limit, there are some startups that could run production on a single Linux host - I recently helped one get off Heroku and their spend went from ~$1k/mo to ~$50/mo and it made debugging and figuring out performance issues so much easier than what they were doing previously...

The amount of traffic you can serve on a bunch of Linode boxes is pretty high. I know this sounds like a boomer yelling at the clouds --see what I did here?

Kubernetes is the right solution to a difficult problem you may or may not have in your future.

Re: Kubernetes is a red flag signalling premature optimisation

#38

Post by raverbashing »

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…

Sounds like "consultant talk", too much fluff and big words but no nuance

"Using different languages" is just Tuesday in most places. Sure, don't use languages needlessly, but it's not a big hurdle unless you're just a "nodejs bro"

Re: Kubernetes is a red flag signalling premature optimisation

#39

Post by ocius »

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?

I'm not an expert on auto scaling groups, but we have used the Google Cloud equivalent for a time. The biggest issue for us was that deployment is not as easy. Can you update the software on the ec2 instance without turning it on, for example? With K8s, we can leave the deployment scaled to 0 and just patch the image of the deployment to perform a release while the workers are all shut down. Similarly, we don't have to write code to wait for the workers to finish their current job before we shut them down in order to be replaced by a newer version; this is all managed by K8s, and the configuration for it lives in Git. As others have already pointed out, it is also important for us to remain independent from Google Cloud / AWS.

Re: Kubernetes is a red flag signalling premature optimisation

#40

Post by BFLpL0QNek »

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?

Apache Spark can use Kubernetes as a scheduler out the box. I don’t know if op is using Spark.

A lot of data tools are starting to target Kubernetes directly as a runtime so using them with GKE/EKS is a bit simpler as it’s officially supported, allows to run locally and on the cloud with no vendor lock in.

ECS in a scaling group works well if your app is stateless but as soon as you scale workers dynamically, do service discovery, orchestration, you end up building some of the features Kubernetes provides.

Post reply on HN