Think of a modern business center. In it, each office is a separate company with its own specialization. Some handle accounting, others do marketing, and others handle logistics. Each one does its job professionally, and together they create an efficient business ecosystem.
That's how microservices work. Instead of one big application (a monolith), we split it into many small services, each doing one specific job.
The approach is based on two main principles:
- Separation of concerns: each service, like a separate company, is responsible only for its part of the work.
- Full autonomy: any service can be updated or changed without disturbing the others — like renovating one office doesn't affect the neighbors.
Evolution: from monolith to microservices
There was a time when everyone loved monoliths. It was the golden standard for enterprise apps. One big project, one codebase, and one deployment. But like any trend, monoliths have downsides:
- Scaling complexity: you often have to scale the whole app even when only one part is under load.
- Failure blast radius: a bug or crash in one component can take down the entire system.
- Slow releases: any change usually requires rebuilding and redeploying the whole application.
Microservices became a logical answer to these problems. They let developers scale critical components independently and speed up deployments.
Why use microservices?
- Speed and flexibility of development. With microservices, teams can work in parallel on different components. For example, team A builds a microservice for payment processing, while team B builds one for user management. They're independent, which shortens development time.
- Scalability. If a particular service (for example, order processing) faces high load, we can scale just that service and leave the rest untouched. That saves resources.
- Fault isolation. When one service fails, the others keep working. For example, if the recommendation service is down, the site can still accept orders.
- Technological independence. Each microservice can be written in its own programming language and use its own tech stack. For example, you can write a REST API with Spring Boot and do big data processing with Python.
How microservices work
Key parts of a microservice architecture:
| Component | Description |
|---|---|
| Service | A self-contained functional unit responsible for a specific task |
| API Gateway | The central entry point to the system that routes requests to the appropriate microservices |
| Service Discovery | Registration and discovery of microservices in the system (for example, using Eureka) |
| Messaging | Asynchronous interaction between services via queues (Kafka, RabbitMQ) |
| Databases | Each service can use its own database |
Real-world examples
- Netflix — a prime example of microservices in action. Every part of their system, from recommendations to video streaming processing, is built as separate services. That lets them scale the parts that users actually use.
- Uber — handles millions of trip and food delivery requests. Their architecture follows microservice principles, splitting functions like driver management, routing, and payments into independent components.
Myths about microservices
- "Microservices are always better". Actually, they don't fit every project. If your system is small enough, microservices can make development more complicated.
- "You can just flip a switch and move to microservices". Not true. Migration requires careful planning and architectural changes.
Implementing microservices with Spring Boot
You're probably wondering: "How do Spring Boot and microservices fit together?" Spring Boot is a great tool for building microservices. Its features include:
- Integration with Spring Cloud for things like configuration, Service Discovery and API Gateway.
- Support for Kafka and other messaging systems for asynchronous communication.
- Easy configuration management via
application.yml.
Let's give an example and start coding. Imagine we have a minimalist microservice system: UserService and OrderService. We'll use Spring Boot to implement them.
UserService
@RestController
@RequestMapping("/users")
public class UserController {
@GetMapping("/{id}")
public String getUser(@PathVariable Long id) {
// Return user info
return "User with ID: " + id;
}
}
OrderService
@RestController
@RequestMapping("/orders")
public class OrderController {
@GetMapping("/{id}")
public String getOrder(@PathVariable Long id) {
// Return order info
return "Order with ID: " + id;
}
}
API Gateway (Spring Cloud Gateway — basic config)
spring:
cloud:
gateway:
routes:
- id: user-service
uri: http://localhost:8081
predicates:
- Path=/users/**
- id: order-service
uri: http://localhost:8082
predicates:
- Path=/orders/**
Now we've got the basic setup: UserService, OrderService, and an API Gateway that routes requests. For example:
- Request
http://localhost:8080/users/1will go to UserService. - Request
http://localhost:8080/orders/1will go to OrderService.
How do you scale microservices?
Say OrderService is under heavy load. You can just spin up a few more instances of it. Tools like Kubernetes will help distribute traffic among them.
Conclusion
Microservices are a powerful tool for modern applications, but they're not a silver bullet. They add flexibility, scalability, and resilience, but also increase system complexity. In future lectures you'll learn more about patterns like Service Discovery and API Gateway that will help you design microservice systems in practice.
GO TO FULL VERSION