Docker and Distributed Systems Architecture

Adopting a microservices architecture introduces scalabilitty benefits but also operational complexity. Unlike monolithic applications, distributed systems consist of numerous independent components that require individual management and deployment. As the number of services grows, deployment frequency increases exponentially. In a single large application, executing ten daily deployments is manageable; however, a microservice version of that same application might require thousands of distinct actions.

Docker addresses these challenges by encapsulating dependencies into portable images. This standardizes the environment, allowing developers to deploy code anywhere without worrying about underlying infrastructure differences. When every service runs within its own container, monitoring, scaling, and updating become modular tasks managed through orchestrasion tools.

To illustrate these concepts, we will implement two lightweight backend services:

• Forex Exchange Service
• Currency Conversion Service

The Conversion Service requires knowledge of the Exchange Service's endpoint to perform calculations. We facilitate this discovery by injecting the target host address as an environment variable.

# Configuring the Target Host Environment Variable
--env FORUM_EXCHANGE_BASE_URL=http://forex-exchange

Only the hostname needs to be defined in the environment. Below is the process for initializing these services locally.

Running Services Manually

First, locate the required container images. For this demonstration, we utilize publicly available repositories.

Execute the following command to start the Forex Exchange service:

docker run --name forex-exchange -p 8080:8080 local-dev/exchange-api:latest

Once the container starts, verify accessibility via the mapped port:

http://localhost:8080/api/exchange/from/EUR/to/INR

Stop the running container to prepare for running mode optimization. Switching to detached mode prevents the terminal from blocking:

docker run -d --name forex-exchange -p 8080:8080 local-dev/exchange-api:latest

Next, launch the Currency Conversion service using a different port mapping:

docker run -d -p 9090:9090 --name conv-service local-dev/conversion-api:latest

Attempting to access the conversion API URL typically results in an error. This occurs because containers communicating on a standard Docker bridge network cannot resolve each other's hostnames automatically.

Legacy Connection Methods

By default, Docker assigns containers to a bridge network. Inspecting the network topology confirms that isolated containers belong to the same subnet but lack direct DNS resolution between them.

Historically, users utilized the --link flag to establish explicit connections between containers. While this allows the linked container to resolve the target name as a hostname, it couples containers tight and is considered deprecated in modern workflows. Nevertheless, the syntax below illustrates how older versions handled this:

docker run -d \
  --name conv-service \
  --env FORUM_EXCHANGE_BASE_URL=http://forex-exchange \
  --link forex-exchange:exchange \
  local-dev/conversion-api:latest

This setup enables the conversion service to call the exchange service at the specified alias. However, relying on linking limits flexibility.

Implementing Custom Networks

A more robust approach involves creating a dedicated user-defined network. While options like host mode expose the container directly to the host OS stack (Linux-only) or none mode provides zero networking, a custom bridge offers the best balance of isolation and internal communication capabilities.

Create a new network named market-trading-net:

docker network create market-trading-net

Remove previous instances to start fresh:

docker rm -f forex-exchange conv-service

Re-attach both services to the new network. Note that the --network parameter replaces the need for --link. Container names now serve as resolvable hostnames within this scope.

docker run -d \
  --name forex-exchange \
  --network market-trading-net \
  -p 8080:8080 \
  local-dev/exchange-api:latest

docker run -d \
  --name conv-service \
  --env FORUM_EXCHANGE_BASE_URL=http://forex-exchange \
  --network market-trading-net \
  -p 9090:9090 \
  local-dev/conversion-api:latest

With both pods participating in market-trading-net, cross-service calls succeed because Docker's embedded DNS server resolves http://forex-exchange correctly.

Streamlining with Docker Compose

As manual commands grow complex, orchestrating multiple containers via Docker Compose becomes essential. This tool utilizes a YAML manifest to define service relationships, networks, and environment configurations.

A typical docker-compose.yml file includes the following sections:

1. Version Specification: Defines the compose file schema.
2. Services Definition: Lists images, ports, and dependencies.
3. Network Definition: Declares the virtual bridge connecting the apps.

An example configuration:

version: '3'

services:
  forex-exchange:
    image: local-dev/exchange-api:latest
    ports:
      - "8080:8080"

  conv-service:
    image: local-dev/conversion-api:latest
    ports:
      - "9090:9090"
    environment:
      - FORUM_EXCHANGE_BASE_URL=http://forex-exchange
    depends_on:
      - forex-exchange

networks:
  market-trading-net:
    driver: bridge

To spin up this entire stack simultaneously, navigate to the directory containing the file and run:

docker compose up

This brings all associated containers online and connects them according to the YAML configuration. For background execution, use the detach flag:

docker compose up -d

Management commands allow for inspection and control of the running group:

docker compose ps          # Display status of all managed containers
docker compose top         # Monitor resource usage
docker compose pause       # Suspend process execution
docker compose unpause     # Resume suspended processes
docker compose stop        # Halt containers gracefully
docker compose down        # Remove containers and networks