From “Works on My Machine” to Isolated and Consistent Development with Docker Compose – Part Two
In modern systems, backend applications rarely operate in isolation. A full-fledged development environment usually requires multiple components: PostgreSQL, Redis, Kafka, and various microservices. Without containerization, this can mean installing a significant amount of software directly on the developer’s machine. Moreover, different projects may require different versions of the same tool. For example, one project may […]
Technologies
In modern systems, backend applications rarely operate in isolation.
A full-fledged development environment usually requires multiple components: PostgreSQL, Redis, Kafka, and various microservices. Without containerization, this can mean installing a significant amount of software directly on the developer’s machine. Moreover, different projects may require different versions of the same tool.
For example, one project may use PostgreSQL 14, while another uses PostgreSQL 16. One may use a specific version of Kafka, while another uses a newer version. Docker allows developers to avoid turning their local computer into a set of manually installed databases, message brokers, and other infrastructure tools. The necessary components can be run in separate containers and stopped when they are no longer needed.
Docker also allows developers to run not only infrastructure components but also other microservices locally.

Suppose a developer is working on an Order Service, but to test a certain scenario, they also need a Payment Service and a Notification Service. If these services can be containerized and run locally, the developer gets a small local fragment of the system that is needed specifically for their work. In this case, there is no need to run the entire system architecture locally — it is enough to run only the components needed for a specific development scenario.
Running a single database via Docker is quite simple. But if developers need five or ten containers for their work, it’s inconvenient to start each one manually. This is where Docker Compose comes in especially handy. In compose.yaml, developers can describe a set of services required for the project to work locally. For each service, developers can define an image, ports, environment variables, volumes, networks, and other parameters. As a result, instead of a set of separate commands, developers get a description of the entire local environment. The entire environment can be started with one command:
docker compose up
The main value of Compose here is not just that one command starts many containers.
The Compose file becomes a declarative description of what environment the application needs to run. If this file is in a repository, the team can version-control it along with the code. When the required version of PostgreSQL changes or a new service is added, the corresponding change is pushed to the repository and becomes available to the entire team.
All these advantages become especially noticeable during the onboarding process for a new developer because Docker significantly reduces the number of tools and services that need to be installed and configured manually. Instead of a long environment configuration process, a significant part of the necessary infrastructure can be run locally using Docker Compose, which helps developers start working on the project quickly.
Docker Compose helps make local environments more consistent across the entire team. Developers can run the necessary databases, services, and other dependencies using the same configuration stored together with the project code. This simplifies environment setup and makes the onboarding process faster and easier for a new team member.
At Swan Software Solutions, we use many tools and technologies to produce reliable, scalable, and affordable solutions. To discover how our team can help your team with its technology needs, schedule a free assessment.