Zuora developers need to be able to test the microservices they are building against the Zuora Central Platform and other dependent Zuora microservices.
Currently, developers write Docker Compose files for their microservice and Zuora Central Platform; this allows them to test their code quickly against a local stack on their laptop. Although this gives developers some level of flexibility and speed, as the number of microservices continues to increase, running the stack on a commodity laptop is no longer feasible as the laptop does not have the resources to run all the microservices.
To head off this problem, we are trying to provide a framework for developers to launch quick, dynamic and customizable development environments in the cloud. In particular, we are testing a solution that reuses the existing Docker Compose files on a Docker Swarm cluster in AWS, with connectivity from the local laptop’s microservices.
The list below represents some of the requirements that we have collected from developer teams with respect to developer environments. In no particular order:
- Minimize changes developers need to make to adopt new environments
- Ability to deploy all or subset of microservices and components into an isolated environment for development and testing
- Dependency management (i.e developer pulls in microservice A, automatically pull in the Zuora Central platform and any dependent microservices)
- Ability to specify a desired version of the microservice for testing
- Run services on their laptop that can interact with the Docker Swarm cluster in the cloud
- Focus on a low cost solution
- Easy to stand up/tear down
- Use existing or create a standard for describing a microservice environment setup and dependencies
Proof of Concept & Results
We implemented a proof of concept (POC) of the Docker Swarm solution, by running the Zuora Central Platform with some of our production ready microservices. One particular goal of the POC was to validate whether we can reuse existing microservice Docker Compose files to run in a Docker Swarm cluster in the cloud.
One of the goals was to be able to stand the cluster up and minimize any changes that teams need to make to their configuration files. Another major goal of the POC was to vet out the needs and understand scope for the development environments in order to derive a strategy to auto scale or automate the environments.
Figure 1- Integrating local and cloud based developer environments
Based on the POC, as displayed in Figure 1, we were able to address most of the initial requirements including avoiding changes that are required from the microservice teams to adopt the new framework.
Furthermore, the POC vetted out that developers would be able to run their in-development containerized microservices locally while standing up any dependencies in the Swarm cluster quickly. Developers were also able to run the entire stack on the shared Swarm cluster if they wanted to - Figure 2 represents one such configuration:
With the POC completed, we continue automating the Swarm based framework. As part of our future work, we have identified two cost-based improvements that we think will make the adoption of the framework more economical:
- Ephemeral clusters - transient clusters that will expire after a certain amount of time
- Spot fleets - leveraging spare AWS capacity to run clusters on the cheap like we do for our CI environments
Zuora Infrastructure Engineering Team
Rajesh Dharmalingam, Gary Forrest, Steven Kane
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.