In 2014 microservices went mainstream. However we still don’t know anything about how microservice projects are maturing over time, so we need to be very cautious when considering them. In fact, it is still recommended to use monoliths.
Martin Fowler is particularly known for challenging microservice architecture. He has published series of articles over last few months and has recently spoken on XConf. I summarized one of his article in the blog post called What are microservices?
###What are microservices? Microservices architectural style is just something different to what we have been doing since 1990s. We built application using layers (UI, middle-tier business logic, database, etc) and usually one layer’s responsibility was far bigger than the other ones.
When we use microservices, a single app consists of services. Each of them is built around business capability and can be independently deployed. No central “module” is responsible for any of those services.
Technically you should assume that each service runs in its own process and communicates by some lightweight mechanism (like HTTP) and has its own persistence solution. Services may be of different size, but optimally they should be developed (and supported) by a team that can be fed by 2 pizzas ;).
###Ponies are shot at you from a rainbow …when you use microservices of course!
- You can deploy the application partially. Changes in one service are highly independent from another services.
- Keeping modularity is easier. You keep the components (i.e. services) loosely coupled, because each of them has a strict published interface.
- You can use different technologies for different tasks.
- You support DevOps culture. People are more involved, because they are responsible for a full-stack functionality.
- You get closer to Continuous Delivery. It’s easier to automate as many things as possible, because there aren’t any huge and complicated global dependencies.
- Teams have better understanding of their components. Microservice teams are far better in logging and monitoring, because it’s the only way they can know what is going on inside.
- Application is designed for failure and it scales well. Services are smaller and are easier to reason about.
###Where is the catch?
- Microservices are slower. Services communicate over more expensive channel than components in monolithic application (e.g. HTTP vs in-process calls).
- Refactoring is harder. Moving responsibilities between services is harder.
- You only have eventual data consistency. Data management is decentralized in microservices, so you cannot guarantee consistency using transactions.
- Debugging a set of services is hard. The only way to know, what is going on in a set of services is to have a very good logging and monitoring solution.
- It’s very hard to prototype using microservices, because of all changing APIs.
Remember that there are always trade-offs in decisions like that. Monolithic applications are still simpler to built. The best way is to start with monolithic unless you are completely sure that you need to use microservices. You can always switch to them later on, when the requirements and APIs are more stable.
