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

231–240 of 558 posts

Re: Kubernetes is a red flag signalling premature optimisation

#231

Post by matwood »

jpgvm wrote: post #171
gjulianm wrote: post #136

Earlier quoted context omitted.

I mean, container+registry is possibly more complex to start and maintain than just creating a service file with SystemD. Deployment can be as easy of "systemctl restart service", and seems to me that configuring all of those resources in Kubernetes is far more difficult that just setting up a simple service on a bare box. Not to mention that you could use Docker too. And by the looks of it, ingress doesn't seem triv…

You don't run your own registry (except in very rare circumstances where that makes sense). You author Dockerfile (or better yet use a tool like jib that creates containers automatically without even a Docker daemon), then you push to hosted registry. Ingress is trivial to use. Internally it's less trivial but you don't need to peek inside unless you manage to break it which generally speaking, you won't; even if you…

Just want to note that we have a mix of ECS and stuff still running on bare VMs using tools like systemd, bash script deploys, etc..., and I 100% agree with you. Once someone understands container orchestration platform concepts, deploying to something like k8s or ECS, is dead simple.

Re: Kubernetes is a red flag signalling premature optimisation

#232

Post by KptMarchewa »

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…

>It's basically admitting that you expect most later employees to not understand k8s or how its being used.

That's also exactly what would happen if you homebrewed your own system. You need to centralize some part of expertize around infra at some point, but hopefully around more than two people.

Re: Kubernetes is a red flag signalling premature optimisation

#233

Post by pfraze »

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…

Then write documentation or train your team.

Re: Kubernetes is a red flag signalling premature optimisation

#234

Post by Beltalowda »

ratww wrote: post #104
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).

This is an underestimation of how hard it is to learn to program. Someone learning a first language isn't just learning a new language: they're learning how to program. It's a new profession, a new hobby, a new superpower. The rest of the stuff (standard library, ecosystem, buildsystem and all kinds of intricacies) is just a mix of trivia and bureaucratic garbage you gotta fill your brain with but will all be replace…

I think a lot of people here have been doing this programming thing for so long we've forgotten we once had trouble understanding things like:

  x = 1
  for i in [1, 2, 3] {
     x = i
  }
What is the value of "x" at the end? Assuming block scope, it will be 1, or assuming it doesn't have block scope (or that it uses the already defined "x" in this pseudo-example) it will be 3.

A lot of beginning programmers struggle with this kind of stuff, as did I. Reading this fluently and keeping track of what variables are set to takes quite a bit of practice.

I've been hired to work on languages I had no prior experience on, and while there was of course some ramp-up time and such, overall I managed pretty well because variables are variables, ifs are ifs, loops are loops, etc.

Re: Kubernetes is a red flag signalling premature optimisation

#235

Post by SassyGrapefruit »

Why build it when you can buy it? Right? The decision is more involved that this. The real question is...

What is the shortest route to a sustainable, defensible revenue stream?

In the 80's IBM built a super quick computer out of pieces you could buy at Radio Shack. The ultimate solution! Why incur all that upfront manufacturing cost when you can assemble it out of existing parts? They learned the answer really quickly. The lower barriers of entry meant anyone could recreate the product. And so a million clones popped up using the same parts. For a decade Apple ate their lunch by investing in a proprietary platform(which a lot people said was madness using the exact reasoning on display in this article)

SaaS is great but you have to have some sort of moat for whatever you are building. Sometimes that moat can be as simple the idiosyncrasies of your over-engineered, prematurely optimized product. I had a hand in the development of one of the major VPS players during the 2010's. There were things we could do just because of the weird decisions people had made in the past. That translated directly to competitive advantage.

Re: Kubernetes is a red flag signalling premature optimisation

#236

Post by gls2ro »

sofixa wrote: post #208
ClumsyPilot wrote: post #178

Earlier quoted context omitted.

The Whole advice of using same language is especially silly - iOS is stuck with Swift, and the web is stuck with JS, and maybe you need an applitation that scales using actors across mutiple machines with Golang or Java, or maybe you need to plug into Windows tightly and need C#. Kubernetes is not 'harder' if all you need is to host a webapp. Where it falls on the hardness spectrum depends on what you are trying to d…

> The Whole advice of using same language is especially silly - iOS is stuck with Swift, and the web is stuck with JS, and maybe you need an applitation that scales using actors across mutiple machines with Golang or Java, or maybe you need to plug into Windows tightly and need C# And you're also forgetting Android and macOS and Linux. That's why cross-platform frameworks like Electron and React Native are so popular…

What is a huge company?

Here is an example of a team that is doing great work in mobile, frontend and backend:

3 people doing native iOS, 2 people doing native Android, 3 backend engineers, 1 frontend and 1 QA.

Two engineering managers/team leaders: one for mobile and one for web.

Of course this is one single product offering native mobile apps and some limited web app functionalities.

The apps are great, smooth, nice UX, works fast, offers native experience.

Is this a huge company? I don't think so.

Re: Kubernetes is a red flag signalling premature optimisation

#237

Post by afiori »

jpgvm wrote: post #122
ggktk wrote: post #102

Earlier quoted context omitted.

Unfortunately, that doesn't seem the way WASM is going. It's been 5 years and we still can't access the DOM without going through JS.

There isn't the political will-power to make it happen and force all the browser vendors to agree and implement. Hence status-quo remains.

Which is ironic as the DOM interface was designed as an abstract interface (the IDL used in the spec is more interested in compatibility with Java than JS).

In practice though the main reason is that to have decent DOM bindings you need to stabilize many other specs first (unless you do a ultra-specific DOM-only extension, but nobody wants that)

Re: Kubernetes is a red flag signalling premature optimisation

#238

Post by williamcotton »

I have the strange urge to create a sort of web app Olympics.

Let’s see just how long it takes for participants using their preferred tools to build and deploy a Todo app with user accounts!

And then we see how long it takes to go from the initial application to one that supports 1000 requests a second.

Re: Kubernetes is a red flag signalling premature optimisation

#239

Post by SassyGrapefruit »

Noughmad wrote: post #201

I really don't understand all these complaints about how Kubernetes is so complex, how it's an investment etc. I am a single developer that uses Kubernetes for two separate projects, and in both cases it has been a breeze. Each service gets a YAML file (with the Deployment and Service together), then add an Ingress and a ConfigMap. That's all. It's good practice so still have a managed DB, so the choice of Kubernetes…

I agree I consider kubernetes to be a simplification. I have two apps running at my company the first is a forest of php files and crontabs strewn about a handful of servers. There are weird name resolution rules, shared libs, etc. Despite my best efforts its defied organization and simplification for 2.5 years.

The second is a nice, clean EKS app. Developers build containers and I bind them with configuration drop'em like they're hot right where they belong. The builds are simple. The deployments are simple. Most importantly there are clear expectations for both operations/scaling and development. This makes both groups move quickly and with little need for coordination.

Re: Kubernetes is a red flag signalling premature optimisation

#240

Post by gautamdivgi »

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…

Use a managed k8s cluster (eks, aks or gke). Creating a production ready k8s on vms or baremetal can be time consuming. Yes, you can do lamdba, serverless, etc. but k8s gives you the same thing and is generally cheaper.
Post reply on HN