Microservice capabilities are expressed formally with business-oriented APIs. They encapsulate a core business capability and as such are assets to the business. The implementation of the service, which may involve integrations with systems of record, is completely hidden as the interface is defined purely in business terms.
There are several intrinsic benefits to microservices. Positioning services as valuable assets to the business implicitly promotes them as adaptable for use in multiple contexts. Additionally, the same service can deliver its capabilities to more than one business process or over different business channels or digital touchpoints. Here are six fundamental principles of microservice design.
Microservice design principle #1: Reuse
Reuse continues to be a principle of microservice design. However, the scope of reuse has been reduced to specific domains within the business. The effort of designing for this reuse, which in the early days of SOA included wasted efforts in designing enterprise-wide canonical models, was fruitless because it was too ambitious.
However, it must be noted that the canonical model in its restricted scope can be of benefit. In line with the reuse it facilitates, its scope has been reduced. With the ‘merit based reuse’ approach, an emerging model is preferred over a predetermined one. Teams can agree on communication models for deciding how microservices must be adapted for use outside the contexts in which they were designed.
A collaboration hub like Anypoint Exchange encourages merit-based reuse with reviews and ratings. If an existing microservice API does not suit your domain or ‘business group’, you might be better off building another microservice that does it.
Microservice design principle #2: Loose coupling
Dependencies between services and their consumers are minimized with the application of the principle of loose coupling. By standardizing on contracts as expressed through business oriented APIs, consumers are not impacted by changes in the implementation of the service. This allows the service owners to change the implementation and switch out or modify the systems of record or even service compositions which may lie behind the interface and replace them without any downstream impact.
Microservice design principle #3: Autonomy
Autonomy is a measure of control that the implementation of the service has over its runtime environment and database schema. This enhances the performance and reliability of the service and gives consumers more guarantees about the quality of service they can expect from it. Coupled with statelessness, autonomy also contributes to the overall availability and scalability of the service.
Microservice design principle #4: Fault tolerance
Each service is necessarily fault tolerant so that failures on the side of its collaborating services will have minimal impact on its own SLA. Services, by virtue of being independent of each other, have the opportunity to cut off communication to a failed service. This technique, called a “circuit breaker” and inspired by the electrical component of the same name, stops individual service failures from propagating through the larger, distributed system.
Microservice design principle #5: Composability
All of these design principles mentioned able contribute to the principle of composability which allows the service to deliver value to the business in different contexts. Its composition together with other services to form a new service aggregate is effectively the new form of application development.
Microservice design principle #6: Discoverability
The aim of discoverability is to communicate to all interested parties a clear understanding of the business purpose and technical interface of the microservice. Thus, the service must be published in a way that ensures that developers of client software have everything they need to easily consume it.
Get started with a platform approach to microservices
Microservices is clearly an important and welcome trend in the software development industry, and has many advantages over previous architectural approaches. However, there are various concerns to be aware of when instituting a microservices architecture in your organization. Businesses need to implement microservices because of its ease of deployment and agile nature, but if not managed properly, this architecture can create disorganization and lack of governance.
Products developed with a microservices architecture will also need to be integrated with legacy technology stacks, and if this is done poorly, it can create technical debt and more operational costs for the IT team. Therefore, instituting microservices in a way that will create competitive advantage and help your company innovate faster goes beyond a mere selection of products and software.
This is why we recommend a holistic, platform approach to microservices, centered around API-led connectivity. Not only does API-led connectivity create the integration component so crucial to the proper function of your technology stack, it will allow developers inside and outside the central IT team to create new solutions in a manageable, reusable, and governed way, eliminating concerns of too many applications that the business cannot control. In addition, MuleSoft’s platform approach provides a unique operating model to allow both LoB and IT to build, innovate, and deliver new solutions wherever needed throughout the organization.