In this article I will summarize what I learned, based on 7 different talks:
Microservices is a way to develop single application by dividing it into several independent, but inter-operating, systems. There are several benefits and problems in this architecture.
Main benefits include:
Unfortunately, there are some challenges. Instead of one application, we have now several dozen of services. Many simple solutions in traditional architecture are difficult in microservices:
Microservices should be modeled around business domain. In best case scenario they should implement single business functionality.
It is very important that services are very loosely coupled. It means that you should avoid sharing code between services. Services should also use independent databases. Shared database leads to tight coupling.
Most popular frameworks for creating microservices are:
API for a microservice should be written by his consumer. Consumer should also write automated acceptance test for service.
For consumer driven contract development you could use for example Accurest.
There are several libraries for calling other services:
It is very important to use some fault protection mechanisms while calling other microservices. Without fault tolerance failure in one service could propagate and kill whole application.
The most popular library for writing fault tolerant code is Hystrix.
Configuring many services can be made easier by using configuration server. Configuration server is centralized repository for configuration, but also can be used to version control services configuration.
There are couple solutions for config server:
Keeping IP addresses for each service can be cumbersome. Problem is even more difficult when you are dynamically adding instances of microservices. Service discovery is used to dynamically register microservices in centralized system. Other services can later used discovery to get IP addresses for registered services. Discovery can also be used for load balancing.
Here are some service discovery systems:
When there is an application error, it is not practical to grep log files from all of microservice instances. It is better to have centralized log database.
It is helpful to generate correlation id for all application requests and propagate it in the system. By using correlation id you can later investigate how request was processed in several microservices.
There are several tools for application logging:
Besides logs, other important aspect of monitoring application is metrics. Metrics can give you information about aggregated times of running critical tasks, rate of important events or information about used application and system resources. It can give you insight about which service failed and why. You could also extrapolate the data to predict maximum system load.
There are several tools to collect metrics data:
There are several technologies for service testing:
Deploying manually can be time consuming and error prone. It should be possible to deploy services independently, so you could change version of one microservice without touching others.
It is also a good idea to have coexisting endpoints when api for microservice changes. Older services could use old api, while newer versions are using newer api.
There are several tools for continuous integration and deployment:
To further abstract runtime environment, it can be a good idea to run services in container.
There are several levels of abstractions:
At the Devoxx there were many presentations talking about creating microservices. Creating application with microservice architecture is only half a battle. To have successfully running application you should have means to change configuration, monitor, check logs, test and deploy new versions of services. Fortunately there are many tools to choose from to create highly reliable systems.