Infosys experts share their views on how digital is significantly impacting enterprises and consumers by redefining experiences, simplifying processes and pushing collaborative innovation to new levels

« Microservices in the Insurance Industry - Part I | Main

Microservices in the Insurance Industry - Part II


...continued from Part I


Maturity Level in an organization for MSA      

When MSA is being introduced, it is important to be prepared to handle the additional complexities and realize the benefits. Below are some of the key competencies that are considered essential in an organization for effective implementation of MSA:

  • Containerization and Automated provisioning: One of the key drivers behind MSA is that services can be deployed and scaled independently, based on the demand. Also, MSA demands reliable and scalable infrastructure. For this to happen seamlessly, there is a need for containerization (e.g. Docker), and the provisioning of resources (servers, virtual machines, containers etc.) should be automated as much as possible. This can be achieved by the effective adoption of one of the various available cloud platforms (e.g. Azure, Cloud Foundry, AWS) for computing resources.
  • Monitoring: When MSA is adopted, one can expect a large number of services in the target state. By its very nature, one can expect very frequent changes and deployments of different services. In such a scenario, chances of any of the services not working as expected increase. To enable to quickly troubleshoot, pinpoint and fix an issue, it is important to invest in robust monitoring of all the services. Also, since transactions could span multiple services, the logging mechanism should ensure complete traceability.
  • Automated Deployment: Whether it is introducing new features, or fixing bugs, one can expect a large number of deployments within a short span of time in the MSA world, in comparison to monolithic systems. This calls for the ability to rapidly deploy changes, and hence tools and process to automate deployments as much as possible.
  • Agile and DevOps Culture: Rapid rolling out of new features, fixes and deployments requires Agile development and DevOps culture.
  • Event Driven Architecture, Eventual Consistency etc.: With MSA, data is expected to be private to every service. This requires a big change in mindset with respect to data consistency and the way systems are designed and developed. With a large number of services, interactions between different services is expected to be asynchronous, and it is important for the organization to embrace the concepts of Event Driven Architecture and Eventual Consistency.

E.g.: Consider a Policy Administration System that takes an underwriter through the various stages of a Policy - Submission, Quote, Bind, Issue etc. After successful completion of every stage of the workflow, it is necessary to update the status of the policy in the master data. This would be simpler in a monolithic system with a single database, since each action can have direct access to, and update all the necessary data within a single transaction. However, in the case of MSA, for instance, the Issue Service may not have direct access to the Policy master data. So, after the successful execution of the Issue service, an event may have to be published to a message broker with the necessary details, which will be subscribed to by the Policy Service, to update the status of the Policy in the Master Data. This is not an ACID transaction; here the data belonging to different services is expected to become eventually consistent.

MSA sample use case.png

  • API Management, Gateway, Security etc.: For a monolithic service, interactions between the client and the service, as well as security implementation tend to be simpler. However, with a large number of microservices, this would become complex. Hence, for instance, instead of every service in a MSA implementing security separately, an API Gateway may implement centralized security. Similarly, instead of the UI making a large number of calls to the services, an Edge Service may do the necessary orchestration and reduce the chattiness of interactions between client and services.
  • Service Discovery: In a MSA scenario, new instances of services can be launched on demand, moved to different computing resources, and so on. For a client to be able to easily and correctly connect to the target service, a Service Discovery (e.g. Eureka) solution is essential.
  • Resilience to Failure: When a monolith fails, the entire system fails. One of the key goals for adopting MSA is that when a monolith is split into a large number of small services, the failure of one of them should not bring down the entire system. But, if the services are too dependent on each other and not built to withstand failure of one or more individual services, it will defeat the purpose of MSA. Hence, it is necessary to design services keeping fallback procedures (e.g. using Circuit breaker) etc. in mind, to make the entire system resilient to failure.

 

Typical use cases in the Insurance Industry

In the Insurance industry, if we take the example of a Policy Administration System, some of the key functionalities include:

      • Account management
      • Intake of applications through various channels
      • Submission
      • Quote
      • Bind
      • Bill
      • Issue
      • Rating
      • Document Processing etc.

 

Before one dives into MSA, it is important to assess the overhead and risks involved, as well as the potential benefits. There are some key implementation considerations that need to be kept in mind:

    • Service Granularity: When a service has low granularity, it is less agile, but simpler with fewer interactions. On the other hand, when a service is highly granular, it is highly agile, but is more complex with high external interactions. The goal is to keep services small enough to stay focused and big enough to add value.
    • Data Ownership: For a service to be truly independent, it should have its own private data. Any communication with other services should be over exposed public interfaces.

 

Where MSA can work:

Some functionalities can be more easily segregated into independent services than others. For e.g., Account/ Customer management, Rating, Billing, Issue etc. are functionalities that can become truly independent microservices, if the underlying data models are well designed and interactions with other services can be minimized.

 

Where pure MSA may not be beneficial:

However, if there are functionalities (e.g. Submission and Quote) where the underlying data is very closely knit with each other and data consistency is very important, pure MSA can be a challenge. The overhead of managing data consistency and communications between such services can make it too complex and risky, thereby outweighing the benefits of MSA.

In such cases, it may be more beneficial to initially have granular services for each functionality along with a Shared Database. Later on, if required, there could be a remodeling of the database, to have separate databases for each service.

 

Other use cases for MSA:

There could be certain functionalities (e.g. document processing) that are highly resource intensive. Such functionalities are good candidates for microservices, since they can be independently deployed and scaled as per needs, thereby avoiding adverse impact on the performance of the rest of the application.

MSA - Transformation.png

Conclusion

The transformation from monoliths to microservices will help an organization improve its agility, speed-to-market and efficiency, and thereby compete better with its peers. However, there are no hard and fast rules for this transformation. What worked for one may not necessarily work for another organization.

Organizations that are pioneers in MSA faced a different set of challenges. Insurance is a different domain, with a more complex domain model. Transformation to MSA here will have a different set of challenges. It necessitates a major change in the mindset of all stakeholders - embracing concepts such as Domain Driven Design, Eventual Consistency etc. Systems will have to be designed accordingly, striking a balance between simplicity and agility.

Also, there are many pre-requisites to the adoption of MSA - some of the prominent ones being the capabilities in Automated Provisioning, Continuous Delivery, Monitoring, Agile Development and DevOps culture. Though an organization may start small with a single service, one has to eventually develop all these competencies before the widespread adoption of MSA.



References

http://blog.christianposta.com/microservices/why-microservices-should-be-event-driven-autonomy-vs-authority/

http://blog.christianposta.com/microservices/the-hardest-part-about-microservices-data/

https://www.nginx.com/blog/refactoring-a-monolith-into-microservices/

https://martinfowler.com/bliki/MicroservicePrerequisites.html


Post a comment

(If you haven't left a comment here before, you may need to be approved by the site owner before your comment will appear. Until then, it won't appear on the entry. Thanks for waiting.)

Please key in the two words you see in the box to validate your identity as an authentic user and reduce spam.