Skip to main content
Welcome back. In this lesson we’ll review how we started and how the final architecture evolved, highlighting the practical steps, trade-offs, and operational improvements made while transforming a monolithic crypto application into a microservices-based system on AWS.

​
Project starting point — what you were given

You joined as a DevOps engineer with access to the application’s codebase only. From that starting point the first working setup was deliberately simple and meant to validate the application end-to-end:
  • Access to the AWS CodeCommit repository for source control.
  • An AWS Cloud9 development environment for quick, browser-based development.
  • Containerization of the application (Docker) and local validation of the container image.
These steps provided a minimal reproducible deployment and a foundation for iterating toward a more robust, scalable architecture.

​
Key technical learnings and trade-offs

During the project you made several architecture and operational decisions. Each choice had trade-offs related to reliability, scalability, and team productivity:
  • Docker image tagging strategies — immutable tags (e.g., content-hash) vs. mutable tags (e.g., latest) and how mutable tags can cause unpredictable deployments.
  • Amazon ECS as the chosen container orchestration platform to run Docker containers in a managed service.
  • CI/CD design using AWS services (CodeCommit, CodeBuild, CodePipeline) for automated builds and deployments.
  • Safe rollback and deployment reliability strategies such as blue/green or canary deployments and use of Application Load Balancer (ALB) for traffic shifting.
Prefer immutable Docker image tags (for example, the image digest or a unique build number) to ensure reproducible, auditable deployments and simpler rollback procedures.
Some choices that were appropriate early in development needed revisiting as requirements, traffic patterns, and team structure changed. The architecture therefore evolved from a monolithic application into a microservices-oriented design.

​
Architectural evolution: Monolith → Microservices

You refactored by separating concerns into distinct services. The product functionality and the login/authentication functionality were decoupled into separate services and repositories. Each service has its own build and deployment pipeline, enabling independent releases and reducing cross-team coupling. Benefits of this refactor include:
  • Independent deployability for each team.
  • Reduced blast radius for failures.
  • Finer-grained scaling per service to optimize cost and performance.
  • Clearer ownership and faster CI/CD cycles.
All of your teams can now develop independently, and — as the diagram shows — application scalability and
The image is a flowchart illustrating the transition from monolithic to microservices architecture using AWS Cloud services such as AWS CodePipeline, Amazon ECS, and Application Load Balancer. It shows the separation of "Product" and "Login" applications, each with their own build and deployment processes.
service reliability are now much easier to guarantee.

​
Side-by-side: Initial vs Final architecture

  • Adopt immutable image tagging and store images in Amazon ECR with proper lifecycle policies.
  • Implement deployment strategies that minimize downtime: blue/green or canary deployments with accurate health checks on the ALB.
  • Automate observability: centralized logging (CloudWatch Logs), metrics (CloudWatch / Prometheus), and distributed tracing.
  • Harden CI/CD pipelines with automated tests, security scans (container image scanning), and IAM least-privilege for build/deploy roles.
  • Document service contracts and API versioning to reduce integration friction between teams.
Congratulations — you’ve moved from understanding requirements and running a monolithic app to refactoring for microservices and applying deployment and operational best practices.

Watch Video

Practice Lab