What are microser­vices?

Microser­vices: definition

The opposite model is the monolith: an application in which all functions—from user management to the shopping cart to invoicing—sit in one shared block of code and are deployed together. In a microservice architecture, this application is broken down into individual services, such as catalog, ordering, payment, and shipping.

Ideally, each service has its own data storage and can be owned by a small team. Changes to one service don't require redeploying the entire application. The services are divided up along business domains, not technical layers.

How microser­vices work

The services communicate via clearly defined interfaces—synchronously, for example via REST API or gRPC, or asynchronously via messaging systems such as RabbitMQ or Apache Kafka. An API gateway often bundles external requests and routes them to the responsible service.

For everything to work together, each service needs a clear contract: What data does it accept, what does it return, and how does it respond to errors? If a service changes, its interfaces must remain backward compatible or be versioned.

• Independent services with clearly defined business responsibilities
• Communication via APIs or messages
• Usually run in containers, e.g., with Docker and Kubernetes
• Central monitoring and logging across all services

Benefits and limitations of microser­vices

Microservices make it possible to scale heavily used parts in a targeted way, choose the right technology for each service, and let several teams work in parallel. If one service fails, the entire application doesn't necessarily come to a standstill.

On the other hand, there is significantly more complexity: distributed data, network errors, and more elaborate testing and monitoring. For small teams and early product phases, a well-structured, modular monolith is often the better choice—it can be split up selectively later when a concrete need arises.

• Independent deployment and scaling of individual functions
• Several teams can work in parallel
• Greater effort for operations, testing, and monitoring
• Pays off mainly for large, growing systems

Real-world example: breaking up a monolith step by step

An online retailer runs a store that has grown over many years. The product search in particular comes under heavy load during promotions and slows down the entire store. Instead of rewriting everything, the search is first moved into its own service and scaled separately. Other areas follow only where there is a clear benefit.

Nano Concepts takes a level-headed look at existing architectures and recommends microservices only where they actually solve your problem—otherwise, a cleanly modularized application.