Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

We're Leaving Kubernetes

gitpod.io

Post reply on HN
Print view View original

231–240 of 348 posts

Re: We're Leaving Kubernetes

#231

Post by sethammons »

riiii wrote: post #115

> development environments Kubernetes has never ever struck me as a good idea for a development environment. I'm surprised it took the author this long to figure out. K8s can be a lifesaver for production, staging, testing, ... depending on your requirements and infrastructure.

Our operations team is planning to build dev envs in k8s, but only the networked dependencies. Like a personal testing/staging where you have full control of the thing(s) you are developing and can simply leverage the rest of the stack.

Sounds sane. Am i missing anything?

Re: We're Leaving Kubernetes

#232

Post by throwaway2037 »

justinclift wrote: post #157
czhu12 wrote: post #148

Earlier quoted context omitted.

We tried this approach at a former company with ~600 engineers at the time. Trying to boot the full service on a single machine required every single developer in the company installing ~50ish microservices on their machine, for things to work correctly. Became totally intractable. I guess one can grumble about bad architecture all day but this had to be solved. we had to move to remote development environments which…

> installing ~50ish microservices on their machine Ouch. Where they using macOS at the time with laptops having not-enough-ram? I've seen that go poorly on macOS with java based microservices. Largely due to java VMs wanting ram pre-assigned for each, which really chews though ram that mostly sits around unused. This was a few years ago though, at the tail end of Intel based mac's where 32GB ram in a mac laptop wasn'…

    > Largely due to java VMs wanting ram pre-assigned for each
Do you mean the JVM min heap size was rather later? Otherwise, there is no need for a very large min heap size on a modern JVM (11+).

Re: We're Leaving Kubernetes

#233

Post by otabdeveloper4 »

kstenerud wrote: post #211
otabdeveloper4 wrote: post #177

Earlier quoted context omitted.

> ...but at least it's generally easy to see what you did wrong and fix it. You're not actually "fixing" anything, you're just passing the ball of shit down the responsibility chain to the ops/infra team. Which is fine if you work in a large corporation where this is a valid strategy. Unfortunately though the software supply chain problem is a) very difficult and b) unavoidable. Nix is the best (or maybe only) attemp…

I've got nothing against the fundamental concepts that Nix strives for. In fact, that's what triggered my 2 year journey with it. I just hate the implementation with a passion. The overall result is worse than before.

There is no possible way to solve anything in this problem space without triggering developer PTSD. The implementation is not at fault.

(See npm or the clusterfuck of Python packaging for proof.)

Re: We're Leaving Kubernetes

#234

Post by lmm »

0xbadcafebee wrote: post #57
horsawlarway wrote: post #33

Personally - just let the developer own the machine they use for development. If you really need consistency for the environment - Let them own the machine, and then give them a stable base VM image, and pay for decent virtualization tooling that they run... on their own machine. I have seen several attempts to move dev environments to a remote host. They invariably suck. Yes - that means you need to pay for decent h…

Most teams/products I have been involved in, the stack always grows to the point that a dev can no longer test it on their own machine, regardless of how big the machine is. And having a different development machine than production leads to completely predictable and unavoidable problems. Devs need to create the software tooling to make remote dev less painful. I mean, they're devs... making software is kind of thei…

> Most teams/products I have been involved in, the stack always grows to the point that a dev can no longer test it on their own machine, regardless of how big the machine is.

It doesn't have to be like that. I've worked on a 10MLOC codebase with 500+ committers - all perfectly runnable locally, on admittedly slightly beefy dev machines. It's true that systems will grow without limit unless some force exists to counter this, but keeping your stack something you can sanely run on a development machine is well worth spending some actual effort on.

Re: We're Leaving Kubernetes

#235

Post by chipdart »

pxc wrote: post #219
chipdart wrote: post #196

Earlier quoted context omitted.

> People just straight-up don’t want to learn. (...) but IME the majority of people in tech are incurious. They want to do their job, and get paid. Reading man pages is sadly not in that list. I don't think you know what you're talking about. Just because you know people who do not want to waste their time on a set of unproductive chores you arbitrarily singled out, that does not mean they are against learning. Your…

> Man pages are notoriously a colossal waste of time. In general they are poorly thought out, they are incomplete, they were written with complete disregard for user experience, and more often than not they are way out of date. Uh, what? What man pages are you reading? I read manpages all the time, and I've never run into an issue where one contained info that was untrue because outdated. The only manpages I've ever…

> Uh, what? What man pages are you reading?

Every single man page out there leads to a user experience that is at best subpar.

> One of the reasons Stack Overflow is so popular is that people who can't/won't read docs can use it to have answers spoonfed to them (...)

Pause and look at what you're saying. Your only criticism of SO is how it improves the task of providing meaningful information to users.

The way you opt to spin improvements to user experience as "spoonfed" speaks volumes of your inability to understand the problem and the value you place on gratuitous ladder-pulling. You even contradict your remarks on man pages.

> Reading isn't a singular skill— each genre requires its own skills (...)

No. Writing is a skill. Producing content that the target audience is able to consume and brings value is a skill. The moment you, as a end-user, feel the need to hunker down and decipher arcane texts is the moment you should realize the documentation is bad.

