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

301–310 of 348 posts

Re: We're Leaving Kubernetes

#301

Post by Neikius »

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)

Yes, exactly.

I just also like to have an option to run service locally and connect to either cloud instances (test) or local instances depending on what I am troubleshooting/testing. Much better than debugging on prod which may still be required at some point but hopefully not often.

Re: We're Leaving Kubernetes

#302

Post by marcosdumay »

therealdrag0 wrote: post #297
animal_spirits wrote: post #292

Earlier quoted context omitted.

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.

Just s/Sales/Management, because sales actually can't wag the development process. But yeah.

Re: We're Leaving Kubernetes

#303

Post by kgeist »

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

It has OpenSearch, RabbitMQ, Redis, MySQL

Re: We're Leaving Kubernetes

#304

Post by nitwit005 »

rtpg wrote: post #223
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)

This is how you get to "I wrote to the spec, it's your problem that clicking the button doesn't do the thing". Huge feedback loops. When you run it "locally" enough you can do your integration stuff before you even ask for review.

That doesn't seem possible to me. If you have a feature that involves 10 teams and 10 services, nothing will actually work until the 10th change is made (assuming everything was done perfectly).

Re: We're Leaving Kubernetes

#305

Post by pxc »

jrockway wrote: post #263
pxc wrote: post #183

Earlier quoted context omitted.

> I think a lot of things are dynamically linked and they include their own /usr/lib tree with the entire transitive dependency chain for that particular app, even if other things you have installed have some overlap with that dependency chain. I prefer the approach of statically linking everything and only including what you need. Wherever there's such overlap, those dependencies are already shared. Static linking i…

Just to answer your edit, nope, I wasn't mixing distros or anything. It would either be all Nix or all Debian.

Got it. Yeah, that would likely be easiest to resolve by exploring the closure with nix-tree and looking at how to eliminate or split dependencies. But pkgsStatic can be a handy fallback option too.

Re: We're Leaving Kubernetes

#306

Post by dns_snek »

dns_snek wrote: post #222
flimsypremise wrote: post #169

Earlier quoted context omitted.

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

According to whom? How do those microservices get anything done if they just live in their own isolated world where they can't depend on (call out to) any other microservice?

Would anyone care to explain the reasoning behind their down votes?

Re: We're Leaving Kubernetes

#307

Post by Tainnor »

chipdart wrote: post #299
Tainnor wrote: post #239

Earlier quoted context omitted.

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

Your whole argument boils down to "don't write shit software" which yeah, fair, but in the real world, the company that you just joined has shit code that evolved over 10 years and has accumulated all sorts of legacy cruft. The idea that there is "absolutely no need to launch a set of ad-hoc self-contained services to run a service locally and work on it" just doesn't match the reality of most places I've worked at. You either got very lucky or you didn't work on complex enough systems.

Re: We're Leaving Kubernetes

#308

Post by Tainnor »

therealdrag0 wrote: post #297
animal_spirits wrote: post #292

Earlier quoted context omitted.

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.

Most of the time it's bad engineering caused by other engineers.

Re: We're Leaving Kubernetes

#309

Post by Tainnor »

OrderlyTiamat wrote: post #284
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…

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

> Then what was the point?

Resume chasing and trying to paper over the fact that you don't understand architecture, plus bad tooling that e.g. doesn't properly support incremental compilation and so makes monoliths painful.

Re: We're Leaving Kubernetes

#310

Post by Tainnor »

nitwit005 wrote: post #304
rtpg wrote: post #223

Earlier quoted context omitted.

This is how you get to "I wrote to the spec, it's your problem that clicking the button doesn't do the thing". Huge feedback loops. When you run it "locally" enough you can do your integration stuff before you even ask for review.

That doesn't seem possible to me. If you have a feature that involves 10 teams and 10 services, nothing will actually work until the 10th change is made (assuming everything was done perfectly).

If you have one team per service, yes. In many companies, you may have one team and 10 services though. I wish I was making this up.
Post reply on HN