In a monolith, every feature ships as one deployable unit. Microservices split the application along business lines, such as users, catalog, payments and notifications, so each service can be built, deployed and scaled by its own team. The cost is that one user request now crosses the network several times, which makes the system harder to run and to debug.
Characteristics
- One job per service: each service owns a single business capability.
- Independent deployment: a team ships its service without waiting for anyone else's release.
- Its own data: each service has its own database, and others reach that data only through its API.
- Communication over the network: synchronous calls over REST or gRPC, or asynchronous messages through Kafka, RabbitMQ or a cloud queue.
- Built for failure: timeouts, retries and circuit breakers keep one slow service from taking down the rest.
- Usually packaged as containers and run on Kubernetes or a serverless platform.
Microservices vs. monolith
| Monolith | Microservices | |
|---|---|---|
| Deployment | One unit, released together | Each service on its own schedule |
| Scaling | The whole application | Only the services that need it |
| Data | Usually one shared database | A database per service |
| Failures | One bad component can take down everything | Failures can be contained, but network failures are new |
| Debugging | One process, one stack trace | Requests span services and need distributed tracing |
| Fits | Small teams and early products | Many teams working on one product |
Microservices are not automatically better. Many teams start with a well-structured monolith and split out services only when team size or scaling needs justify the extra operational work.
Monitoring microservices
- Distributed tracing follows one request across every service it touches and shows where the time went. See distributed tracing.
- A service map shows which services call which, so you can see the blast radius of a failure.
- Per-service RED metrics: request rate, errors and duration for every service and endpoint.
- Correlated logs: a shared trace ID in every log line ties logs from different services to the same request.
- Cascading failures: watch for retry storms and saturated connection pools, which spread one service's problem to others.
Further reading: distributed tracing best practices for microservices and why APM matters for microservices.
Microservices monitoring with Atatus
Atatus APM traces requests across services, including database queries and external calls, and builds a service map of how they depend on each other. It has agents for Node.js, Python, Java, .NET, PHP, Go and Ruby and accepts OpenTelemetry data, so services written in different languages appear in the same trace.