Microservices architecture: containers, registry and delivery pipeline
Microservices split an application into small services that you build, release and scale on their own. Here is how the pieces fit, which service plays each part on AWS, Azure and Google Cloud, and what to settle before you split anything.
Quick answer
A microservices architecture runs each service as a container on a managed Kubernetes cluster or a serverless container platform, behind a load balancer. A pipeline builds images into a container registry and deploys them, and monitoring, logs and a secrets service support every service, each owning its own data.
| Best for | Large products with several teams that must release and scale parts independently |
|---|---|
| Less suited when | Small teams and simple apps, where one well-organised application is faster to build and run |
| Start with | Split one clear service out of a working application, with a pipeline and monitoring |
| Main services on AWS | AWS CodePipeline + CodeBuild, Amazon ECR, Amazon CloudWatch, AWS Secrets Manager, Elastic Load Balancing, Amazon EKS |
| Main services on Azure | Azure Pipelines, Azure Container Registry, Azure Monitor, Azure Key Vault, Azure Application Gateway, Azure Kubernetes Service |
| Main services on Google Cloud | Cloud Build, Artifact Registry, Cloud Monitoring, Secret Manager, Cloud Load Balancing, Google Kubernetes Engine |
The idea in plain words
In a monolith, the whole application is one unit: you build, release and scale it together. In microservices, you split it into small services, each owning one business job and its own data, that talk to each other over the network.
That lets teams release independently and scale only the busy parts. In return you take on more moving parts: networking between services, many pipelines, shared monitoring and data that is spread out.
Run the services as containers. A managed Kubernetes cluster gives the most control, and serverless container platforms remove the cluster work. A registry stores the images and a pipeline ships them.
The architecture
Boxes show the job each part does. Pick a cloud to see the service for each job.
Step by step
- Developers push codeA change to one service starts its own pipeline, which runs tests.
- The pipeline builds an imageIt packages the service as a container image and scans it for known vulnerabilities.
- The image goes to a registryA private registry stores versioned images, so every environment runs exactly the same build.
- The platform runs itA managed Kubernetes cluster or serverless container platform pulls the image and runs several copies.
- Traffic is sharedA load balancer or ingress sends requests to healthy copies and routes each path to the right service.
- Services use their own dataEach service keeps its own database or queue and talks to others through APIs or events, not by sharing tables.
- Everything is watched togetherCentral metrics, logs and traces show how requests move across services. Secrets come from a secrets service, never from images.
Services side by side
The main service for each job on each cloud, with a second option where one exists. Names checked on 23 October 2026.
| Job | AWS | Azure | Google Cloud |
|---|---|---|---|
| CI/CD pipelines |
|
|
|
| Container image registry |
|
|
|
| Monitoring, metrics and alerts |
|
|
|
| Store secrets (passwords, API keys) |
|
|
|
| Load balancing |
|
|
|
| Managed Kubernetes |
|
|
|
| Central logs and log analyticsOptional |
|
|
|
Common variations
- Services must call each other reliably. Add retries, timeouts and a message queue between services, and consider a service mesh only when you really need one.
- Releases must be very safe. Use blue-green or canary releases, so a bad version reaches few users and can be rolled back quickly.
- Traffic is spiky. Scale services automatically on load, using serverless containers or event-driven scaling.
- Teams already run virtual servers. Move one service at a time and keep the rest where it is, linking them with APIs.
Kubernetes cluster or serverless containers?
You can run containers on a managed Kubernetes cluster, which gives the most control, or on a serverless container platform that hides the cluster, shown in the table.
| AWS | Azure | Google Cloud | |
|---|---|---|---|
| Run containers without managing servers |
|
|
|
Managed Kubernetes
Good
- Most control and the widest tool ecosystem
- The same approach on every cloud
- Handles many services and complex setups
Watch out
- Cluster upgrades, networking and security to manage
- Needs Kubernetes skills
- Costs while nodes run, even when idle
Serverless containers
Good
- No cluster to run or patch
- Scales to zero and up on demand
- Quicker to start for a small team
Watch out
- Less control of networking and scheduling
- Platform limits on size and features
- Moving to Kubernetes later takes work
Keep in mind
- Do you need microservices?. A well-structured single application is simpler and faster for small teams. Split only when team size, release speed or scaling really demand it.
- Own your data. Each service should own its data. Sharing one database across services brings back the problems you were trying to avoid.
- Observability. Use correlation IDs, central logs, metrics and traces from day one. Without them, finding a fault across services is slow.
- Security. Scan images, run containers with least privilege, restrict service-to-service traffic and keep secrets out of images.
- Cost. Many small services add idle capacity and tooling cost. Right-size containers, scale to demand and remove unused services.
- Delivery pipeline. Give each service its own pipeline and versioned releases, with automated tests and fast rollbacks.
- Team skills. Running distributed systems needs skills in networking, containers and monitoring. Plan training or use managed platforms.
Words used on this page
Services in this pattern that have changed
Cloud providers rename and retire services often. These affect the parts above. Checked on 23 October 2026.
Sources and further reading
Check details such as features, limits, prices and regions in the providers' own documentation.
- AWS documentation (opens in a new tab)
- Microsoft Azure documentation (opens in a new tab)
- Google Cloud documentation (opens in a new tab)
Announcements about the changed services above
Frequently asked questions
What are microservices?
Microservices split an application into small, independent services, each handling one business job and owning its data. Teams build, release and scale each service separately.
Do I need Kubernetes for microservices?
No. Serverless container platforms and plain managed container services can run microservices without a cluster. Kubernetes helps when you need its control or tooling.
When should I not use microservices?
Avoid them for small teams, early products and simple apps. A single well-organised application is faster to build, test and run, and can be split later.
How do microservices communicate?
Services call each other through APIs when they need an immediate answer, or exchange messages and events through queues and buses when they do not need to wait. Each choice has trade-offs.
How do I manage many microservices?
Use one pipeline pattern for all services, central monitoring and logs, versioned APIs, clear ownership and automation for deployment and scaling.
Want this reviewed for your case?
CloudBrum architects can adapt this pattern to your documents, users, rules and budget, and estimate the cost. Nothing is sent until you choose.
Building something else?
Describe it in plain words and get matching services on all three clouds.
Service suggester → Cloud consulting →