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

281–290 of 348 posts

Re: We're Leaving Kubernetes

#281

Post by Capricorn2481 »

redman25 wrote: post #276
mattacular wrote: post #273

Earlier quoted context omitted.

> You launch your local service locally, you consume whatever you need to consume straight from a cloud environment, you test the contract with a local test set, and you deploy the service. That's it. If your services are mostly stateless and/or your development team is very small that can work. If not, you will quickly run into problems sharing the data. Making schema changes to the shared cloud services. Cleaning u…

You can always spin up several services locally or if you have a development cluster run the service you are working on locally against development services.

You're going in circles. That is what the commenter is replying to. You often can't just go off dev because other people use it while you're testing, and you're back to just launching everything yourself.

Re: We're Leaving Kubernetes

#282

Post by stephenr »

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 always grows to the point that a dev can no longer test it on their own machine

Sounds like you have a different problem.

CPU resources required to run your stack should be very minimal if it's a single user accessing it for local testing idle threads don't consume oodles of cpu cycles to do nothing.

Memory use may be significant even in that case (depending on your stack) but let's be realistic. If your stack is so large that it alone requires more memory than a dev machine can spare with an IDE open, the cost of providing developers with capable workstations will pale in comparison to the cost of running the prod environment.

I have a client whose prod environment is 2x load balancer; 2x app server; 3x DB cluster node - all rented virtual machines. We just upgraded to higher spec machines to give headroom over the next couple of years (ie most machines doubled the RAM from the previous generation).

My old workstation bought in 2018 had enough memory that it could virtualise the current prod environment with the same amounts of RAM as prod, and still have 20GB free. My current workstation would have 80+ GB free.

In 95% of cases if you can't run the stack for a single user testing it, on a single physical machine, you're doing something drastically wrong somewhere.

Re: We're Leaving Kubernetes

#283

Post by stephenr »

Tainnor wrote: post #228
kgeist wrote: post #76

Earlier quoted context omitted.

We have a project which spawns around 80 Docker containers and runs pretty OK on a 5 year old Dell laptop with 16GB RAM. The fans run crazy and the laptop is always very hot but I haven't noticed considerable lags, even with IntelliJ running. Most services are written in Go though and are pretty lightweight.

> Most services are written in Go though and are pretty lightweight That's probably the difference. Throw elasticsearch, kafka and a bunch of Java services in and you'll be easily exhausting your RAM (at least at startup).

16GB of RAM is hardly a gargantuan amount in 2024 - it's not unreasonable to expect someone running a local dev environment to have a more practical amount. I wouldn't buy (or recommend) any machine for dev work with less than 64GB in 2024.

Re: We're Leaving Kubernetes

#284

Post by OrderlyTiamat »

mattacular wrote: post #273
chipdart wrote: post #187

Earlier quoted context omitted.

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

> You launch your local service locally, you consume whatever you need to consume straight from a cloud environment, you test the contract with a local test set, and you deploy the service. That's it. If your services are mostly stateless and/or your development team is very small that can work. If not, you will quickly run into problems sharing the data. Making schema changes to the shared cloud services. Cleaning u…

What was the point of microservice architecture if you can't develop each service individually in the first place? Sounds to me like the architecture you're talking about isn't an actual microservice, and it's just ball 'o mud over TCP instead of as a single monolith.

At a previous place of work I worked with a monolith structure, and it was actually perfectly fine. Development got done separately on several large substructures in the monolith, and devs could install the whole project locally and run it just fine.

I'm really wondering why we're all using microservice architecture if we're all convinced that to actually develop on them, devs need to reproduce 50odd of those services locally for debugging. Then what was the point?

Re: We're Leaving Kubernetes

#285

Post by [deleted] »

gchamonlive wrote: post #269
Kye wrote: post #249

Earlier quoted context omitted.

What ever happened to make? It seems like so much of what developers do now just duplicates what could be done with a single makefile that pokes around, figures out what you need, and makes a script to set it up.

"Use make" advices start so sound a lot like fetish and disregard the actual challenges. Make is just a framework for you to do your builds. Sure you can cram anything into it, but that is exactly the kind of area that other tools like Ansible or even Terraform shine. Make isn't a silver bullet. EDIT: Just to make sure, I'm using fetish as something you spend an unreasonable amount of time with it.

[deleted]

Re: We're Leaving Kubernetes

#288

Post by fensgrim »

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…

> how a developer manages assets like source code

IMO there are some workloads, where it is beneficial for a developer to have access to a local repository with at least some snippets based on previous projects.

Having a leftover PoC of some concept written for a previous employer but never elevated to team use/production is both handy (at least to confirm that the build environment is still viable after an unspecified period of toolchain updates) and ethical (copying production code is not ethical - even if the old and new products are vastly different e.g. last job was taxi app, new app is banking app).

Making it all 'remote' and 'cloud' will eventually result in a bike reinvention penalty on each new employment - not everything can be rebuilt from memory only, especially things that are done 1-2 times a year; sure there is open-source documentation/examples, but at some point it'll just introduce even heavier penalty for a need to either know a lot of opensource stuff to have some reference points, or to work on a pet projects to get the same amount of references.

Re: We're Leaving Kubernetes

#289

Post by scarface_74 »

fensgrim wrote: post #288
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…

> how a developer manages assets like source code IMO there are some workloads, where it is beneficial for a developer to have access to a local repository with at least some snippets based on previous projects. Having a leftover PoC of some concept written for a previous employer but never elevated to team use/production is both handy (at least to confirm that the build environment is still viable after an unspecifi…

Are you suggesting that you should enable the employee to move work done on company time and that is the company’s IP to a new company?

And the new company would also be liable for using trade secrets that they shouldn’t.

Re: We're Leaving Kubernetes

#290

Post by fensgrim »

scarface_74 wrote: post #289
fensgrim wrote: post #288

Earlier quoted context omitted.

> how a developer manages assets like source code IMO there are some workloads, where it is beneficial for a developer to have access to a local repository with at least some snippets based on previous projects. Having a leftover PoC of some concept written for a previous employer but never elevated to team use/production is both handy (at least to confirm that the build environment is still viable after an unspecifi…

Are you suggesting that you should enable the employee to move work done on company time and that is the company’s IP to a new company? And the new company would also be liable for using trade secrets that they shouldn’t.

Neither, it's unethical and there's no possibility of doing that in legal way.

However I do write 1-2 hour PoCs on my spare time and my own equipment, using only publicly available stuff - they sometimes come handy at some point later. If we assume 'remote first' development is okay - with no possibility to test stuff locally, well, we're back to either bookmark managers or pet projects to keep at least a bit of knowledge between jobs.

Post reply on HN