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

151–160 of 348 posts

Re: We're Leaving Kubernetes

#151

Post by bhouston »

dthg wrote: post #142
bhouston wrote: post #24

Earlier quoted context omitted.

> How does the orchestration work? Github Actions CI. Take this and make a few more dependencies and a matrix strategy and you are good to go: https://github.com/bhouston/template-typescript-monorepo/blo... For dev environments, you can add post-fixes to the services based on branches. > How do you share storage? I use managed DBs and Cloud Storage for shared storage. I think that provisioning your own SSDs/HDs to th…

> But you can set up each service with a domain name and access them that way. Are you using Cloud Run domain mappings for this or something else? I have been converging on a similar stack, but trying to avoid using a load balancer in an effort to keep fixed costs low.

Yup domain mappings for now. There is some label support in Cloud Run but I haven’t explored it yet. You can also get the automatic domain name for a service via the cloud run tools.

Yeah I definitely want to also avoid a load balancer or gateway or end points as well for cost purposes.

Re: We're Leaving Kubernetes

#152

Post by kstenerud »

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…

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 feel like I needed a sacrificial chicken.

Docker may be a dumpster fire, but at least it's generally easy to see what you did wrong and fix it.

Re: We're Leaving Kubernetes

#153

Post by vinnymac »

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!

Code is a liability. Not writing code is one of the best things a developer can do on any particular day, aside of course from deleting it ;)

Re: We're Leaving Kubernetes

#154

Post by rileymat2 »

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…

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)

Re: We're Leaving Kubernetes

#155

Post by cryptonector »

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…

I've no problem with remote dev envs for most things. But they have to be VMs in many cases, not containers.

Re: We're Leaving Kubernetes

#156

Post by dboreham »

richards wrote: post #16
candiddevmike wrote: post #14

Earlier quoted context omitted.

You know that Cloud Run is effectively a Kubernetes PaaS, right?

Google employee here. Not the case. Cloud Run doesn't run on Kubernetes. It supports the Knative interface which is an OSS project for Kubernetes-based serverless. But Cloud Run is a fully managed service that sits directly atop Borg ( https://cloud.google.com/run/docs/securing/security ).

Parent said "effectively", which it appears you confirm.

Re: We're Leaving Kubernetes

#157

Post by justinclift »

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…

> 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't really an option.

Re: We're Leaving Kubernetes

#158

Post by worthless-trash »

jrockway wrote: post #137
maxrecursion wrote: post #130

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" Isn't this problem solved by CICD? When the developer is ready to test, they make a commit, and the pipeline deploys the code to a dev/test environment. That's how my teams have been doing it.

This turns a 1 hour task into a 1 day task. Fast feedback cycles are critical to software development. I don't quite understand how people get into the situation where their work can't fit on their workstation. I've worked on huge projects at huge tech companies, and I could run everything on my workstation. I've worked at startups where the CI situation was passing 5% of the time and required 3 hours to run, that yo…

You just need faster tests. ;)

Also, if you're booting kernel or device drivers you need the hardware. Some of this is not desktop hardware.

Re: We're Leaving Kubernetes

#159

Post by rossjudson »

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…

The stack(factory) must grow.

Re: We're Leaving Kubernetes

#160

Post by justinclift »

arp242 wrote: post #120
0xbadcafebee wrote: post #57

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…

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

That kind of mess sounds super dangerous from a production perspective too.

With things that messy it's fairly likely there would be dependency loops or problems (thundering herd, etc) trying to get things going from a cold start.

ie after a complete outage or similar for whatever reason

Post reply on HN