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

161–170 of 348 posts

Re: We're Leaving Kubernetes

#161

Post by lemme_tell_ya »

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…

> time is possibly too short (especially if you have kids) to learn new things that aren't simple, even if better

Having a kid has drastically altered my ability to learn new things outside of work, simply due to lack of time. I never could have imagined how big of an impact having a kid would be, its crazy!

The worst thing is when you actually manage to carve out some time to do some learning or experimentation with a new tool, library, etc only to find out that it sucks or you just don't have the time to pick up or whatever.

Re: We're Leaving Kubernetes

#162

Post by justinclift »

csweichel wrote: post #50
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…

OP here. There definitely is a place for running things on your local machine. Exactly as you say: one can get a great deal of consistency using VMs. One of the benefits of moving away from Kubernetes, to a runner-based architecture , is that we can now seamlessly support cloud-based and local environments ( https://www.gitpod.io/blog/introducing-gitpod-desktop ). What's really nice about this is that with this kind…

Something that's not clear from the post is whether you're running these environments on your own hardware, or layering things on top of something from a cloud provider (AWS, etc)?

Re: We're Leaving Kubernetes

#163

Post by animal_spirits »

rileymat2 wrote: post #154
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…

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

Re: We're Leaving Kubernetes

#164

Post by rileymat2 »

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

Yes, the real world trumps theory, hence my question.

Re: We're Leaving Kubernetes

#165

Post by themanmaran »

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

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"

Re: We're Leaving Kubernetes

#166

Post by halfcat »

fragmede wrote: post #145
arp242 wrote: post #120

Earlier quoted context omitted.

> the stack always grows to the point that a dev can no longer test it on their own machine So the solution here is to not have that kind of "stack". I mean, if it's all so big and complex that it can't be run on a laptop then you almost certainly got a lot of problems regardless. What typically happens is tons of interconnected services without clear abstractions or interfaces, and no one really understands this spa…

> So the solution here is to not have that kind of "stack". Reminds me of my favorites debugging technique. It's super fast: Don't write any bugs!

Quite an effective approach:

https://github.com/kelseyhightower/nocode

Re: We're Leaving Kubernetes

#167

Post by djbusby »

xcrunner529 wrote: post #138
hosh wrote: post #73

Earlier quoted context omitted.

I have used remote dev machines just fine, but my workflow vastly differs from many of my coworkers: terminal-only spacemacs + tmux + mosh. I have a lot of CLI and TUI tools, and I do not use VScode at all. The main GUI app I run is a browser, and that runs locally. I have worked on developing VMs for other developers that rely on a local IDE such. The main sticking point is syncing and schlepping source code (someth…

I am hardly a dev but occasionally have had to do some or some scripting or web stuff and have really loved VSCode and using the remote SSH support to basically feel like I’m coding locally. Does that not work for your devs?

That puts a "scary" VSCode blob on the remote-server. Some orgs do not like that, even if it's a "work" class box.

Re: We're Leaving Kubernetes

#168

Post by junkaccount »

datadeft wrote: post #12

The original k8s paper mentioned that the only use case was a low latency and a high latency workflow combination and the resource allocation is based on that. The generic idea is that you can easily move low latency work between nodes and there are no serios repercussions when a high latency job fails. Based on this information, it is hard to justify to even consider k8s for the problem that gitpod has.

Thanks for reading the paper!

Re: We're Leaving Kubernetes

#169

Post by flimsypremise »

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

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

Re: We're Leaving Kubernetes

#170

Post by skydhash »

themanmaran wrote: post #165
justinclift wrote: post #157

Earlier quoted context omitted.

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

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.
Post reply on HN