As with any architecture or technology, there are benefits and liabilities; the microservices architecture is not an exception. Since you have a good understanding of the key microservice characteristics, this is a good time to talk about them.
Benefits
One of the main reasons for the popularity of the microservices architecture is the benefits that it provides over conventional software architecture patterns.
Let’s have a closer look at the key benefits of the microservices architecture.
Agile and Rapid Development of Business Functionalities: The microservices architecture favours autonomous service development, which helps us with the agile and rapid development of business functionalities. In a conventional architecture, converting business functionality to production-ready software application functionality takes many cycles, primarily due to the size of the system, codebase, and dependencies.
With autonomous service development, you just need to focus on the interface and the functionality of the service (not the functionality of the entire system, which is far more complex), as all the other services only communicate through network calls via service interfaces.
Replaceability: Due to their autonomous nature, microservices are also replaceable. Since we are building services as an independent entity, which is communicating via network calls and defined APIs, we can easily replace that functionality with another better implementation. Being focused on a specific functionality, having a limited scope and size, and deploying it in an independent runtime, all make it much easier to build a replaceable service.
Failure Isolation and Predictability: Replaceability also helps us to achieve failure isolation and prediction. As discussed, a microservices-based application cannot blow up like a conventional monolithic application due to the failure of any given component or service. Having proper observability features also helps us to identify or predict potential failures.
Agile Deployment and Scalability: With modern cloud-based container-native infrastructures, the ability to easily deploy a service and scale it dynamically is becoming trivial. Since we are building capabilities as autonomous services, we can easily leverage all such container and cloud-native technologies to facilitate agile deployment and scalability.
Align with Organizational Structure: Since microservices are business capability-oriented, they can well be aligned with the organizational or team structure. Often, a given organization is structured in such a way that it delivers its business capabilities. Therefore, ownership of each service can easily be given to the teams that own the business functionality.
Liabilities
Most of the liabilities of the microservices architecture are primarily due to the proliferation of services that you need to cope with.
Inter-Service Communication: Inter-service communication complexity could possibly be more challenging than the implementation of the actual services. The smart endpoints and dumb pipes concept forces us to have inter-service communication logic as part of our microservices. The service developers have to spend a substantial amount of time on plumbing microservices together to create composite business functionality.
Service Governance: Having a number of services communicated over the network also complicates the governance and observability aspects of services. If you don’t have the proper governance and observability tools in place, it will be a nightmare to identify service dependencies and detect failures.
Heavily Depends on Deployment Methodologies: The success of deploying and scaling microservices is heavily dependent on the adoption of containers and container orchestration systems. If you don’t have such an infrastructure in place, you will need to invest time and energy in it (and don’t even think about having a successful microservices architecture without containers).
Complexity of Distributed Data and Transaction Management: Since a microservices architecture promotes localizing the data to a given service, distributed data management will be quite daunting. The same applies to distributed transactions. Implementing transaction boundaries that span across multiple microservices will be quite challenging.
Posts
No comments:
Post a Comment
Note: Only a member of this blog may post a comment.