“In short, the microservice architectural style is an approach to developing a single application as a suite of small services, each running in its own process and communicating with lightweight mechanisms, often an HTTP resource API. These services are built around business capabilities and independently deployable by fully automated deployment machinery. There is a base minimum of centralized management of these services, which may be written in different programming languages and use different data storage technologies.”
– James Lewis and Martin Fowler
From this definition, we understand that microservices are small, independently deployable services that work together. These services are focused on doing one thing well (Single Responsibility Principle). In this style, you break down your larger system into multiple microservices that will interact with each other to accomplish the larger goal. There is no standard model for a microservices architecture but most share some notable properties.
First, they are autonomous. Microservices are typically created by componentizing the software, a component being a unit of software that is independently replaceable and upgradeable. This is especially important as more applications are being deployed to the cloud where load demands can increase dramatically. All communication happens via lightweight networking calls (APIs). The aim is to be as decoupled and as cohesive as possible.
Microservices do not need a standard technology stack. While traditionally large software applications standardize on a single technology stack, when you split your software into independent services you can choose your technology stack for each service. For example, you can use C/C++ for real-time services, Java for the GUI, and Node.js for reporting. You should remember that there will be overhead for having different technology stacks for each service.
You need to design your services to handle the failure of other services; they need to be resilient. This is a side-effect of making the software individual components. You need to consider how a failure of a single service will affect the overall user experience. As a consequence of this, each service should fail as quickly as possible and restore itself automatically, if possible.
Scaling is one of the big advantages of microservices and one of the reasons it is so popular. Since each service (feature) does not depend on the other services, they can be deployed separately. You can now distribute the services across servers and replicate them as load demands increase. Compare this to traditional development that must scale the entire application as demands increase.
Different microservices can be owned by different teams. Teams are cross-functional, which means that they contain the full range of skills for the development of the service. The development team builds the software and owns the product for its lifetime. An example of this is Amazon’s philosophy “You build it, you run it.” The advantage is that the development team now has special insight into how users are using their service and can tailor future development to their needs. Teams can also be organized around business capabilities but you will need to watch out for Conway’s Law where the design tends to mimic the organizational structure (see our blog post Overcoming Conway’s Law: Protecting Design from Organization).
Finally, because of the componentization of the software there is a lot of opportunity for reuse of functionality. In the microservices architecture, as you are making the software individual components you should also be designing them so that many different programs can reuse the functionality. This does take significant effort and awareness to be done correctly but can also lead to increases in quality and productivity (for more information see “Effects of Reuse on Quality, Productivity and Economics” by Wayne C. Lim).
To summarize, microservices: are autonomous, using services to componentize the software; use decentralized governance; are designed to handle service interruptions; are easily scalable; focus on products not projects; are typically organized around business capabilities; and promote software reuse. To learn more see our whitepaper “Developing a Microservices Architecture.”