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

141–150 of 348 posts

Re: We're Leaving Kubernetes

#141

Post by pylua »

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…

Really? I can't imagine not running the code locally. Honestly, my company has a micro services architecture, and I will just comment out the docker-compose pieces that I am not using. If I am developing/testing a particular component then I will enable it.

How tightly coupled are these systems?

Re: We're Leaving Kubernetes

#142

Post by dthg »

bhouston wrote: post #24
spwa4 wrote: post #21

Earlier quoted context omitted.

How does the orchestration work? How do you share storage? How do the docker containers know how to find each other? How does security work? I feel like Kubernetes' downfall, for me, is the number of "enterprise" features it (got convinced into) supporting and enterprise features doing what they do best: turning the simplest of operations into a disaster.

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

Re: We're Leaving Kubernetes

#143

Post by wutwutwat »

preommr wrote: post #105
lolinder wrote: post #3

> This is not a story of whether or not to use Kubernetes for production workloads that’s a whole separate conversation. As is the topic of how to build a comprehensive soup-to-nuts developer experience for shipping applications on Kubernetes. > This is the story of how (not) to build development environments in the cloud. I'd like to request that the comment thread not turn into a bunch of generic k8s complaints. Th…

Can someone clarify if they mean development environments, or if they're talking about a service that they sell that's related to development environments. Because I don't understand most of the article if it's the former. How are things like performance are a concern for internal development environments? And why are so many things stateful - ideally there should be some kind of configuration/secret management solut…

4th paragraph in if you read the article…

> This is not a story of whether or not to use Kubernetes for production workloads that’s a whole separate conversation. As is the topic of how to build a comprehensive soup-to-nuts developer experience for shipping applications on Kubernetes.

> This is the story of how (not) to build development environments in the cloud.

Re: We're Leaving Kubernetes

#144

Post by d_sem »

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…

It's likely you haven't come across these use cases in your professional career, but I assure you its very common. My entire career has only seen projects where you need dozen to hundreds of CPU's in order to have a short feedback loop to verify the system works. I saw this in simple algorithms in automotive, to Advanced Driver Assistance Systems and machine learning applications.

When you are working on a software project that has 1,000 active developers checking in code daily and require a stable system build you need lots of compute.

Re: We're Leaving Kubernetes

#145

Post by fragmede »

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…

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

Re: We're Leaving Kubernetes

#146

Post by fragmede »

kalaksi wrote: post #111
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…

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?

Typically when you start a new dev job the company will provide you with a pre-provisioned laptop that has their security stuff setup and maybe dev tools already installed, eg source code, compilers, VMs, Nix, and a supported editor, so it's not exactly a personal machine that they're messing with.

Re: We're Leaving Kubernetes

#147

Post by epgui »

wutwutwat wrote: post #143
preommr wrote: post #105

Earlier quoted context omitted.

Can someone clarify if they mean development environments, or if they're talking about a service that they sell that's related to development environments. Because I don't understand most of the article if it's the former. How are things like performance are a concern for internal development environments? And why are so many things stateful - ideally there should be some kind of configuration/secret management solut…

4th paragraph in if you read the article… > This is not a story of whether or not to use Kubernetes for production workloads that’s a whole separate conversation. As is the topic of how to build a comprehensive soup-to-nuts developer experience for shipping applications on Kubernetes. > This is the story of how (not) to build development environments in the cloud.

I'm not sure that this really answers their question.

Re: We're Leaving Kubernetes

#148

Post by czhu12 »

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 restored everyone’s sanity.

Both FAANG companies I’ve worked at had remote dev environments that were built in house.

Re: We're Leaving Kubernetes

#150

Post by dilyevsky »

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.

> They want to do their job, and get paid

Where "job" is defined in a narrowest way possible to assume minimum responsibility. Still want to get 200k+ salaries though...

This may sound extreme (it really isn't) but as Dr of Eng TP's job was to sus those folks out as early as possible and part ways (the kind where they go work for someone else). Some folks are completely irrational about their setups and no amount of appeasement in the form of "whys" and training is usually sufficient.

Post reply on HN