Optimising Docker Build Pipelines for Microservices: A Worked Example

As organizations scale their microservices architectures, Docker build pipelines often become bottlenecks in the development process. This worked example walks through how a microservices team with dozens of services can transform their Docker build process to improve developer productivity and reduce infrastructure costs.

The Initial Situation

Picture an engineering team responsible for 50–100 microservices spread across many teams. Their architecture typically includes services built with various technologies, for example:

• A large group of Node.js services
• Java/Spring Boot services
• Python services
• Go services
• Other specialized services in mixed languages

Each service has its own repository and CI/CD pipeline, and the team deploys frequently across all services, with each deployment requiring a Docker build and push to a container registry.

Key Challenges and Solutions

# syntax=docker/dockerfile:1.4
FROM node:18-alpine AS deps
WORKDIR /app
COPY package*.json ./
RUN --mount=type=cache,target=/root/.npm \
    npm ci

FROM node:18-alpine AS builder
WORKDIR /app
COPY --from=deps /app/node_modules ./node_modules
COPY . .
RUN --mount=type=cache,target=/root/.npm \
    npm run build

FROM node:18-alpine AS runner
WORKDIR /app
ENV NODE_ENV=production
COPY --from=builder /app/dist ./dist
COPY --from=deps /app/node_modules ./node_modules
USER node
EXPOSE 3000
CMD ["node", "dist/main.js"]

# syntax=docker/dockerfile:1.4
FROM eclipse-temurin:17-jdk-alpine AS builder
WORKDIR /app
COPY gradle/ gradle/
COPY gradlew build.gradle settings.gradle ./
RUN --mount=type=cache,target=/root/.gradle \
    ./gradlew dependencies

COPY src/ src/
RUN --mount=type=cache,target=/root/.gradle \
    ./gradlew bootJar

FROM gcr.io/distroless/java17-debian11
WORKDIR /app
COPY --from=builder /app/build/libs/*.jar app.jar
EXPOSE 8080
USER nonroot
ENTRYPOINT ["java", "-jar", "app.jar"]

steps:
  - name: Set up Docker Buildx
    uses: docker/setup-buildx-action@v2

  - name: Login to Container Registry
    uses: docker/login-action@v2
    with:
      registry: ${{ env.REGISTRY }}
      username: ${{ secrets.REGISTRY_USERNAME }}
      password: ${{ secrets.REGISTRY_PASSWORD }}

  - name: Build and push
    uses: docker/build-push-action@v4
    with:
      context: .
      push: true
      tags: ${{ env.IMAGE_NAME }}:${{ env.TAG }}
      cache-from: type=registry,ref=${{ env.IMAGE_NAME }}:cache
      cache-to: type=registry,ref=${{ env.IMAGE_NAME }}:cache,mode=max

Results and Impact

When the optimisations described above are applied together, the typical improvements teams report fall into ranges like the following:

The downstream effects are usually broader than the raw numbers suggest:

• Developer productivity: Faster feedback cycles lead to more iterations and fewer context switches.
• Incident response: Time to deploy critical fixes drops noticeably.
• Infrastructure costs: CI compute is one of the easiest line items to reduce once builds are tuned.
• Security posture: Smaller, minimal production images reduce attack surface.
• Deployment reliability: Faster, more reliable deployments with fewer timeout issues.

Key Learnings and Best Practices

Several key learnings from this kind of programme generalise well to other microservices environments:

Lessons for other organisations

Based on the patterns above, here are key recommendations for teams looking to optimise their Docker build pipelines for microservices:

1. Start with Measurement: Collect baseline metrics before making changes to quantify improvements
2. Prioritize High-Impact Services: Begin with the most frequently built services or those with the longest build times
3. Standardize for Scale: Create templates and standards that can be applied consistently across all services
4. Educate Teams: Ensure all developers understand Docker build best practices through workshops and documentation
5. Automate Compliance: Implement CI checks to ensure Dockerfile best practices are followed
6. Consider Total Costs: Factor in both infrastructure costs and developer time when evaluating optimizations
7. Iterate and Improve: Continuously monitor metrics and refine your approach based on real-world results

Conclusion

The pattern this worked example walks through demonstrates that with careful analysis and disciplined application of best practices, microservices teams can achieve substantial improvements in build performance, image size, and cost.

The key to their success was a holistic approach that addressed:

• Dockerfile structure and optimization
• CI/CD pipeline architecture
• Caching strategies at multiple levels
• Standardization across teams and services
• Continuous measurement and improvement

For organisations with growing microservices architectures, investing in Docker build optimisation can yield meaningful returns in both direct cost and developer productivity. The principles and techniques demonstrated above adapt to microservices environments of any size.