Again, Stack overflow is widely used as ad-hoc crowd-sourced documentation for a reason. Some project maintainers even go as far as to make it their own channel to provide technical support. Why so? Do you honestly believe its because the whole world is not smart enough to read man pages?

Again, those who do not waste their time on man pages are the smart ones who put their own time to better use.

Re: We're Leaving Kubernetes

#236

Post by chipdart »

Tainnor wrote: post #226
chipdart wrote: post #191

Earlier quoted context omitted.

> Invariably this is an ideal and does not match up in reality. No, this does indeed match reality. At least for those who work with microservices. This is microservices 101. It's baffling how this is even being argued. We have industry behemoths building their whole development experience around this fact. Look at Microsoft. They even went to the extents of supporting Connected Services in Visual Studio 2022. Why on…

You can't compare Microsoft to your run-of-the-mill small (or even large) software shop, though. Maybe on HN, most people work on these amazingly designed systems, but in my experience most tech out there is shit and has no proper design or architecture beyond "we're doing microservices because everyone is".

> You can't compare Microsoft to your run-of-the-mill small (or even large) software shop, though.

I'm talking about how Microsoft added support for connected services to Visual Studio. It's literally a tool that anyone in the world can use. They added the feature to address existing customer needs.

Re: We're Leaving Kubernetes

#237

Post by lmm »

pmarreck wrote: post #88
horsawlarway wrote: post #33

Personally - just let the developer own the machine they use for development. If you really need consistency for the environment - Let them own the machine, and then give them a stable base VM image, and pay for decent virtualization tooling that they run... on their own machine. I have seen several attempts to move dev environments to a remote host. They invariably suck. Yes - that means you need to pay for decent h…

In my last role as a director of engineering at a startup, I found that a project `flake.nix` file (coupled with simply asking people to use https://determinate.systems/posts/determinate-nix-installer/ to install Nix) led to the fastest "new-hire-to-able-to-contribute" time of anything I've seen. Unfortunately, after a few hires (hand-picked by me), this is what happened: 1) People didn't want to learn Nix, neither d…

I love the idea/design of Nix and hope that one day someone will reimplement it in a way that one can reasonably understand/debug. Language is part of the problem but I think it's more of a https://www.lihaoyi.com/post/SowhatswrongwithSBT.html style problem where the execution model involves too much at runtime.

Re: We're Leaving Kubernetes

#238

Post by gchamonlive »

czhu12 wrote: post #148
horsawlarway wrote: post #33

Personally - just let the developer own the machine they use for development. If you really need consistency for the environment - Let them own the machine, and then give them a stable base VM image, and pay for decent virtualization tooling that they run... on their own machine. I have seen several attempts to move dev environments to a remote host. They invariably suck. Yes - that means you need to pay for decent h…

We tried this approach at a former company with ~600 engineers at the time. Trying to boot the full service on a single machine required every single developer in the company installing ~50ish microservices on their machine, for things to work correctly. Became totally intractable. I guess one can grumble about bad architecture all day but this had to be solved. we had to move to remote development environments which…

You need an option to enable only the services they need to develop locally and automatically configure them to talk to the other services hosted elsewhere.

Re: We're Leaving Kubernetes

#239

Post by Tainnor »

chipdart wrote: post #236
Tainnor wrote: post #226

Earlier quoted context omitted.

You can't compare Microsoft to your run-of-the-mill small (or even large) software shop, though. Maybe on HN, most people work on these amazingly designed systems, but in my experience most tech out there is shit and has no proper design or architecture beyond "we're doing microservices because everyone is".

> You can't compare Microsoft to your run-of-the-mill small (or even large) software shop, though. I'm talking about how Microsoft added support for connected services to Visual Studio. It's literally a tool that anyone in the world can use. They added the feature to address existing customer needs.

Apart from the fact that not everyone uses Visual Studio, "connected services" appears to be something by which you can connect to existing cloud-based services.

How does that solve the problem of a mess of interconnected services where you may have to change 3 or more of them simultaneously in order to implement a change?

Re: We're Leaving Kubernetes

#240

Post by KronisLV »

skydhash wrote: post #170
themanmaran wrote: post #165

Earlier quoted context omitted.

I bet it's less of a RAM issue, and more of an orchestration problem. Making sure you have the latest version of every microservice and it's configuration. "Oh it's not running locally, you need to also run service_18_v2.js, and include the right env variables"

This + k8s magic that seem to make thing coupled tighter.

> This + k8s magic that seem to make thing coupled tighter.

I think nobody really talks about this, but unless you have a docker-compose.yml that includes everything you need for local development, it's increasingly more likely that you'll end up coupling things to Kubernetes to such a degree that running without it (and its abstractions) will become more effort than a person can muster.

So while people try to create services that are decoupled from one another, they end up instead coupling them to Kubernetes concepts and a service mesh, service discovery, configuration and secret management mechanisms, persistent storage abstractions and so on.

Which you can obviously do if you want to, but which might make running things locally in a minimalistic fashion that much more complex.

It's the same as with for example using a web server as a reverse proxy for my applications and ending up putting some logic in there (e.g. route rewrites, headers etc.) and then realizing that I must also run a similar web server locally for 1:1 compatibility because something like Vue dev server proxy to the locally running API won't be able to give me all that.

Post reply on HN