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

191–200 of 348 posts

Re: We're Leaving Kubernetes

#191

Post by chipdart »

animal_spirits wrote: post #163
rileymat2 wrote: post #154

Earlier quoted context omitted.

I may be misunderstanding, but wouldn't you want the particular microservice you are working on independent enough to develop locally, then deploy into the remote environment to test the integration? (I don't work at this scale)

Invariably this is an ideal and does not match up in reality. I work at ~50 ish employee company and we have layers of dependencies between at least 6 or 7 various microservices. I can see this adding up in complexity as the product scales

> 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 earth do you believe one of the most basic traits of backend development is unreal?

> I work at ~50 ish employee company and we have layers of dependencies between at least 6 or 7 various microservices.

Irrelevant. Each service has dependencies and consumers. When you need to run an instance of one of those services locally, you point it to it's dependencies and you unplug it from it's consumers. Done. This is not rocket science.

Re: We're Leaving Kubernetes

#192

Post by pmarreck »

kalaksi wrote: post #184
pxc wrote: post #180

Earlier quoted context omitted.

> From my perspective, installing Nix seems pretty invasive. How so? With what other software does Nix interfere?

From the provided link: > Nix requires a broad set of changes to your system, from creating new users to installing and running a daemon to creating a root volume and beyond

The daemon and the users are only to run a build when that is necessary. It might seem invasive but it works out pretty well.

Re: We're Leaving Kubernetes

#193

Post by pmarreck »

kstenerud wrote: post #152
pmarreck wrote: post #88

Earlier quoted context omitted.

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…

After my personal 2-year experiment with NixOS, I'd avoid anything Nix like the plague, and would be looking for a new job if anyone instituted a Nix-only policy. It's not the learning new things that's a problem, but rather the fact that every little issue turns into a 2-day marathon that's eventually solved with a 1-line fix. And that's because the feedback loop and general UX is just awful - I really started to fe…

Literally every Docker image you've ever downloaded comes from a build that only worked (essentially) "by accident."

If Docker builds were as deterministic as Nix, then all that would need to be distributed would be Dockerfiles and perhaps a cache of base images somewhere.

Looking at a build as a pure function where each dependency (including any compiler(s), plus the environment), are "input arguments" to it, was a revelation (since I already realized the advantages of pure functions while working in functional languages).

Running a Dockerfile and hoping to get a working image out of it is like running a function which checks the time when it runs and errors when the seconds end in 0 due to a bug.

> every little issue turns into a 2-day marathon that's eventually solved with a 1-line fix

There is spotty education in the space. Did you ever take this (very cool) Nix tutorial? Not actually understanding Nix is going to make any troubleshooting of Nix much harder. https://nixcloud.io/tour/

> I really started to feel like I needed a sacrificial chicken.

Have you looked at Guix? A lot of people think it's "Nix without the warts." Plus it uses a Lisp, which some people prefer, or can at least grok better than the Nix language. https://guix.gnu.org/

Re: We're Leaving Kubernetes

#194

Post by OneCricketeer »

rahen wrote: post #102

Kubernetes works great for stateless workloads. For anything stateful, monolithic, or that doesn't require autoscaling, I find LXC more appropriate: - it can be clusterized (LXD/Incus), like K8S but unlike Compose - it exposes some tooling to the data plane, especially a load balancer, like K8S - it offers system instances with a complete distribution and a init system, like a VM but unlike a Docker container - it ca…

Nomad cannot orchestrate what, exactly? https://developer.hashicorp.com/nomad/tutorials/plugins/plug...

Re: We're Leaving Kubernetes

#195

Post by pmarreck »

rfoo wrote: post #98
pmarreck wrote: post #88

Earlier quoted context omitted.

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…

In a worse world, worse is better.

this is such an awful truth to even say aloud lol but... yeah.

which is why you gotta find your peeps that believe in the better world and are thus believing it into existence. (OT: reminds me of this song title: https://soundcloud.com/anjunabeats/mat-zo-see-it-when-i-beli...)

Re: We're Leaving Kubernetes

#196

Post by chipdart »

sgarland wrote: post #133
pmarreck wrote: post #88

Earlier quoted context omitted.

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…

People just straight-up don’t want to learn. There are always exceptions, of course, 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.

> 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 take is particularly absurd considering the topic: engineers working on distributed services.

Do you actually believe that you build up enough knowledge on this topic to become a professional in the field if you "straight-up don't want to learn"? There is not a single developer in the field who, at least to some degree, is not self-taught.

> They want to do their job, and get paid.

Everyone wants to get paid. Do you know anyone who works non-profit?

What you're failing to understand is the "do their job" part. Software developers are trained to solve the problems they face, and not waste time with the problems they do not have. Time is precious, and they invest it where it has the largest return on investment.

> Reading man pages is sadly not in that list.

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.

Why do you think sites like Stack overflow is so popular? Because all those "incurious" people in tech feels the need to ask questions and dig through answers on how to solve problems?

I think you're just picking a very personal definition of competence which conveniently boils down to "do the things I do, and do not do the things I don't". Except the bulk of the people in the field is smart, and some have already solved problems that you aren't aware exist, such as wasting precious time deciphering unreadable documents that are systematically out of date.

Re: We're Leaving Kubernetes

#197

Post by pmarreck »

bamboozled wrote: post #114
pmarreck wrote: post #88

Earlier quoted context omitted.

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…

Try Devbox, you can basically ignore nix entirely and reap all the benefits.

When I looked at it, I encountered some problem that unfortunately slips my mind now.

Re: We're Leaving Kubernetes

#198

Post by herewulf »

pmarreck wrote: post #190
kalaksi wrote: post #111

Earlier quoted context omitted.

From my perspective, installing Nix seems pretty invasive. I can understand if someone doesn't want to mess with their system "unnecessarily" especially if the tool and it's workings are foreign. And I can't really remember the last time I had issues with non-deterministic dependencies either. Dependency versions are locked. Maybe I'm missing something?

> installing Nix seems pretty invasive I'm writing a test to check whether a tool I'm writing can work without Nix (it works with it perfectly, but I want it to also work without it because there are a lot of folks like you, and like me about 3 years ago, who still think they'd rather struggle with manually installing the right glibc that goes with the right python dependency installed with the right pip and venv ver…

Guix uses GRUB like most distros (but is scripted a bit to allow booting earlier generations of the system). The init system is Guile (Shepherd).

Fewer packages, yes, but the packages are by far the most common ones. It's easy to add packages for yourself, if needed. Nonguix channel and others for stuff upstream won't accept.

I believe Guix is innovating on a number of things in relation to Nix these days. So I've heard. I don't know much about Nix, honestly.

I heartily agree with your last paragraph in the case of Guix.

Re: We're Leaving Kubernetes

#199

Post by weikju »

loujaybee wrote: post #23
ensignavenger wrote: post #8

The article does a great job of explaining the challenges they ran into with Kubernetes, and some of the things they tried... but I feel like it drops the ball at the end by not telling us at least a little what they chose instead. The article mentions they call their new solution "Gitpod Flex" but there is nothing about what Gitpod Flex is. They said they tried microVMs and decided against them, and of course Kubern…

Yeah, that's fair. The blog was getting quite long, so we need to do some deeper dives in follow-ups. Gitpod Flex is runner-based. The runner interface is intentionally generic so that we can support different clouds, on-prem or just Linux in future. The first implemented runner is built around AWS primitives like EC2, EBS and ECS. But because of the more generic interface Gitpod now supports local / desktop environm…

What’s a “runner”?
Post reply on HN