Answers: <p>I recommend running all the dependent microservices on cloud and deploy only the microservice that is under active development in your laptop.</p>
  
Answers: CC BY-SA 4.0
Answers: 2022-03-24T18:29:26.753Z
Answers: 2022-03-24T18:29:26.753Z
Answers: kaushikv
Answers: <p>There are several options for handling this and they are not exclusive of each other:</p>
  <ol>
  <li>Giving your developers machines with lots of memory and CPU, and probably GPU, is a quick way to solve problems if you have money to throw at things.</li>
  <li>Use a VPN to let users access resources in the cloud.  Hopefully you have some sort of pre-prod (aka staging) environment so they can develop against something that isn't needed by production.</li>
  <li>Shrink your containers.  Many folks start with containers that are based on an OS.  This will eat lots of memory in production and development spaces.  If you can build lighter containers it will save you money on developer machines and cloud resources.  There's tons of info on the web about ways to get your container down to what it only needs.</li>
  </ol>
  <p>I'm also a fan of inventories like service catalogs, but unless the catalog helps you make cloud services available to local devs I don't see how it is going to solve your memory contention issues.</p>
  
Answers: CC BY-SA 4.0
Answers: 2022-03-29T17:31:12.887Z
Answers: 2022-03-29T17:31:12.887Z
Answers: chicks
Body: <p>Where I work we've been adding microservices for different purposes and the local development environment is becoming difficult to setup. Services have too many environment variables to configure and usually there's not enough memory avaiable to run them.</p>
  <p>We plan to fix these issues. I understand it's a matter of architecture and DevOps mostly. One way we've thought of is to create a proper service registry that allows easier setup and opens the door to, for example, have some services running locally and others in the cloud. All wired together with the service registry.</p>
  <p>Another option could be to stub some of the dependencies with something like <a href="https://wiremock.org/" rel="nofollow noreferrer">https://wiremock.org/</a> but it seems too limited and difficult (?).</p>
  <p>I wanted to ask, what other strategies are there to manage growing development environments?</p>
  
Tags: <environments>
Title: Growing local development environment issues
UserDisplayName: David Montaño
ThreadText: # Growing local development environment issues
  
  (Asked by: username_0 on 2022-03-24)
  
  Where I work we've been adding microservices for different purposes and the local development environment is becoming difficult to setup. Services have too many environment variables to configure and usually there's not enough memory avaiable to run them.
  
  We plan to fix these issues. I understand it's a matter of architecture and DevOps mostly. One way we've thought of is to create a proper service registry that allows easier setup and opens the door to, for example, have some services running locally and others in the cloud. All wired together with the service registry.
  
  Another option could be to stub some of the dependencies with something like <https://wiremock.org/> but it seems too limited and difficult (?).
  
  I wanted to ask, what other strategies are there to manage growing development environments?
  
  **Tags:** environments
  
  
  ---
  
  ## 2 answers
  
  ### Answer by username_1 on 2022-03-24. Score: 3
  
  I recommend running all the dependent microservices on cloud and deploy only the microservice that is under active development in your laptop.
  
  
  ---
  
  ### Answer by username_2 on 2022-03-29. Score: 1
  
  There are several options for handling this and they are not exclusive of each other:
  
  1. Giving your developers machines with lots of memory and CPU, and probably GPU, is a quick way to solve problems if you have money to throw at things.
  2. Use a VPN to let users access resources in the cloud. Hopefully you have some sort of pre-prod (aka staging) environment so they can develop against something that isn't needed by production.
  3. Shrink your containers. Many folks start with containers that are based on an OS. This will eat lots of memory in production and development spaces. If you can build lighter containers it will save you money on developer machines and cloud resources. There's tons of info on the web about ways to get your container down to what it only needs.
  
  I'm also a fan of inventories like service catalogs, but unless the catalog helps you make cloud services available to local devs I don't see how it is going to solve your memory contention issues.
  
  
  ---
  
  