Like any new trend in IT architecture, the main issue is ensuring there is a definition that everyone agrees on. When doing research about microservices it is already easy to see that there are several definitions that are slightly different from each other. The purpose of this article, the first in a series on using microservices for moving to The Cloud, is to focus on what we think makes up a microservice and why they are becoming more important.
Our definition is:
• A small problem domain
• Built and deployed by itself
• Runs in its own process
• Integrates via well-known interfaces
• Owns its own data storage
A small problem domain
A service can only be described as micro if it deals with one job or function (a small problem domain). The service should be easily understood by anyone who needs to use it either through its interfaces or through the code itself.
Built and deployed by itself
Each microservice should be stand-alone that is – it should be possible to build and run the service in complete isolation from any other services or systems. That makes services much easier to test in integration terms and reduces the complexity of the entire system.
Clearly, some microservices will need to call (use) other microservices but as that usage should be via interfaces these can be “mocked up” for testing purposes.
The value of this in production is that the size of any change can be very small, and deploying lots of small changes continuously has significantly less risk than large complex changes.
Runs in its own process
Each microservice should run as a standalone service which means that the technology used for each service can be different and appropriate for the service it is running. This does not mean that each microservices requires its own server it just means they need to be run as separate processes which could be enabled via virtualization or container technology.
Integrates via interfaces
Microservices are the latest generation of architectural components that are loosely coupled via well-defined interfaces.
Microservices are loosely coupled vertical stacks. Each microservice should communicate with other services via well-known interfaces. This is simply described as a contract between the service and its user – you provide me with information in this format and I will give you back information in a specified structure. By using this approach the developer of the microservice can do what they like with the coding of the service on condition that the interface does not change.
Owns its own data
A microservice owning its own data gives it the freedom to “do what it wants” with the data in terms of modifying layouts, manage persistence and manage the behavior of data inside the service.
Clearly, there will be a need for some microservices that do not own data, for example, the services that update corporate databases with the results from microservices.
Why Are Microservices Important?
It has been over a decade since the idea of a services oriented architecture was first introduced and during that time various attempts have been made to make it a solution that was commercially viable to use. Technology has progressed at a rapid rate meaning that taking the idea of a service and actually implementing it is now a real solution rather than the idealistic proposal it was 10 years ago.
Now, we can develop an architecture that is based on the idea that it is easy to change something when the requirements change and that can be deployed on a heterogeneous technology stack to provide solutions that are easy to implement in changing environments without massive rework when things do change.