4 ms·

> Trying to boot the full service on a single machine required every single developer in the company installing ~50ish microservices on their machine, for thing

> 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 developer ever needs to launch locally are the ones that are being changed. Anything else they can consume straight out of a non-prod development environment. That's what non-prod environments are for. 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. > I guess one can grumble about bad architecture all day but this had to be solved. Yes, it needs to be solved. You need to launch your service locally while consuming dependencies deployed to any cloud environment. That's not a company problem. That's a problem plaguing that particular service, and one which is trivial to solve. > Both FAANG companies I’ve worked at had remote dev environments that were built in house. All FANG companies I personally know had indeed remote dev environments. They also had their own custom tool sets to deploy services locally, either in isolation or consuming dependencies deployed to the cloud. This is not a FANG cargo cult problem. This is a problem you created for yourself out of short-sightedness and for thinking you're too smart for your own good. Newbies know very well they need to launch one service instance alone because that's what they are changing. Veterans know that too well. Why on earth would anyone believe it's reasonable to launch 50 services to do anything at all? Just launch the one service you're working on. That's it. If you believe something prevents you from doing that, that's the problem you need to fix. Simple. Crazy.

athrowaway3z 2y ago
Ha. It almost looks like either the fan boys or PR department is making up use-cases. Yes what you're saying is correct, but why many words when few do trick: This hypothetical IT department isn't able to host its own development environment, yet suddenly they do have the skills if they switched to gitpod.
mattacular 2y ago
> 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 up dev/test/etc data that has accumulated, etc. Then you are back to thinking of provisioning isolated cloud environment per dev.
- redman25 2y ago
  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.
  - Capricorn2481 2y ago
    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.
    - chipdart 2y ago
      > You often can't just go off dev because other people use it while you're testing. Why do you think that other people using a cloud environment prevents you from using the environment?
- OrderlyTiamat 2y ago
  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?
alanwreath 2y ago
I’m sure there are legion ways to do this. For our company, it was Tilt + Telepresence. Locally, we ran our local service with Tilt. The service we ran would often need access to some other service(s), which would have been hard/impossible to bring up in conjunction with their own rabbit hole of dependencies. Thus, those dependency services were made available to the local k8s installation via Telepresence. That way, locally running services could access their dependent services as if they were running in the local environment (even though they were actually running in the cloud). In our case, security teams would only allow us stage environments, but that was enough for most everything.

athrowaway3z 2y ago

Ha. It almost looks like either the fan boys or PR department is making up use-cases. Yes what you're saying is correct, but why many words when few do trick: This hypothetical IT department isn't able to host its own development environment, yet suddenly they do have the skills if they switched to gitpod.

mattacular 2y ago

> 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 up dev/test/etc data that has accumulated, etc. Then you are back to thinking of provisioning isolated cloud environment per dev.

redman25 2y ago
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.
- Capricorn2481 2y ago
  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.
  - chipdart 2y ago
    > You often can't just go off dev because other people use it while you're testing. Why do you think that other people using a cloud environment prevents you from using the environment?
OrderlyTiamat 2y ago
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?

alanwreath 2y ago

I’m sure there are legion ways to do this. For our company, it was Tilt + Telepresence. Locally, we ran our local service with Tilt. The service we ran would often need access to some other service(s), which would have been hard/impossible to bring up in conjunction with their own rabbit hole of dependencies. Thus, those dependency services were made available to the local k8s installation via Telepresence. That way, locally running services could access their dependent services as if they were running in the local environment (even though they were actually running in the cloud). In our case, security teams would only allow us stage environments, but that was enough for most everything.