Working with distributed teams

With Docker, anyone can replicate an environment on their local machine. Docker provides a consistent development environment for the entire team. Team members need not struggle to set up their local machines with all the needed scripts and libraries needed to start working on a project. They can simply pull a Docker image and start working in a few seconds. Since Docker containers run as a process, most IDEs can be used to connect to the running instance for any debugging of applications as needed, without having to SSH into any remote system.

Docker features such as mounting Host machine volumes and exposing ports can be leveraged for local development. A developer working on a service can focus on just that and have other dependency services run as containers, without needing to know the details of how to run them.

In our example of Issue Management System, a team working on the ims-micro-tasks (tasks) microservice may need to run the ims-micro-users microservice as a dependency. Here, the users microservice team can build an image of its service and upload it to either a public or private registry. So, the tasks microservice team can simply download/pull the image and run it as a container. Thus, teams can share their application with all the required dependencies as Docker images.

This sharing becomes more convenient when the microservices are written using different languages, or cater to different needs. As an example, a team working on the UI in Angular need not know anything about the microservices written in Java. They can simply use Docker to run the Java-based microservices as a dependency.