In the past we used to pack all our services into a single bundle and deploy it. This monolithic applications have it's own pros and cons.
- Massive code bases are difficult to maintain.
- To deliver a single feature we have to deploy full application.
- If something fail, whole system fail.
- Difficult to scale.
- Domains are tightly coupled.
- Everything in a single database.
- Quick deliveries are difficult.
This does not mean monolithic systems are bad. It is depending on the system we build. Above mentioned disadvantages will become advantages on those situations. In addition to that a monolithic system;
- Easy to monitor
- Have one code base to maintain
- Easy to trace any error
- Easy transaction handling.
Ideally, if your company is not willing to bear the initial cost (specially start ups), CI/CD pipelines, server costs, etc go with monolithic.
On the other hand microservices are here to solve these kind of problems although it is not a one fit for all solution. Given all the advantages, one of the main advantage of the microservice architecture is replaceability. Since the services are properly decoupled we can replace whole system without breaking any.
In a microservice architecture application is broken into small-grained components by their business domain. One of main difficulties is identifying business boundaries. That is why it is always better to use "monolithic first" approach since it will give us proper understanding about the system we are going to build. A properly structured microservice give us;
- Faster delivery of new features
- Independent delivery of business.
- Independent deploy, update, replace, scale.
- Highly flexible
- Database is divided as per the domain.
- Different technologies as per the demand.
It is widely misunderstood that breaking a system into REST APIs is the microservice architecture. It should be noted that there is no proper definition for a microservices and we should ask the question from ourselves. Is my service is really a microservice?
A bad microservice
- A service with too many responsibilities.
- Having large number of tables (more than 5).
- Service per a table.
- Heavily interdependent on one another.
- Cannot re-write within few days.
A good microservice
- Replace within few days with different technologies.
- Single responsibility
- Serving small number to tables (usually less than 5)
- Independent of other services.
In addition to those it is always better to stick to below practices.
- Use REST philosophy.
- Proper URI names to communicate intent.
- HTTP status codes to communicate results.
- JSON as the request/ result type.
- Versions from the beginning.
- Communicate its health.
- Self contained and independently deployable.
Nothing comes free. When working with microservices we are going to face new set of problems.
- How to manage configurations?
- How does services find each other?
- How can we load balance?
- How to pin down a failure and monitor logs?
- How to handle security?
- What are we going to do if a service is failed?
Lucky for us we are not alone. Giants in the industry already have faced these difficulties which lead them to create frameworks to handle them. Companies like Pivotal, Netflix has gone one step further making their products free and open source. With Spring Boot it is a matter of adding few dependencies into our build automation tool which help us to focus on our business domain.
- Spring Boot - Quickly create microservices
- Spring Cloud Config - Configuration management
- Netflix Eureka - Service discovery
- Netflix Zuul - Route gateway
- Netflix Ribbon - Client side load balancing
- Netflix Histrix - Circuit breaker
- Spring Cloud Sleuth - Distributed tracing
- Spring Cloud Stream - Asynchronous event processing
- Spring Cloud Security - Authentication and authorization management
Spring microservices in action
Learn microservices with spring boot
Microservices with spring boot and spring cloud
How netflix works