Live data from Hacker News

We're Leaving Kubernetes

gitpod.io

291–300 of 348 posts

Re: We're Leaving Kubernetes

#291

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.

True. Your run-of-the-mill shop should have a simpler and more straight-forward system.

But you seem to want the reverse.

Re: We're Leaving Kubernetes

#292

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. True. Your run-of-the-mill shop should have a simpler and more straight-forward system. But you seem to want the reverse.

No one wants the reverse, I would love if my microservices were perfectly isolated little boxes with known inputs and outputs! That would make my life easier. But I don’t have the ownership over the planning process and our sales person already told our customer we’d have the new feature they asked for that no one on the engineering team knew about delivered by next sprint. It would be nice if my company planned things well! But they don’t

Re: We're Leaving Kubernetes

#293

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…

> you either insist on it and say it's the only supported developer-environment-defining framework, or you will lose control over it

That's true for any architectural decision in an organization with more than 1 person.

It's really not something that should make you reconsider a decision. At the end of the day, an architecture that "people" actually want to use doesn't exist, "people" doesn't want any singular thing.

Re: We're Leaving Kubernetes

#294
post #77

On a side note: has anybody experience with MicroK8s? I'd love to learn stories about it. I'm interested in both dev and production experiences.

Microk8s is nothing but a kubernetes distro from canonical. Personally I would use k3s because it’s a little more widespread and less opinionated in a good way.

Anyway, as always it depends on what you want to use it for.

Re: We're Leaving Kubernetes

#295
Regardless how you edit/compile your code, you still need to debug/troubleshoot problems in production, and that is very likely to use Kubernetes. So the more reasonable approach seems to be: first, figure out how do you troubleshoot/identify/mitigate a problem in production, then reproduce it in development environment and work to fix it at daytime. When you have instrumented your app for reasonable debugging experience then using these tools on development machine becomes much easier problem, K8s or not.

Re: We're Leaving Kubernetes

#296
post #234

Earlier quoted context omitted.

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 count…

It depends on the application. I've worked at places where the main application being written needs 128GB to run. Another where it's computationally intense and will take hours for a single run on anything but the most massive machines. Another where the dataset is huge and simply being remote makes the bandwidth requirements untenable unless you live across from a data center. I've seen teams just accept their workflow will take 15 minutes each time they run their app because they're copying stuff from remote each time. Remote dev gives you as beefy a machine as you want, with the fastest network and lowest bandwidth.

But that's only the resource problem. Another problem I have seen my entire career, is devs can't keep their machines configured the same. They have different model laptops, they don't pin their app versions, they configure and install things by hand. Each time they change something by accident it takes them hours, days, sometimes weeks, to get it working again. That also can lead to bugs developing the app, which wastes a huge amount of time.

And then there's the fact that their local copy runs completely differently than it does in production. This leads to the app being written with certain assumptions about how it runs, that turn out to be false in production. I've seen this lead to catastrophe, as well as just weeks to months of wasted time, trying to track down issues. This is an undeniable, existential issue.

Finally, it's rare for local setups to be secure. Often devs get too much access from their local machines, and this is stolen by infostealer malware and compromise happens. A protected remote environment is easier to secure. A lot of development is hampered by all the crappy corporate security tools that's on laptops now. Remote dev allows you to bypass all that and have a fully working yet protected network without restrictions.

Is remote dev a pain? Right now, yeah, because nobody has made it be less painful. So of course it's easier on the local machine. But it's not ideal. I'm sure eating with a spoon was more painful than eating with your hands, until forks were popularized in the 18th century. Change took a long time, but I think most of us prefer the change once new tools became widely available.

Re: We're Leaving Kubernetes

#297

Earlier quoted context omitted.

> You can't compare Microsoft to your run-of-the-mill small (or even large) software shop, though. True. Your run-of-the-mill shop should have a simpler and more straight-forward system. But you seem to want the reverse.

No one wants the reverse, I would love if my microservices were perfectly isolated little boxes with known inputs and outputs! That would make my life easier. But I don’t have the ownership over the planning process and our sales person already told our customer we’d have the new feature they asked for that no one on the engineering team knew about delivered by next sprint. It would be nice if my company planned thin…

So then it’s bad engineering being wagged by Sales, not some expected sane choice.

Re: We're Leaving Kubernetes

#298

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…

Shouldn't all systems be tested end-to-end regardless of if they are microservices or not?

You don’t have to test them all end to end before merging a PR. You should have multiple stable pre prod environments for e2e testing. But if most changes fail e2e testing then your sdlc is broken before then and that should be fixed first. You need better designs and better collaboration and better local tests and code reviews.

Re: We're Leaving Kubernetes

#299

Earlier quoted context omitted.

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

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

Yes. That's the point.

> How does that solve the problem of a mess of interconnected services (...)

I don't think you got the point.

The whole point is that you only need to connect your local deployment to services that are up and running. There is absolutely no need to launch a set of ad-hoc self-contained services to run a service locally and work on it. That is the whole point.

Post reply on HN