Microservices pattern is a way of designing software applications through independent deployable services. Each services will be running on its own processes. This gives more scalability in comparison with Monolithic architecture and been leveraged by multiple companies in the modern technology world.
A microservices-based approach has become one of the most widely discussed IT topics in recent memory. This is due to traditional Service Oriented Architecture and Domain Driven Design approaches, which are giving more maintainability to enterprise applications. There are small independent providers which integrate with business processes with no dependency on external services.
In the case of SOA, an enterprise IT team really needs to build a maturity platform and ensure the right deployment strategy is achieved. In my opinion, Microservices will help an IT team deploy the processes as stand-alone independent unit services. This will provide simplification on Infrastructure processes and lessen usage of heavy applications.
There are two types of Microservices – Stateless and Stateful. As the names depict, both differ in the way the state is maintained. Stateless microservices will be utilized for processes where state of the process will not be maintained and Stateful microservices will be maintained in its own databases.
This article talks about the difference in traditional Monolithic architectural and Microservices architectural patterns.
An example would be the Oil and gas domain which consists of 3 main streams – Upstream, Midstream and Downstream:
Architecture Patterns- The diagrams below depicts the monolithic and Microservices-based architectural pattern for the process areas mentioned above.
Typical Enterprise platforms in this domain cover order management to invoicing, which includes the fulfillment process. There can be multiple interdependencies between each process with respect to data and availability. In a Monolithic based applications, each application will include the business process components and services in a more tightly coupled nature.
When we bring Service Oriented Architecture pattern in place, most of these services will be moved to stand-alone business process components/services and every application can leverage the same.
In the case of Monolithic application architecture, each application consists of related processes. With frequent changes in business processes, maintenance of this is a challenge always. Since it is tightly coupled with the application, it may have redundant functionalities in multiple services and deployment was also difficult to attain. If any specific process area, for example – pricing service needs to extend further based on new rules or accommodation of pricing from multiple regions, it always ends with changes in the associated services modules and integrated applications.
A Microservices pattern brings some definite advantages to the above challenges. In the Microservices Architecture diagram, each service can be developed and deployed as a separate entity. The diagram depicts a stateful architecture where each service will maintain the state in respective databases.
- If there are any specific extensions or changes in the respective services, it will not impact any other systems or services until we change the contract of the exposed services.
- Ease of deployment, irrespective of systems and consumers.
- Functional decomposition (SOA pattern) of application in to services.
Surely microservices architecture is not without challenges. The right architectural pattern considers scalability, performance and partitions of services etc., which are required as part of the selection. I will detail the same in Part2 of this article of how Azure Service Fabric can be leveraged to build the Enterprise applications for domains using Microservices architectures.
*Adapted from LinkedIn post by Nandakumar Sivaraman