Whether you are part of building a modern digital enterprise platform for mid-sized to large insurance companies or part of a startup that distinguishes itself through innovative technologies, you are likely to be hearing about microservices.
Microservices architecture has increasingly become popular and often associated with benefits such as scale, speed of change, ease of integration, fault tolerance and ability to adapt to changing business demands and models. Commitment from digital giants such as Amazon, Netflix, PayPal, eBay, Twitter and Uber, which built and scaled their platforms based on microservices architecture, has galvanized adoption across many industries.
[caption id="attachment_30424" align="alignnone" width="570"]
Source: Google Trends[/caption]
A crucial question is, “How will microservices help insurers design open platforms for building sustainable competitive advantage?”
This four-part blog series will share our views based on our experience in building a modern digital platform using microservices. This first blog will provide a general primer about microservices. The second will share our view on the applicability and strategic potential of microservices for insurance. The third will illustrate best practices and applied principles of designing a microservices-based platform. The final blog will share how our innovative Majesco Digital1st platform will help insurers simplify and accelerate the development of microservices apps.
Let’s start with the basic question, “What are microservices?” You can find the answer through a simple Google search, but let’s explain it in simple terms. Think of a microservice as a micro application that enables a specific granular business function like payment, issue, policy documents, first notice of loss (FNOL), etc. The micro application can be independently deployed and can communicate with other micro applications serving other business functions through a well-defined interface. This approach is in stark contrast to “monolith applications,” such as policy management systems, billing systems and claims systems that work as an aggregation of multiple business functions tightly woven together and must be deployed as a large, monolithic unit.
See also: It’s Time to Accelerate Digital Change
An architectural pattern called self-contained-service (SCS) is often discussed along with microservices but does not provide the full benefits of microservices. The SCS pattern recommends putting cohesive services together as a self-contained, individually deployable unit. Because the individual services are no longer self-contained and individually deployable, they cannot be considered microservices. While this approach is better than the monolithic application, it is instead building multiple small monoliths!
So why does anyone advocate the microservices approach? Simply put, it addresses the issues of monolith architectures that inhibit digital models. Even after functional decomposition and the use of several deployment artifacts with monolith architectures, they are still part of a single code base that must be managed as a single deployment unit.
In contrast, a microservices architecture has the following advantages when done well:
Despite the complexity in managing microservices, separation of responsibilities across microservices offers organizations significant benefits in today’s platform economy. We outline these in our thought leadership report, Cloud Business Platform: The Path to Digital Insurance 2.0. The constant pivoting of business priorities requires a continuous and high degree of system changes that enable new strategies. Microservices can bring great value to agility, velocity, availability, scalability and accountability across both technical and business organizational dimensions.
See also: A New Way to Develop Products
We believe that every organization should exercise patient urgency, which author and futurist Chunka Mui describes as "the combination of foresight to prepare for a big idea, willingness to wait for the right market conditions and agility to act straight away when conditions ripen.”
We look forward to covering our views on the role of microservices in insurance in Part 2. Please share your views on this exciting topic in the comments section. We would enjoy hearing your perspective.
This article was written by Manish Shah and Sachin Dhamane.
Source: Google Trends[/caption]
A crucial question is, “How will microservices help insurers design open platforms for building sustainable competitive advantage?”
This four-part blog series will share our views based on our experience in building a modern digital platform using microservices. This first blog will provide a general primer about microservices. The second will share our view on the applicability and strategic potential of microservices for insurance. The third will illustrate best practices and applied principles of designing a microservices-based platform. The final blog will share how our innovative Majesco Digital1st platform will help insurers simplify and accelerate the development of microservices apps.
Let’s start with the basic question, “What are microservices?” You can find the answer through a simple Google search, but let’s explain it in simple terms. Think of a microservice as a micro application that enables a specific granular business function like payment, issue, policy documents, first notice of loss (FNOL), etc. The micro application can be independently deployed and can communicate with other micro applications serving other business functions through a well-defined interface. This approach is in stark contrast to “monolith applications,” such as policy management systems, billing systems and claims systems that work as an aggregation of multiple business functions tightly woven together and must be deployed as a large, monolithic unit.
See also: It’s Time to Accelerate Digital Change
An architectural pattern called self-contained-service (SCS) is often discussed along with microservices but does not provide the full benefits of microservices. The SCS pattern recommends putting cohesive services together as a self-contained, individually deployable unit. Because the individual services are no longer self-contained and individually deployable, they cannot be considered microservices. While this approach is better than the monolithic application, it is instead building multiple small monoliths!
So why does anyone advocate the microservices approach? Simply put, it addresses the issues of monolith architectures that inhibit digital models. Even after functional decomposition and the use of several deployment artifacts with monolith architectures, they are still part of a single code base that must be managed as a single deployment unit.
In contrast, a microservices architecture has the following advantages when done well:
- Velocity and Agility – Maintenance and evolution of monolith applications is expensive and slow due to inadvertent side effects, because they affect other functions and services. Dealing with the side effects requires additional work, including vital tasks such as impact analysis, elaborate and expensive testing and forcing changes into large and infrequent releases to optimize testing efforts. In contrast, a microservice is a low-impact, single-responsibility business function that performs its own individual tasks, manages its own data and communicates with other microservices through a well-defined interface. It allows you to make and deploy changes reliably, incrementally and more quickly, in contrast to monolith architectures.
- Scale – Microservices allow easy monitoring that can predict seasonal or unique business demands on a business function. Because each microservice runs in its own process, it can easily be scaled with elastic containers, which efficiently scale up and down. In comparison, a monolith architecture runs multiple business functions under a single process, making it harder to orchestrate the feeding of resources to targeted business functions.
- Decentralized Governance and Teams – The separated code base of microservices allows different parts of an organization to build business functions as opposed to a centralized large team. Each team can manage different microservices with full DevOps (development and operations) responsibility and accountability. This gives insurers the freedom to choose the technology best-suited for the business function.
- Self-Contained and Sustainable – With monolithic applications, when introducing a new business capability that requires the upgrade of external dependencies (OS, shared libraries, etc.) the entire application must be tested. In contrast, microservices are self-contained from OS down to the actual code required for implementation. This enables microservices to separately and individually upgrade without affecting unrelated application functions based on business/operational needs. This keeps the application stack relevant and avoids the risk of running applications on an obsolete technology stack.
- Hypothesis-Driven Development – The advantages outlined above lead to a completely different way of contemplating software development. The focus and conversation shifts from managing projects and defect backlogs to emphasizing new opportunities, experimentation and observing the application usage. Experimental software changes can be built and deployed quicker in small increments into production. When errors happen, they can be fixed in minutes and hours, rather than days or months. For major problems, the incremental functionality upgrade can quickly and easily be rolled back without loss of major functionality or downtime.
Despite the complexity in managing microservices, separation of responsibilities across microservices offers organizations significant benefits in today’s platform economy. We outline these in our thought leadership report, Cloud Business Platform: The Path to Digital Insurance 2.0. The constant pivoting of business priorities requires a continuous and high degree of system changes that enable new strategies. Microservices can bring great value to agility, velocity, availability, scalability and accountability across both technical and business organizational dimensions.
See also: A New Way to Develop Products
We believe that every organization should exercise patient urgency, which author and futurist Chunka Mui describes as "the combination of foresight to prepare for a big idea, willingness to wait for the right market conditions and agility to act straight away when conditions ripen.”
We look forward to covering our views on the role of microservices in insurance in Part 2. Please share your views on this exciting topic in the comments section. We would enjoy hearing your perspective.
This article was written by Manish Shah and Sachin Dhamane.
