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

501–510 of 558 posts

Re: Kubernetes is a red flag signalling premature optimisation

#501

Post by hsn915 »

lima wrote: post #213
hsn915 wrote: post #200

Earlier quoted context omitted.

> The biggest learning curve is for the person setting up the initial deployments, services, ingress etc Most other team members may just need to maybe change the image name and kubectl apply to roll things out. This is a huge redflag. It's basically admitting that you expect most later employees to not understand k8s or how its being used. You may think they don't need because it works, but you have to think about w…

You have this with literally every deployment mechanism, except with Kubernetes the boundary is standardized and you can easily find/hire/teach new team members to work on the complicated parts. Custom VM/cloud/$randomSaaS deployments are much worse when it comes to "the one guy who understands the intricate details is on vacation".

Of course, if your deployment mechanism needs to be complicated, standarizing on something everyone knows is useful.

The underlying assumption behind my comment is that you really really want to simplify your deployment as much as you can.

Unfortunately this is nearly impossible with the currently accept set of standard best practices for developing web applications, where you use a scripting language and like six different database systems (one for source of truth on data, one for caching, one for full text search, and who knows what else everyone is using these days; I honestly can't keep track).

There are many ways to make the deployment process simple. My rule of thumb is to use a compiled language (Go) and an embedded database engine.

The levels.io guy famously did it even with php https://twitter.com/levelsio/status/1102487697220820994

Re: Kubernetes is a red flag signalling premature optimisation

#502

Post by hadlock »

pjmlp wrote: post #36
hadlock wrote: post #9

Earlier quoted context omitted.

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.

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.

Re: Kubernetes is a red flag signalling premature optimisation

#503

Post by quickthrower2 »

andybak wrote: post #344
quickthrower2 wrote: post #185

Earlier quoted context omitted.

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…

You seem to be saying there's nothing inbetween K8s and "use a BaaS or PaaS"? What about something that does the subset of what K8s does that is the simple bit and covers most use-cases outside of complex clusters? I get the strong sense people are just misusing it for the wrong types of task. I've seen this happen countless times in tech. Development by CV.

It is like asking for something between vanilla JS and React. Or something between zipping your src folder and git.

The problem is, while this is in theory good, the weight of knowledge and support for React (and git) make it worth putting up with a bit more complexity. That support covers: Stackoverflow, Colleagues, New Hires, Cloud Support of these things (Vercel for example using both Github and React!)

You learn the tool, then you are set for 10+ years, probably, in both cases.

In the Kubernetes case, the killer thing is it very easy to set up a cluster on cloud platforms. I am not so sure about say Docker compose or the other ones. I am in the Azure world and Azure dropped support for direct container running, and now you need to use k8s if you want something cloud managed. (As far as I know).

Re: Kubernetes is a red flag signalling premature optimisation

#504

Post by mirceal »

movedx wrote: post #480
nouveaux wrote: post #478

Earlier quoted context omitted.

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.

that's the crux of the problem. people no longer know, understand or want to know and understand what their software is vs what is around their software. they treat docker and k8s as a way of packaging software and just ignore all the lessons that generations of software engineers have learned when it comes to how to properly manage your dependencies and how to correctly pack your software so that it's resilient and runs anywhere.

we also live in a world that does not appreciate well crafted software and a lot of things are driven by the desire to build a resume. I've maintained code that was decades old and was amazing to work with and was still generating ridiculous amounts of money. I've also worked on code that was just written and used all the possible bells and whistles and development speed grinded to a halt once the it's been around for more than a couple of months.

My worst case scenario is having to work on code where the original developer didn't understand what they were doing and they just wanted to use X. Double the trouble if they didn't master X when the thing was put together.

Re: Kubernetes is a red flag signalling premature optimisation

#505

Post by quickthrower2 »

andybak wrote: post #383
digianarchist wrote: post #366

Earlier quoted context omitted.

Docker Swarm, Nomad, ECS?

I've seen K8S recommended for single server installs with a couple of services. i.e. people jumping on instead of vanilla Docker/Docker Compose.

Following that argument why use Docker? Just spin up a VM and install it on that.

Re: Kubernetes is a red flag signalling premature optimisation

#506

Post by politician »

jen20 wrote: post #362
politician wrote: post #294

Earlier quoted context omitted.

You can’t just hire 1 DevOps superstar though because they need to sleep and not burnout. You’ll need ~7 people on a rotation if you need to really support anything worth really supporting. DevOps is about giving Developers a dedicated System Operations job for some small fraction of their time.

> DevOps is about giving Developers a dedicated System Operations job for some small fraction of their time. No. DevOps is about the development and operations disciplines working together in a cross functional way to deliver software faster and more reliably. In a small enough startup both disciplines may be represented by a single person, though.

I respectfully disagree. I’ve scaled these teams myself, and it’s about giving developers in a small organization the job of deploying the solution and ensuring that it runs. In larger organizations, DevOps becomes impossible and it naturally splits into Dev and Ops. It’s important to understand where it works and when it stops working to effectively manage the transition as the business grows.

Re: Kubernetes is a red flag signalling premature optimisation

#507

Post by politician »

jjav wrote: post #346
politician wrote: post #294

Earlier quoted context omitted.

You can’t just hire 1 DevOps superstar though because they need to sleep and not burnout. You’ll need ~7 people on a rotation if you need to really support anything worth really supporting. DevOps is about giving Developers a dedicated System Operations job for some small fraction of their time.

> You can’t just hire 1 DevOps superstar though You don't go from zero to needing global 24x7 support overnight. Hiring 1 DevOps superstar is exactly what we did a few startups back and it worked great. Of course there was no after-hours support, it's a small startup. Eventually the team grew.

Fair enough. If you don’t need 24/7 and the bus factor risk is tolerable, then you might not need a rotation.

I’d just caution that when it comes to the mental health of the one person in this role, even if they seem like they are doing ok, check in frequently.

Re: Kubernetes is a red flag signalling premature optimisation

#508

Post by jhugo »

gjulianm wrote: post #413
jhugo wrote: post #350

Earlier quoted context omitted.

It depends. There are many things that carry a cost early but pay for themselves many times over later. Whether that will be the case for your startup depends whether you end up needing to scale quickly or not. It's also worth considering that appropriate use of k8s can quite likely save you time and money early on as well. It standardises things, making it very easy for new ops people to onboard, and you might other…

> It depends. There are many things that carry a cost early but pay for themselves many times over later. Whether that will be the case for your startup depends whether you end up needing to scale quickly or not. Well, precisely what I said is that 99.9% of startups won't find themselves in a situation where they need to scale quickly and the only scale problems they find can be solved with Kubernetes. > It's also wo…

You seem to be describing very early stage companies, and if so I agree, host it on your laptop if you need to, it makes zero difference. But it's not binary with Netflix on one side and early stage on the other.

There are a lot of companies in the middle, and following dogma like "you don't need k8s" leads them to reinvent the wheel, usually badly, and consequently waste enormous amounts of time and money as they grow.

Knowing when is the right time to think about architecture is a skill; dogmatic "never do it" or "always do it" helps nobody.

Re: Kubernetes is a red flag signalling premature optimisation

#509

Post by jhugo »

dasil003 wrote: post #414
jhugo wrote: post #365

Earlier quoted context omitted.

I certainly wouldn't recommend that anyone "focus on multi-cloud" in an early-stage company (unless of course multi-cloud is a crucial part of their product in some way). Kubernetes is basically an industry standard at this point. It's easy to hire ops people competent in it, and if you do hire competent people, it will save you time and money even while you are small. As an investor "we use this product for orchestr…

I agree with all of that. That said, I don't think competence is a binary proposition, and if you hire people who have only worked at scale they will be calibrated very differently to the question of what is table stakes. One of the critical components of competence for early stage tech leadership is a keen sense of overhead and what is good enough to ratchet up to the next milestone. As many problems as containeriza…

The overhead of containerisation is mostly in the learning curve for teams that are not already familiar with it (and the consequent risk of a poor implementation). A well designed build pipeline and deployment is at least as efficient to work with as your Terraform+Ansible.

If you have such a team, it can of course make sense to delay or avoid containerisation if you don't see obvious major technical benefits.

But those teams will get rarer as time goes on, and since we're talking about startups, honestly it would be questionable to build a new ops team from people with no containers knowledge in 2022.

Re: Kubernetes is a red flag signalling premature optimisation

#510

Post by osigurdson »

knewter wrote: post #455
DuskStar wrote: post #437

Earlier quoted context omitted.

> They used the work of others to get to the result. Should everyone go back to assembly on bare metal, then?

Lol you think you get computer. Use hands to mine lithium, go.

One would also need to independently discover much of math and physics in order to say they did it themselves according to that definition.

I think you mean silicon though.

Post reply on HN