Daniel Bryant has written a good article on how to work/develop locally when you are working with a microservice architecture.
He says there are five patterns:
- the naive (painful) approach
- local ‘profiles’ combined with mocking and stubbing
- service virtualization
- environment leasing
I’ve encountered some of these techniques before in my career. The first naive approach usually works when you’re dealing with RESTful APIs of 3rd party services. The second approach with local profiles works mainly when you’re focusing on your part of the system and don’t really care about the integration and what happens with other services; for example, I don’t need my payment processor to be up and running when I’m working on the website content and layout.
The third approach, service virtualization, is something I’ve used on an open source project (fogbugz-mode) and on client projects when working with internal APIs that our team didn’t have much ownership of. We captured the JSON responses from the services for various calls and then would play those back later through our virtualized service. On one project we had a 5 stage process where we had to make 1 or more API calls at each step. Using JSON responses that were identical to real responses from the services helped greatly in making sure we could test the 5 stage process locally without interrupting other developers or the client whose API we were using. The biggest improvement though is speed; if the API call takes 10 seconds, locally it will only take 1 second. That 5 stage process can take 1 minute to test instead of 10 minutes.
The fourth approach, “Production in a box”, of using Docker or prepackaged virtual machines/appliances isn’t used often. Maybe it’s because most deployments still don’t use appliances or Docker which means there’s some infrastructure to setup and work on before this approach can be used. However the advantages of using this approach are great:
The ‘production-in-box’ pattern also allows us to keep a much cleaner local developer environment, and also removes potential configuration clashes by encapsulating a service and its dependencies and configuration (e.g. different requirements of Java version).
The fifth approach, environment leasing, leans closer to duplicating the production development. My friends who work at larger companies have used this setup because their deployment process supports it. To deploy the services they depend on to AWS EC2 (Amazon Web Services) or to Google Cloud or to a private cloud is easy to do with a few commands or clicks of the mouse.
The ‘platform leasing’ pattern is an advanced pattern, and does rely on the ability to provision platform environments on-demand (e.g. private/public cloud with elastic scaling), and also requires that a developer’s machine has a stable network connection to this environment
However, most companies will not have this kind of setup. Some of them may use EC2 or private cloud for deployment but will restrict developers from creating more virtual machines for local development.