Kubernetes is a red flag signalling premature optimisation • Hacker News Board

Re: Kubernetes is a red flag signalling premature optimisation

#211

Post by snorremd » Mon, Jul 04, 2022, 11:13 AM UTC

waffles2021 wrote: post #77

jsiepkes wrote: post #61

Earlier quoted context omitted.

While concepts transfer over between languages the language is only 10% of it. The rest of it is the standard library, ecosystem, buildsystem and all kinds of intricacies you have to know about and what not which is specific to the language (ecosystem).

There is also an issue with conceptual leakage, most noticeably I've found with devs well versed in one language bending another language into behaving like the former.

Agreed. You see this a lot with people with a C# and/or Java background using TypeScript with annotation based decorators and libraries/frameworks that implement dependency injection, etc. They don't really embrace the nature of the new language and ecosystem. And I can sympathise, it is simpler to do things as you have been doing them before.

You also see it when people who've mostly done imperative programming tries their hands with a lisp or some ml based language. I've been there myself. You still find yourself using the equivalent of variable bindings, trying to write in an imperative rather than declarative style.

I guess when trying to learn a new language in a different paradigm you also need to unlearn a lot of the concepts from the former language.

Re: Kubernetes is a red flag signalling premature optimisation

#212

Post by nightpool » Mon, Jul 04, 2022, 11:13 AM UTC

onion2k wrote: post #32

moreira wrote: post #8

Earlier quoted context omitted.

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.

Are there contractors out there that will take on call shifts? Because it seems unlikely, and if your proposal is "put into a production a system that you will have to spend $500/day every time it goes down and wait 2-4 business days for a resolution" then you're a braver person than I am.

Re: Kubernetes is a red flag signalling premature optimisation

#213

Post by lima » Mon, Jul 04, 2022, 11:13 AM UTC

hsn915 wrote: post #200

tr33house wrote: post #180

As a startup founder that's not VC funded, I would totally recommend you look into building with kubernetes from the get go. 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. Knowing that rollouts won't bring down prod and that they can be tested in different…

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

Re: Kubernetes is a red flag signalling premature optimisation

#214

Post by AgentME » Mon, Jul 04, 2022, 11:14 AM UTC

spion wrote: post #164

beachy wrote: post #121

Earlier quoted context omitted.

I'm far from a full stack developer, but really how much code would actually be common across the front and and back end? I would have thought maybe some validation code, not sure how much else?

It depends. If you do server-side rendering with something like nextjs, then its quite a lot of code. With trpc you can share types without going through an intermediary schema language ( https://trpc.io/ ) although I think it would've still benefitted from separating the schema from the implementation (hope you don't forget the type specifier and import your backend into your frontend by accident) For business logic…

Even when using Nextjs, it's still pretty common to have a separate API backend that doesn't also have to be in Javascript/Node. There are parts of backend code (HTML generation) that very strongly benefit from being unified with the frontend code, and there are parts of backend code (like database persistence code) that much less strongly if at all in some cases benefit from unification with the frontend code. Many people split these parts of backend code up between a separate Nextjs backend service and API backend service, and Nextjs lends itself well to this.

I'm a big Nextjs fan; I just think it's useful to emphasize that using it doesn't necessarily have to mean "only javascript/typescript on the backend".

Re: Kubernetes is a red flag signalling premature optimisation

#215

Post by cjalmeida » Mon, Jul 04, 2022, 11:15 AM UTC

shankr wrote: post #129

jpgvm wrote: post #116

Earlier quoted context omitted.

Have you made a good faith attempt to use k8s? Or are you just regurgitating how hard it is to use based on what you hear on the Internet? My experience is even mediocre engineers are capable of understanding k8s concepts with minimal assistance assuming things are either sufficiently standard (i.e google-able) or well documented with any company specific practices. K8s == hard to run, k8s != hard to use.

I am not a SDE but I did try one weekend to set-up a self managed k8s cluster in the previous company. I did have some previous knowledge of using k8 in GCP. Although when trying to set it up on a completely new cluster outside of GCP, I did run into some issues where I felt I was out of my depth. I think unknowingly I exposed whole of the cluster to the public internet. On the other hand, with docker swarm, I built…

Friends don’t let friends run their own k8s instances. You should use cloud managed deployment and rely on their security services.

For comparison, you can just as easily expose/hide your VM as your managed k8s cluster.

Re: Kubernetes is a red flag signalling premature optimisation

#216

Post by [deleted] » Mon, Jul 04, 2022, 11:16 AM UTC

[deleted]

Re: Kubernetes is a red flag signalling premature optimisation

#217

Post by proxysna » Mon, Jul 04, 2022, 11:22 AM UTC

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.

Nomad is a lot easier to get into, all the while it provides almost the same functionality as k8s, including a lot of the edge cases like orchestrating vm's, lxc, firecracker and ofc workloads on windows and freebsd too. Weakest point of nomad compared to k8s IMO is the size of the community.

Re: Kubernetes is a red flag signalling premature optimisation

#218

Post by cjalmeida » Mon, Jul 04, 2022, 11:23 AM UTC

wodenokoto wrote: post #155

It’s kinda curious that the HN sentiment in the comments has lately switched from “kubernetes is hell” to “kubernetes is quite useful and well worth it” To me, kubernetes is the kind of giant, complicated, hard to understand software that is ripe for HN disdain.

Modern CPUs are giant, complicated pieces of hardware. But they’re useful, and have a well defined interface that you can interact with it at a higher level.

Same with k8s. People conflated running k8s from scratch, with administrating. The former is very hard, you should buy it from a cloud provider. The latter is IMO not much harder than VMs at small scale and much simpler at you grow bigger.

Re: Kubernetes is a red flag signalling premature optimisation

#219

Post by thathndude » Mon, Jul 04, 2022, 11:24 AM UTC

andybak wrote: post #189

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?

Agreed. OC is overstating it. It’s not that the anti K8s crowd is necessarily anti-containerization, it’s that containerization doesn’t necessarily require Something as complex as K8s.

I’m invested in Cycle.io, which is a company that simplifies containerization and infrastructure (major oversimplification of the company). But a lot of customers are refugees from K8s, whose appetite exceeded common sense. Their infrastructure ops teams are costing them 6-7 figs that they can shed with something like Cycle, because K8s is simply really complex.

This is going to become really really important in the next 3-4 lean years we have coming our way. If you’re a K8s user, and spending money you can’t afford on an ops team to manage, you owe it to your company, investors, and customers to explore options to reduce this type of burn.

P.S. Intentionally not making a hyperlink for Cycle.io because I’m honestly not trying to shill here.

Re: Kubernetes is a red flag signalling premature optimisation

#220

Post by mrweasel » Mon, Jul 04, 2022, 11:24 AM UTC

shele wrote: post #45

> Imagine spending a lot of time and money picking out the best possible gear for a hobby before actually starting the hobby. Haha, this is exactly what “hobby” means to a lot of people. Less judgmental: thinking and dreaming about the right tools in disproportion to the need is something people do a lot, presumably because it is a source of joy.

That bit was pretty interesting to me as well, because that's exactly what many people do. I don't agree that this is what "hobby" means, it's more that we tend to try to buy our way into a life style.

I feel that Kubernetes is exactly that for a large number of developers, operations people less so, they want to be part of a professional, world class, trendy environment/community. So they try leverage Kubernetes to elevate them to this Silicon Valley type tech company.

There's absolutely value to be had from Kubernetes, but I agree with the article, it's not for the majority. Except I think there is one valid reasoning: If you purely see Kubernetes as tooling for deployment, it's hard to present any good alternatives for deploying to VMs or physical hardware.