Microservices and Conteiner Architecture
Lecturer
Heino Talvik, IT College, TalTech
Lecture 1 - Introduction to Microservices and Container Architecture
Keywords: Microservices, Containers, Virtualization, and Cloud Computing
1. Overview
The presentation introduces key concepts in microservices and container architectures, tracing their historical evolution and practical application in cloud computing environments like AWS.
2. Core Topics
- Virtualization & Containers
- Docker & Kubernetes
- Enterprise and Cloud Architecture
- Scalability & DevOps
- Microservices & Serverless
- 12-Factor Apps & GitOps
3. Historical Evolution of Microservices
Monolithic Era
- Early software systems were monolithic, bundling all features in one large codebase.
- Difficult to scale, maintain, and deploy as systems grew.
Distributed Systems & SOA
- Service-Oriented Architecture (SOA) emerged, separating services via an Enterprise Service Bus (ESB).
- However, SOA often led to large, tightly coupled services.
DevOps and Continuous Deployment
- Emphasis on rapid iteration and continuous integration/deployment.
- Required smaller, independent units—leading to microservices.
Cloud & Containerization
- The rise of AWS, Azure, Google Cloud, and Docker made deploying many small, independent services feasible.
- Containers enabled lightweight, isolated, and scalable deployments.
Organizational Shift
- Conway’s Law: Systems reflect organizational communication.
- Microservices align with cross-functional teams managing independent services.
Agility & Market Responsiveness
- Microservices allow faster adaptation to market changes.
- Enable fault isolation—one service failing doesn’t crash the entire system.
Data and Persistence
- Encouraged polyglot persistence: each service can use its own database suited to its needs.
User Experience & Scalability
- With global and mobile users, microservices offer resilient, scalable backends for high availability.
4. Evolution of Containerization
Early Concepts
- Began with UNIX
chroot(1970s) for file system isolation. - FreeBSD Jails (2000) and Solaris Zones (2004) expanded isolation capabilities.
Linux Containers (LXC)
- Introduced in 2008, combining cgroups and namespace isolation.
- Provided a base for modern container systems.
Docker Revolution (2013)
- Simplified building, sharing, and running containers.
- Introduced Dockerfile, Docker Hub, and an intuitive CLI.
- Focused on developer usability and workflow automation.
Kubernetes (Google, 2014)
- Based on Google’s internal “Borg” system.
- Became the de facto standard for orchestrating and managing containerized applications.
Open Container Initiative (OCI, 2015)
- Standardized container formats and runtimes to ensure interoperability.
Modern Trends
- Tools like containerd, CRI-O, and rkt diversified the ecosystem.
- Containers now underpin serverless (AWS Lambda, Azure Functions) and edge computing environments.
5. Key Takeaways
- Microservices represent an evolution from monolithic to modular architectures.
- Containerization enabled scalable, reproducible deployments.
- DevOps, cloud infrastructure, and agile teams drove widespread adoption.
- Together, they form the foundation of modern distributed systems.
Lecture 2 - Virtualization and IT Infrastructure
Keywords: Virtualization, Hypervisors, and IT Infrastructure
1. Overview
The presentation explains virtualization technology, its evolution, and its role in modern IT infrastructure. It covers how virtualization increases efficiency, scalability, and flexibility in data centers while also introducing key concepts like hypervisors, types of virtualization, and security implications.
2. The Data Center Dilemma
- Increasing power demand and underutilized hardware led to inefficiency.
- Servers typically used only a fraction of their CPU capacity.
- As computing power doubled every ~18 months (Moore’s Law), server sprawl became a major issue.
- Organizations accumulated many idle servers, increasing energy consumption and maintenance costs.
3. The Rise of Virtualization
Virtualization abstracts physical hardware into virtual machines (VMs) that mimic physical servers.
Key benefits:
- Consolidation: Multiple VMs on one physical server reduce footprint, energy, and costs.
- Containment: Deploying new applications as VMs avoids buying new hardware.
- Agility: Quick cloning, templating, and snapshots make IT operations more flexible.
4. Virtual Machines and Hypervisors
Virtual Machines (VMs)
- Act like real servers but are just files describing virtual hardware (CPU, memory, storage, network).
- Offer portability and isolation.
- Can be quickly cloned or restored.
Hypervisors
Software that manages VMs and allocates physical resources.
Types:
- Type 1 (Bare-metal): Runs directly on hardware (e.g., VMware ESXi, Hyper-V, Xen).
- More secure and efficient.
- Type 2 (Hosted): Runs atop an operating system (e.g., VirtualBox, VMware Workstation).
- Easier setup but less efficient.
5. Types of Virtualization
- Server Virtualization: Combine multiple servers into one host.
- Desktop Virtualization (VDI): Virtual desktops run in the data center, accessed via thin clients.
- Application Virtualization: Applications isolated from the OS for compatibility and easier deployment.
- Network Virtualization: Abstracts physical networks to create VLANs, virtual switches, and routers.
- Storage Virtualization: Aggregates and manages physical storage through a network (e.g., SAN).
- Access Virtualization: Allows devices to access any app without compatibility issues.
6. Benefits of Virtualization
From a Business Perspective
- Lower hardware and energy costs.
- Easier management and recovery.
- Increased flexibility and scalability.
- Vendor independence and better resource utilization.
From a Data Center Perspective
- Reduced heat and power usage.
- Faster server provisioning.
- Easier migration to cloud and improved disaster recovery.
7. Challenges and Trade-offs
- Isolation and performance: Balancing efficient resource sharing (CPU, memory, disk).
- Overhead: Running multiple OS instances adds resource cost.
- Security: More layers (hypervisor + guest OSes) increase complexity and potential vulnerabilities.
8. Security Implications
Advantages
- Isolation between VMs enhances compartmentalization.
- Limits the scope of a breach (e.g., web server compromise doesn’t affect DNS).
- Enables out-of-band monitoring and security layers.
Disadvantages
- Complexity increases attack surface.
- Hypervisors can introduce new vulnerabilities.
- Possible VM-to-VM attacks if isolation fails.
9. Key Takeaways
- Virtualization maximizes hardware efficiency and improves scalability.
- Enables cloud computing by separating software from hardware dependencies.
- Essential for modern DevOps, data center automation, and hybrid cloud environments.
- Must be managed carefully to avoid security and performance pitfalls.
Lecture 3 - Containers and Microservices
Keywords: Containers, Microservices, and Modern IT Infrastructure
1. Overview
This presentation explores containers — lightweight, portable environments for running software — and how they relate to virtualization and microservices. It explains container properties, compares them to virtual machines (VMs), and discusses their benefits from both business and IT perspectives.
2. What is a Container?
A container is a self-contained software package that includes everything needed to run an application — the code, runtime, libraries, dependencies, and configuration files.
It ensures consistent operation across environments (development, testing, production).
Containers are a form of lightweight virtualization that use the host OS kernel instead of running a full OS per application.
3. Key Properties of Containers
- Lightweight Virtualization – Share the host OS kernel, using fewer resources than VMs.
- Isolation – Each container has its own filesystem, process tree, and network namespace.
- Consistency – Runs identically across environments; eliminates “works on my machine” issues.
- Portability – Run anywhere (Linux, Windows, macOS) as long as a container runtime (e.g., Docker) is available.
- Efficiency – Faster start-up and lower overhead compared to virtual machines.
- Immutability – Containers are built from fixed images that don’t change after creation.
- Ephemeral and Scalable – Containers can be easily created or destroyed for horizontal scaling.
- Microservices Enablement – Each microservice runs in its own container, communicating via APIs.
- Managed by a Runtime – Tools like Docker, Podman, or containerd handle container lifecycle operations.
4. Containers vs Virtual Machines
| Aspect | Virtual Machines (VMs) | Containers |
|---|---|---|
| Architecture | Each VM includes its own OS, libraries, and app, running atop a hypervisor. | Containers share the host OS kernel; only include the app and dependencies. |
| Resource Usage | Heavy – each has its own OS, consuming more CPU/RAM. | Lightweight – no OS duplication. |
| Isolation | Full OS-level isolation. | Process-level isolation (via namespaces, cgroups). |
| Portability | Less portable (depends on hypervisor compatibility). | Highly portable across systems and clouds. |
| Efficiency | Higher overhead, slower boot time. | Very efficient, near-instant startup. |
| Security | Stronger isolation via separate kernels. | Slightly weaker; mitigated with SELinux, seccomp, etc. |
| Use Cases | Run multiple OSes or legacy systems. | Ideal for microservices and cloud-native apps. |
| Density | Fewer VMs per host. | Many containers per host (high density). |
5. Brief History of Containers
- 1979: UNIX V7 – early isolation features
- 2000: FreeBSD Jails
- 2001: Linux VServer
- 2004: Solaris Containers
- 2005: OpenVZ
- 2008: Linux Containers (LXC)
- 2013: Docker – revolutionized usability and adoption
Open Container Initiative (OCI) (founded 2015) standardized container formats and runtimes for compatibility across ecosystems.
6. Container Management Systems
- Open Source: Kubernetes
- Commercial Platforms: Docker Enterprise, Red Hat OpenShift, CoreOS Tectonic, Rancher
These tools orchestrate containers — automating deployment, scaling, networking, and monitoring across clusters.
7. Containers in Modern IT Infrastructure
Foundation of Cloud-Native Systems
- Containers form the backbone of cloud-native applications.
- Support multi-cloud and hybrid architectures across AWS, Azure, and GCP.
Microservices Enablement
- Each service runs independently in its own container.
- Simplifies updates, testing, and scaling.
DevOps and CI/CD
- Key to modern DevOps workflows.
- Enable continuous integration, automated testing, and continuous deployment.
Scalability and Elasticity
- Containers support horizontal scaling based on real-time workload.
- Kubernetes automates scaling and load balancing.
8. Benefits of Containerization
Business Perspective
- Portability: Seamless migration between on-premise and cloud.
- Faster Time to Market: Rapid deployment and iteration cycles.
- Cost Efficiency: Higher app density, lower infrastructure and maintenance costs.
- Scalability: Easily adapts to changing workloads and demand.
- Productivity: Encourages DevOps collaboration.
- Microservices Support: Modular, agile system design.
- Vendor Independence: Avoids lock-in, flexible across providers.
IT Perspective
- Consistency: Same container runs in dev, test, and prod.
- Resource Efficiency: Shares host OS, maximizing utilization.
- Fast Deployment & Scaling: Instant startup and elastic scaling.
- Simplified Management: Abstracts apps from infrastructure.
- Security & Isolation: Namespace and cgroup-based isolation; RBAC and image scanning.
- CI/CD Integration: Automates deployment pipelines.
- Disaster Recovery: Rapid redeployment on new hosts.
- Automation & Orchestration: Kubernetes simplifies large-scale container operations.
9. Summary: Business vs IT Value
| Business Benefits | IT Benefits |
|---|---|
| Cost efficiency | Resource optimization |
| Faster market response | Rapid deployment & scaling |
| Scalability & agility | Simplified management |
| Reduced vendor lock-in | Security and reliability |
| Innovation & microservices | Automation with orchestration tools |
10. Key Takeaways
- Containers are the core of modern cloud-native infrastructure.
- They offer portability, scalability, and consistency unmatched by traditional VMs.
- Kubernetes and Docker ecosystems form the backbone of DevOps and microservices adoption.
- Businesses benefit from agility, cost savings, and faster innovation cycles.
Lecture 4 - Docker and Containerization
Keywords: Docker, Containers, and Modern Application Delivery
1. Overview
The presentation introduces Docker — a leading platform for building, running, and managing containers.
It explains how Docker revolutionized software delivery by providing a lightweight, portable, and consistent environment for applications, bridging the gap between developers, system administrators, and cloud infrastructure.
2. What is Docker?
Docker is a software platform that automates the deployment of applications inside containers.
Different perspectives:
- Software Developer: A merge of infrastructure and source code management.
- Hardware Engineer: Processes with IP addresses.
- System Administrator: “chroot on steroids.”
- Visionary: A transformative tool, like replacing tar with apt-get.
- Business Owner: A foundation for generating revenue through faster delivery.
3. Docker’s Origins and History
- Origin: Created as a project by dotCloud, a PaaS provider.
- First release: Docker 0.1.0 in March 2013.
- Rapid adoption with tens of thousands of GitHub stars and forks.
- Became an open-source movement led by Docker Inc.
4. What Docker Is and Isn’t
Docker is:
- A container platform for packaging, distributing, and running applications.
- Lightweight, portable, and fast.
Docker is not:
- A virtualization platform
- A full cloud platform
- A configuration management system
- A development environment
Docker is an application delivery technology, not a virtualization solution.
5. Docker Components
| Component | Description |
|---|---|
| Docker Engine | The runtime responsible for building and running containers. |
| Docker CLI | Command-line tool to interact with Docker. |
| Docker Daemon | Background process managing Docker objects (images, containers). |
| Docker Image | Read-only template used to create containers. |
| Docker Container | Running instance of an image. |
| Dockerfile | Text file with instructions to build an image. |
| Docker Hub | Centralized public/private registry for storing images. |
| Registry | Stores, distributes, and manages images. |
| Control Plane | Orchestration and management layer for clusters (e.g., Swarm, Kubernetes). |
6. Docker Architecture and Terminology
- Images: Read-only templates (like snapshots).
- Containers: Running images with their own isolated environments.
- Engine: The Docker runtime that handles networking, storage, and container lifecycle.
- Dockerfile: Defines how images are built (imperative build scripts).
- Registry (Hub): Stores and distributes container images like GitHub does for code.
Image structure: Layers based on file system changes (FROM, RUN, COPY, etc.), similar to Git commits.
7. Container vs Virtual Machine (VM)
| Aspect | Virtual Machine | Docker Container |
|---|---|---|
| Isolation | Full OS per VM | Shared kernel, process-level isolation |
| Startup Time | Minutes | Seconds |
| Size | GBs | MBs |
| Overhead | High | Low |
| Portability | Limited | Highly portable |
| Use Case | Legacy, multiple OS | Modern apps, microservices |
Key difference:
Docker focuses on delivering applications, not virtualizing entire machines.
8. The Docker Lifecycle
| Phase | Action |
|---|---|
| Conception | Build an image from a Dockerfile |
| Birth | Run (create + start) a container |
| Reproduction | Commit and run new containers from existing images |
| Sleep/Wake | Stop/start containers |
| Death | Remove container |
| Extinction | Delete image (RMI) |
9. How Docker Works
Docker containers are built upon three Linux kernel features:
1. Control Groups (cgroups): Manage CPU, memory, I/O, and network resources.
2. Namespaces: Provide process, network, and file system isolation.
3. Union File System (UnionFS): Enables layered image construction.
Each image layer is reusable and versioned for efficiency.
10. Docker Commands
Common example:
docker run hello-world
Downloads and runs a test image to verify installation.
General syntax:
docker run [OPTIONS] IMAGE [COMMAND] [ARGS...]
11. Docker Use Cases
For Developers
- “Build once, run anywhere.”
- Avoid dependency issues.
- Isolated, reproducible environments.
- Automate packaging, integration, and deployment.
- Fast resets and versioning with images.
For DevOps
- Consistent lifecycle management.
- Reliable CI/CD pipelines.
- Environment parity across development, testing, and production.
- Reduced cost and simpler deployment than VMs.
For Enterprises
- Improved ROI, standardization, and resource optimization.
- Reduced hardware, licensing, and maintenance costs.
- Faster time to market and mean time to repair (MTTR).
- No vendor lock-in and easier cloud adoption.
12. Common Myths About Docker (Debunked)
- Docker isn’t open source → False (Docker Engine is open source via the Moby Project).
- Containers are virtual machines → False; containers share the host kernel.
- All Docker editions are the same → False; Desktop, Engine, and Enterprise differ.
- Docker = Kubernetes → False; Docker manages containers, Kubernetes orchestrates them.
- Docker isn’t secure → False; features like rootless mode, seccomp, and SOC 2/ISO 27001 compliance exist.
- Docker is dead → False; Docker remains one of the most used and desired tools (2023–2024 Stack Overflow surveys).
- Docker is hard to learn → False; extensive resources and community support make it accessible.
- Docker is only for developers → False; used in DevOps, data science, healthcare, education, etc.
- Docker Desktop is just a GUI → False; includes Docker Engine, CLI, and advanced integrations.
- Docker is only for microservices → False; used for diverse workloads and enterprise use cases.
13. Key Takeaways
- Docker democratized container technology, making it usable, portable, and community-driven.
- It transformed software delivery with consistency and scalability.
- Forms the foundation of modern DevOps and cloud-native ecosystems.
- Not a replacement for Kubernetes but an essential companion for building and running containerized apps.
14. Core Docker Components Summary
- Docker Engine – core runtime.
- Docker CLI – command interface.
- Docker Hub – cloud registry for images.
- Docker Desktop – developer GUI and environment.
- Docker Build Cloud & Docker Scout (2023–2024) – advanced build and security tools.
Lecture 5 - Docker Compose and Docker Swarm
Keywords: Multi-container applications, Docker Compose, and Docker Swarm orchestration
1. Overview
This presentation introduces Docker Compose and Docker Swarm, two key tools for managing containers and multi-service environments.
While Docker Compose simplifies single-host multi-container management, Docker Swarm provides clustering and orchestration across multiple hosts.
2. Understanding Docker Execution
When executing:
docker run ubuntu:12.04
Docker:
1. Searches for the image locally.
2. Downloads from Docker Hub if missing.
3. Creates and starts a container.
This process automates image retrieval, creation, and execution.
3. Docker Solutions and Tools
- Docker Hub – image registry
- Docker Engine – runtime
- Docker Desktop – developer GUI
- Docker Enterprise – enterprise-level security and management
Features:
- Trusted images
- Encrypted communication
- Secrets/cert management
- Policy-based image promotion
4. Common Docker Commands
| Command | Description |
|---|---|
docker run |
Run a container |
docker ps -a |
List all containers |
docker commit |
Save changes as new image |
docker images |
List images |
docker build |
Build image |
docker logs |
Show logs |
docker kill |
Stop running container |
docker rm |
Remove container |
docker rmi |
Remove image |
5. What is Docker Compose?
Docker Compose defines and runs multi-container Docker apps using a YAML file.
It describes multiple services and how they connect (ports, volumes, environment variables).
Commands:
docker compose up
docker compose stop
docker compose down
docker compose logs
docker compose build
6. Key Features of Docker Compose
- Multiple isolated environments on one host
- Persistent volumes
- Rebuild only changed containers
- Easy environment migration
- Supports variables and multiple configs
7. Common Use Cases
- Development environments
- Automated testing pipelines
- Single-host deployments
Production Tips:
- Remove local volume binds
- Set restart policies (restart: always)
- Adjust environment variables
- Bind to external ports
- Add logging and monitoring
8. Example – Voting App (Microservices)
Services:
- Frontend (JavaScript)
- Backend (Python)
- Database (MySQL)
- Cache (Redis)
- Worker (Java)
Each runs in a separate container orchestrated by Docker Compose.
9. Useful Docker Compose Commands
| Command | Purpose |
|---|---|
docker-compose version |
Verify installation |
docker-compose ps |
List running containers |
docker exec -it <id> bash |
Access container shell |
docker-compose run |
Run service with ports |
docker-compose up |
Start |
docker-compose up -d |
Start in background |
docker-compose down |
Stop/remove containers |
docker kill <id> |
Kill specific container |
10. Docker Registry
Centralized repository for Docker images.
Features:
- Flexible storage
- Authentication and access control
- Horizontal scalability
- High performance
- Global content delivery
11. What is Docker Swarm?
Docker Swarm is Docker’s native orchestration tool that manages clusters of hosts as a single system.
Capabilities:
- Load balancing
- Automatic failover
- High scalability
- Secure communication
- Rollback and recovery
Swarm = cluster of Docker engines (nodes).
12. Key Concepts
| Term | Definition |
|---|---|
| Service | Defines what tasks should run |
| Task | A single running container |
| Node | Machine running Docker Engine |
| Manager Node | Controls and schedules cluster |
| Worker Node | Executes tasks from managers |
13. Docker Compose vs Docker Swarm
| Aspect | Docker Compose | Docker Swarm |
|---|---|---|
| Scope | Single host | Multiple hosts |
| Configuration | YAML file | Cluster-managed |
| Usage | Dev/Test | Production |
| Load Balancing | None | Built-in |
| Resilience | Manual | Automatic failover |
| Scalability | Limited | High |
14. Benefits
Compose:
- Easy setup
- Fast configuration
- Productivity boost
Swarm:
- Clustered management
- Security
- Auto-scaling and load balancing
- Simple rollback
15. Key Takeaways
- Docker Compose: Ideal for multi-container apps on one host.
- Docker Swarm: Manages multi-host clusters for production.
- Compose = simplicity; Swarm = scalability and reliability.
- Together, they support the full container lifecycle from local dev to production.
Lecture 6 - Docker Swarm and Container Orchestration
Keywords: Docker Swarm, YAML, and Container Orchestration
1. Introduction
The presentation explains the need for container orchestration, introduces Docker Swarm, and discusses the use of YAML in container configuration.
Docker Swarm enables scalable, automated, and resilient container management across distributed systems.
2. Markup and Data Serialization Languages
Markup Languages
- Add structure and metadata to text.
- Examples: HTML, XML, LaTeX, SGML.
- Contrast with programming languages (C++, Java, Python).
Types:
1. Presentational: Formatting text (bold, color, etc.).
2. Procedural: Instructions for text processing.
3. Semantic: Describes meaning (e.g., title, author).
3. XML vs. HTML
| HTML | XML |
|---|---|
| Web-focused | Data transport |
| Loose syntax | Strict and clean syntax |
| Fixed tags | Extensible |
| Combines content & format | Separates structure & data |
4. JSON vs. XML
Similarities: Human-readable, hierarchical, language-independent, widely used in APIs.
Differences:
- JSON is lighter and less verbose.
- XML supports validation.
- JSON works natively with JavaScript and supports arrays.
5. YAML – Configuration Format
YAML (YAML Ain’t Markup Language) is a human-readable format for defining structured data.
Features:
- Uses .yaml or .yml extension.
- Indentation-based (spaces, not tabs).
- Case-sensitive and supports comments with #.
Examples:
# Key-Value
Martin: Developer
Steve: Manager
# List
Fruits:
- Apple
- Orange
- Mango
# Dictionary
Apple:
Color: Green
Weight: 150g
6. The Challenge: Scaling Containers
Before orchestration:
- Difficult container communication and management.
- Manual deployment and scaling.
- No built-in load balancing or health checks.
- Not scalable for large workloads.
7. What is Container Orchestration?
Automation of container lifecycle management:
- Provisioning and deployment
- Scaling (up/down)
- Networking and load balancing
- Resource allocation
- Health monitoring
- Security and recovery
8. Docker Compose Example
Instead of long docker run commands:
docker run -e MYSQL_ROOT_PASSWORD=wordpress -d mysql:5.7
docker run -e WORDPRESS_DB_PASSWORD=wordpress -p 80:80 -d wordpress:latest
Use a single docker-compose.yml file and start everything with:
docker-compose up
9. Why We Need Orchestration
At scale, orchestration automates:
- Container scheduling and deployment
- Scaling and failover
- Load balancing and traffic routing
- Security and health checks
10. What is Docker Swarm?
Docker Swarm is Docker’s native orchestration engine, built into Docker Engine.
Key Features:
- Converts multiple hosts into a single cluster.
- Simplifies deployment and scaling.
- Uses Docker CLI — no extra tools required.
- Provides built-in load balancing and fault tolerance.
11. Docker Swarm Components
| Component | Role |
|---|---|
| Node | Docker Engine instance in the cluster. |
| Manager Node | Orchestrates and maintains cluster state. |
| Worker Node | Executes assigned containers. |
| Service | Defines the desired state (containers, replicas). |
| Task | A single container instance. |
| Load Balancer | Distributes requests for high availability. |
12. Benefits of Docker Swarm
- Centralized management via Docker CLI.
- Built-in health checks and load balancing.
- High availability and resilience.
- Network segmentation and security controls.
- Easy scaling and zero-downtime rolling updates.
13. Common Docker Swarm Commands
| Command | Purpose |
|---|---|
docker swarm init |
Initialize swarm |
docker swarm join --token <token> <ip>:2377 |
Add node |
docker node ls |
List nodes |
docker service create --name SERVICE image |
Create service |
docker service ls |
List services |
docker service ps SERVICE |
Show service tasks |
docker service scale SERVICE=n |
Scale up/down |
docker service update --image image:version |
Update image |
docker swarm leave |
Leave swarm |
14. How Docker Swarm Works
Declarative Model
Define the desired state, and Swarm ensures the actual state matches it.
Service Lifecycle
Creation → Deployment → Scaling → Updating → Removal.
Rolling Updates
Incremental updates ensure zero downtime.
15. Key Takeaways
- YAML is vital for configuration in Compose and Swarm.
- Docker Compose manages local, multi-container setups.
- Docker Swarm enables cluster-level orchestration.
- Provides high availability, scaling, and automation.
- Ideal for production-grade containerized systems.
Lecture 7 - Microservices Architecture and Migration
Keywords: Microservices, Monolith to Microservices Evolution, and Migration Strategies
1. Introduction
Overview of how IT architecture evolved from monoliths to microservices and serverless.
Focus on the benefits, challenges, and migration strategies that enable scalable, independent, and resilient applications.
2. Evolution of IT Architectures
| Stage | Description |
|---|---|
| Monolith | All functionality in one large application. |
| Modular Monolith | Divided modules within a single deployable unit. |
| SOA | Large network-based services. |
| Microservices | Independently deployable, fine-grained services. |
| Serverless | On-demand, event-driven functions. |
3. Monolithic Architecture
Characteristics
- Single codebase and deployment unit
- Shared database
- Vertical scaling
- Redeployment required for any change
Pros
- Simple development and testing
- No network latency
- Unified deployment and state management
Cons
- Hard to scale parts independently
- Tight coupling and high risk of failure
- Technology lock-in
- Slow release cycles
4. Modular Monolith
A monolith divided into well-defined modules.
Pros
- Better organization and team collaboration
- Easier testing and refactoring
Cons
- Hidden dependencies between modules
- Still deployed as one unit
- Limited scalability
Purpose: Serves as a transitional model toward microservices.
5. Service-Oriented Architecture (SOA)
Pros
- Reusable, interoperable services
- Scalable and flexible
- Easier maintenance
Cons
- Complex to manage
- Communication latency
- Security vulnerabilities
- Data consistency issues
6. Microservices Architecture
Definition:
Small, independently deployable services focused on specific business functions.
Core Traits
- Independent deployment and scalability
- Organized around business capabilities
- Decentralized technology and data
- Loose coupling, high cohesion
Size:
Small enough for one team to manage, large enough for meaningful business value.
7. Microservices: Pros and Cons
Advantages
- Independent scalability
- Technology flexibility
- Fault isolation
- Faster delivery cycles
- Reusability across applications
Disadvantages
- Distributed system complexity
- Network latency
- Data consistency challenges
- Higher CI/CD and monitoring demands
- Expanded attack surface
8. Migration Drivers
| Business | Technical |
|---|---|
| Faster delivery and innovation | Scalability and performance |
| Agility and cost efficiency | High availability and modernization |
| Competitive advantage | Component-level optimization |
Avoid migration for small apps, unprepared teams, or weak automation setups.
9. Migration Patterns
Strangler Fig Pattern
- Proxy routes requests from monolith to new microservices.
- Gradual migration without downtime.
Benefits: - Minimal risk, continuous delivery, and rollback support.
Steps:
1. Identify migration targets
2. Build and deploy microservice
3. Route traffic via API gateway
4. Shift traffic incrementally
5. Retire old functionality
Branch by Abstraction
Gradual migration inside the same codebase.
Steps:
1. Create abstraction interface
2. Implement old and new behind it
3. Switch gradually and remove old code
Benefits:
- Continuous integration maintained
- Easier testing and rollback
Decomposition Strategies
- By Business Capability: Each service owns a complete business domain.
- Domain-Driven Design (DDD): Use bounded contexts and aggregates.
- Anticorruption Layer (ACL): Protect new services from legacy systems.
Pitfalls:
- Too fine-grained services
- Excessive synchronous dependencies
- Ignoring data consistency
10. 8-Step Migration Process
Analysis Phase:
1. Identify components and dependencies
2. Refactor and flatten architecture
3. Group related modules
4. Create API façade
Migration Phase:
5. Migrate to macroservices
6. Split into microservices
7. Test and verify
8. Repeat iteratively
11. Microservices Architecture Principles
| Principle | Description |
|---|---|
| Componentization | Independent, replaceable units |
| Business Capability | Aligned with business domains |
| Decentralization | Teams choose stack and tools |
| Database per Service | Each service owns its data |
Benefits:
Granular scaling, resilience, and rapid development velocity.
12. Migration Challenges & Solutions
| Challenge | Solution |
|---|---|
| Data consistency | Event-driven architecture, eventual consistency |
| Communication latency | REST/gRPC APIs, message queues |
| Deployment complexity | Docker, Kubernetes, CI/CD |
| Legacy complexity | Strangler Fig, ACL, incremental refactoring |
13. Technology Stack
| Category | Examples |
|---|---|
| Containerization | Docker, ECS, Nomad |
| Orchestration | Docker Swarm, Kubernetes |
| Communication | REST, gRPC, Kafka, RabbitMQ |
| Monitoring | ELK, Prometheus, Grafana, Jaeger |
| API Gateway & CI/CD | Kong, Jenkins, GitLab CI |
| Service Discovery | Consul, Eureka, K8s DNS |
14. Why Microservices Now?
- Rapid response to business change
- High reliability and uptime
- Mature cloud and automation tools
- Domain-driven design adoption
- Asynchronous communication maturity
15. Key Takeaways
- Microservices improve agility, scalability, and fault tolerance.
- Migration requires automation, CI/CD, and team alignment.
- Use incremental patterns like Strangler Fig or Branch by Abstraction.
- Choose mature, proven tools for deployment and monitoring.
- Align system architecture with business and team boundaries.
Lecture 8 - Containers and Microservices – Enterprise Architecture and DevOps Integration
Keywords: Enterprise Architecture, Microservices Principles, and CI/CD Integration
1. Enterprise Architecture and Paradigm Shift
Enterprise Architecture Framework defines the processes, technologies, and structures required for business operations.
It connects business goals with IT systems and supports modernization through:
- Microservices adoption
- Configuration management
- Continuous delivery
- Infrastructure as Code (IaC)
- DevOps integration
This represents a major paradigm shift enabling automation, agility, and scalability.
2. The Problem: Friction
Traditional delivery pipelines suffered from:
- Long release cycles
- Manual processes
- Configuration drift
- Dev–Ops misalignment
DevOps and containerization resolve these by automating deployments and maintaining consistency across environments.
3. Application Delivery with Containers
Containers standardize app packaging and deployment, ensuring consistency across environments and forming the basis for microservice architecture.
4. DevOps and CI/CD
DevOps integrates development and operations to accelerate release cycles.
CI/CD automates build, test, and deploy processes for reliable continuous delivery.
Top CI/CD Tools (2025)
| Tool | Description | Best For |
|---|---|---|
| GitHub Actions | GitHub-integrated, YAML workflows | Small–medium projects |
| GitLab CI/CD | Full DevOps suite | Enterprise and education |
| Jenkins | Plugin-rich, open-source | Custom enterprise systems |
| CircleCI | Fast cloud platform | Startups |
| Azure DevOps | Microsoft native | .NET/Azure projects |
| Bitbucket Pipelines | Simple Atlassian integration | Small teams |
| Travis CI | Easy GitHub integration | Small OSS projects |
| AWS CodePipeline | AWS-native service | AWS-based architectures |
| Argo CD | GitOps automation | Kubernetes-native deployments |
5. Product vs Service
| Aspect | Product | Service |
|---|---|---|
| Nature | Tangible | Intangible |
| Delivery | Physical or packaged software | Process or value outcome |
| Example | Car, device, software | Cloud service, API, consulting |
6. Service-Oriented Architecture (SOA)
SOA Principles: - Interoperability - Loose Coupling - Abstraction - Granularity
Components: Service, Implementation, Contract, Interface, Provider, Consumer, Registry
Benefits: Faster time-to-market, flexibility, easier maintenance
Limitations: Scalability, interdependencies, single point of failure
7. Microservices vs Monolith
| Aspect | Monolith | Microservices |
|---|---|---|
| Structure | Single unit | Distributed services |
| Team | Large, centralized | Small, autonomous |
| Scalability | Vertical | Horizontal |
| Deployment | All-in-one | Independent |
| Complexity | Low | High |
Microservices Advantages
- Better productivity
- Resilience and fault tolerance
- Scalable and modular
- Supports CI/CD and DevOps
Tradeoff: Complexity in communication and service management.
8. Microservices Fundamentals
Microservices = Loosely coupled, autonomous services with clear boundaries.
Principles
| Principle | Description |
|---|---|
| Single Purpose | Focused on one specific task |
| Loose Coupling | Minimal dependencies |
| High Cohesion | Encapsulates related logic and data |
Without these:
- No single purpose → “Mini-monoliths”
- No loose coupling → Fragile, slow changes
- No cohesion → “Distributed monoliths”
9. When to Adopt Microservices
Adopt microservices when:
- System size and complexity grow
- Release cycles are slow
- Independent scaling is required
- DevOps maturity and automation exist
Avoid when:
- Systems are small
- Teams lack CI/CD or container expertise
10. Monolith vs Microservice Trade-offs
| Monolith | Microservice |
|---|---|
| Simpler architecture | Partial deployment possible |
| Consistent data | Eventual consistency |
| Easier refactoring | Requires orchestration |
| Single platform | Multi-platform flexibility |
11. Key Takeaways
- Enterprise Architecture bridges business and technology.
- Microservices rely on: single purpose, loose coupling, high cohesion.
- DevOps and CI/CD are vital for automation and scalability.
- SOA paved the path, but microservices improve scalability and independence.
- Balance complexity vs flexibility with strong documentation and tooling.
“Microservices represent a cultural and technical evolution — enabling fast, reliable, and scalable software delivery through automation and independence.”