Microservices are a popular way to structure software systems today. As companies grow bigger and use more cloud computing, microservices help tackle complexity.
In this issue, we review some key microservices concepts and common questions that come up in interviews:
What are microservices?
What issues do microservices aim to solve?
What new challenges do microservices introduce?
What are some popular microservices solutions?
How does monitoring and alerting work with microservices?
How are logs collected and analyzed?
What is a Service Registry?
Now let’s start with the definition of microservices.
1. What Are Microservices?
We can quote from Martin Fowler and Adrian Cockcroft on key aspects of microservices.
From Martin Fowler:
“The microservice architectural style is an approach to developing a single application as a suite of small services, each running in its own process and communicating with lightweight mechanisms, often an HTTP resource API. These services are built around business capabilities and independently deployable by fully automated deployment machinery. There is a bare minimum of centralized management of these services, which may be written in different programming languages and use different data storage technologies.”
From Adrian Cockcroft:
“Microservices are loosely coupled service-oriented architecture with bounded contexts.”
Key Aspects of Microservices
From the insightful definitions by Martin Fowler and Adrian Cockcroft, we can summarize these key aspects of a microservice architecture:
Decompose monolithic application into small, independent services. This allows different product teams to develop, test, and deploy services that align to specific business capabilities. Useful for large organizations to break down monolithic systems and improve productivity.
Loosely coupled services communicating via APIs. Frontend/backend components communicate via REST, whil inter-service communications use RPC for efficient request/response.
Carefully designed around bounded contexts. Each service has clear module boundaries and encapsulated domain logic to avoid tight coupling between services.
Enables effective DevOps practices. It is an important part of the microservice development methodology. Small, full-stack teams fully own specific services end-to-end. Containerization, automation, and container orchestration are used to effectively deploy microservices.
Horizontally scalable by design, resilient to failures. Services can scale out independently as needed. Built with fault tolerance in mind.
Decentralized governance and flexibility. Teams can choose whatever technology makes sense for their service.
Requires extensive monitoring and instrumentation due to:
Growth in services - As monoliths decompose into many independent services, the number of components to track grows quickly.
Infrastructure abstraction via containers/orchestrators - Runtime platforms like Kubernetes handle infrastructure. So monitoring must happen at the application code level using sidecars to aggregate logs, metrics and traces.
2. What Are the Differences Between SOA and Microservices?
Service-oriented architecture (SOA) and microservices architecture styles are important milestones in software architecture's evolution. The diagram below shows the progression of key architectural styles.
Service-oriented architecture emerged in the late 1990s to help manage enterprise software systems’ growing complexity. In the 2000s, SOA gained more industry attention and adoption by companies. However, SOA faced implementation complexity challenges.
Then in the 2010s, microservices architecture emerged in response to SOA’s limitations. Many large internet companies started adopting microservices to break down their services into smaller components. Microservices gained momentum with cloud computing’s evolution, as containers and orchestration tools made microservices' development, deployment, and monitoring easier.
Let’s compare their differences in more detail. The diagram below lists some of the differences.
The SOA architectural style offers coarse-grained services, typically a centralized approach where services are grouped by business functions and shared across multiple applications. The microservice style offers fine-grained service granularity through a decentralized approach where small, independent services perform specific functions within an application context.
The communication methods also evolve over time. SOA emphasizes uniform communication protocols and standardized interfaces for services to interact. Microservices lean towards diverse communication protocols and interfaces, often based on REST or message queues.
Cloud computing has evolved from Infrastructure-as-a-Service (IaaS) to Platform-as-a-Service (PaaS) to container-based PaaS. So microservice-based applications deploy on containers by default.
As the technical architecture changes, the organizational structure mirrors it (Conway’s law). So with microservices, the team structure requires multi-functional product teams. Each team focuses on a specific domain.
Keep reading with a 7-day free trial
Subscribe to ByteByteGo Newsletter to keep reading this post and get 7 days of free access to the full post archives.