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

21–30 of 558 posts

Re: Kubernetes is a red flag signalling premature optimisation

#21

Post by robertlagrant »

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…

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

Exactly - $950/mo is nowhere near enough to pay for those skills if you don't have them. It's good value for money.

Re: Kubernetes is a red flag signalling premature optimisation

#22

Post by p_l »

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…

Funnily enough, small amount of servers that you want to utilize as much as possible is pretty much one of the original use cases for kubernetes.

My first deployment involved virtual machines, but we were essentially packing as much as possible into lowest amount of VMs, then doubled it up so that we had failover. This way we had clear visibility of how many resources we were using and could allocate them according to how much we had.

Re: Kubernetes is a red flag signalling premature optimisation

#24

Post by mjburgess »

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…

I'm unconvinced learning what I did as a 14yo is more complex than modern devops.

Re: Kubernetes is a red flag signalling premature optimisation

#25

Post by davnicwil »

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…

How do you know what the performance will be in what language or needs to be, in numerical terms, before you are running the system in practice?

Re: Kubernetes is a red flag signalling premature optimisation

#26

Post by robertlagrant »

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.

A node is a server, virtual or physical, which may or may not have a hardware capability such as a GPU.

Re: Kubernetes is a red flag signalling premature optimisation

#27

Post by lmm »

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 is not premature optimization to have parts of a back-end implemented in C/C++/Go/whatever else if high performance is needed.

But the overwhelming majority of the time you don't need it, at least not yet. I would say that unless you have actual evidence that your other language would not be adequate - i.e. an implementation of your system or some representative subset of it, in your main language, that you spent a reasonable amount of time profiling and optimizing, and that still proved to have inadequate performance - then it is indeed premature.

Re: Kubernetes is a red flag signalling premature optimisation

#28

Post by mattbillenstein »

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…

It's all scripted - so from bare ubuntu install to functioning environment and checked into git. So, it serves as documentation as well.

So disaster recovery is spin a new box, pull the most recent db backup in, and update dns - all scripted should I be gone.

Re: Kubernetes is a red flag signalling premature optimisation

#29

Post by xnorswap »

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've worked at many places where everything was run off single instance (usually windows) VMs.

These systems rarely were constrained in performance by scaling issues that would have be solved by scaling horizontally, and in many cases the added latency of doing so would have caused more problems than it would have solved.

And as you say, having everything on one or two VMs is not just orders of magnitude cheaper hosting, but also comes with benefits of much more easy debugging and performance monitoring.

These weren't tiny start-ups either, these were long running services contracted out to clients including the government and other major companies.

It doesn't scale infinitely, but I'd wager that the traffic just isn't there to justify these kinds of setups in 99% of cases, and that some of the scaling needed is because all the added latency and service discovery etc is adding overhead that wouldn't be needed without it.

I've often found it odd that people who strive for YAGNI at the code level don't apply the same to the system architecture level.

Re: Kubernetes is a red flag signalling premature optimisation

#30

Post by p_l »

Dave3of5 wrote: post #16

Sort of agree. There are caveats of course but I tend to think if you can just start with a bunch of manually setup instances and roll from there. If you find yourself spending hours per day starting up and shutting down instances manually then yes, automate that part. Nothing I've ever done has taken off at all so automating DevOps would have been a total waste of time. Then again the projects themselves have been a…

I think it depends on whether you automate it so that it goes out of your way so you can spend more time on things crucial to your work - or you're just pontificating because you hate your job anyway.
Post reply on HN