Live data from Hacker News

We're Leaving Kubernetes

gitpod.io

211–220 of 348 posts

Re: We're Leaving Kubernetes

#211

Earlier quoted context omitted.

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…

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

Re: We're Leaving Kubernetes

#212

  >Kubernetes seems like the obvious choice for building out remote, standardized and automated development environments
- Is it really Obvious Choice™ though Fred?

- Hmm, let's consult the graphs.

  >Kubernetes is a container orchestration system for automating software deployment.
- It's about automating deployment Carl, not development environments!

  >Kubernetes is not the right choice for building development environments, as we’ve found.

Re: We're Leaving Kubernetes

#213

Earlier quoted context omitted.

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…

I watched all the videos, read all the tutorials (including the "super easy" ones). I understand the Nix language, but the actual infrastructure is just so damn convoluted and fragile, the error feedback mechanisms are worse than useless, and the documentation assumes that you already know everything inside and out. It reminds me of the bad old days of the neckbeard gatekeepers.

I'll take a look at guix, though...

Re: We're Leaving Kubernetes

#214

Earlier quoted context omitted.

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

If the microservice has dependencies on other services it is not a microservice.

Connecting to a messaging queue or database count as a dependency?

Why not break a microservice into a series of microservices, its microservices all the way down.

Re: We're Leaving Kubernetes

#215
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…

> 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. This is certainly one of the critical mistakes you did. No developer needs to launch half of the company's services to work on a local deployment. That's crazy, and awfully short-sighted. The only services a dev…

Ha. It almost looks like either the fan boys or PR department is making up use-cases.

Yes what you're saying is correct, but why many words when few do trick:

This hypothetical IT department isn't able to host its own development environment, yet suddenly they do have the skills if they switched to gitpod.

Re: We're Leaving Kubernetes

#216
post #202

Earlier quoted context omitted.

UNIX, and other competing timesharing systems of the time, have always been remote first, with Windows catching up with Citrix, followed by RDP, and nowadays finally headless as well. Nowadays Web frontends and SSH/cloud shell, have replaced what used to be X Windows / telnet / rsh, but the underlying workflows aren't much different than running an IDE / emacs /vi / joe /... from a UNIX development server in a 1990's…

The funniest (?) thing to me about all this: we're still hoping, if we do things right, to replicate the technology (terminals) from 50 years ago . I honestly don't understand why nobody has simply invented some software to solve this problem, after 50 years.

Add to it the whole TUI fashion, as if we weren't doing them already 50 years ago.

We did, it is called GUI and language REPLs, like Smalltalk and Interlisp-D development enviroments, with graphical based terminals, not dependent on replicating virtual teletypes.

Still something that seems problematic to take off the way it should.

Re: We're Leaving Kubernetes

#217
post #87

Earlier quoted context omitted.

Serious time to set up _and_ maintain as the project changes. At least, that was my experience. I really _want_ to have Nix-powered development environments, but I do _not_ want to spend the rest of my career maintaining them because developers refuse to "seriously dig" to understand how it works and why it decided to randomly break when they added a new dependency. I think this approach works best in small teams whe…

This may be the one area where some form of autocracy has merit :-)

What's that saying about developers and herding cats? :)

Re: We're Leaving Kubernetes

#218
post #148

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…

[deleted]

Re: We're Leaving Kubernetes

#219

Earlier quoted context omitted.

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…

> 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 read that I'd characterize as incomplete are Apple's.¹

> 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?

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, often by people who only differ from them in being more willing/able to read the docs. Isn't that extremely obvious?

> unreadable documents

Reading isn't a singular skill— each genre requires its own skills, and you gradually pick those up by reading in that genre. Reading novels doesn't much prepare you to read math textbooks, but that doesn't make all math textbooks 'unreadable'.

The same things goes for skimming. Skimming a text is likewise a (set of) genre-specific skill(s), built up through practice.

Frankly, moving from your terminal to your web browser to look up how to use a CLI tool is only consistently faster than working with the docs native to that CLI environment (man pages, info pages, usage messages, --help flags, help subcommands, tldr pages, etc.) if you have don't have very good reading skills in the genres of those native docs.

As someone who does not have difficulty skimming or navigating manpages quickly, when someone tells me that digging through StackOverflow seems like less of a waste of time than reading docs and so they never read docs, I have to wonder if the real issue is that a reading skills deficit is caught in a self-reinforcing loop.

And indeed, a trip to StackOverflow never ends at StackOverflow for a person with much curiosity. Because even if a curious person finds a solution to their immediate problem, they will wonder things like:

  - is this solution outmoded by some other fix?
  - how is the feature/option/change used in this solution actually supposed to work?
  - are there any alternatives I should know about?
  - if I wanted to do things slightly differently, could I still use the method/feature/option referenced in this solution? does it have any parameters that are easy to swap or tweak?
  - is this scenario what the feature/method/option in the solution is actually intended for? should I care?
... and the quickest way to answer questions like that is usually a glance at a manual.

-----

1: In some cases with GNU stuff the literal `man` pages are abridged versions of the `info` pages. But even then, the `man` pages direct you to `info` pages. It's not like they leave you having.

Re: We're Leaving Kubernetes

#220
post #116

Earlier quoted context omitted.

I strongly recommend just switching the Dev environment over to Linux and taking advantage of tools like "distrobox" and "toolbx". https://github.com/89luca89/distrobox https://containertoolbx.org/ It is sorta like Vagrant, but instead of using virtualbox virtual machines you use podman containers. This way you get to use OCI images for your "dev environment" that integrates directly into your desktop. https://podman…

If you're doing this, there are many cases where you might as well just spin up a decent Linux server and give your developers accounts on that? With some pretty basic setup everyone can just run their own stuff within their own user account. You'll run into occasional issues (e.g. if everyone is trying to run default node.js on default port) but with some basic guardrails it feels like it should be OK? I'm rememberi…

The painful part of that setup is that all the tools you want to use on the source code must either run on the server itself, thus installed somehow, or some slow remote mounted filesystem, this severely limits the tools you may want to use.
Post reply on HN