Innovating with Microservices – Part 1

By: Sachin Dhamane & Manish Shah |

If you are part of building a modern digital enterprise platform for mid-to-large insurance companies or part of a startup who distinguishes themselves through innovative technologies, it is highly unlikely that you have not come across the word – 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, who built and scaled their platforms based on microservices architecture, have galvanized adoption across many industries.

Source: Google Trends

We are often asked about the applicability of microservices to insurance. 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. We would love to hear your views.

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 principals of designing a microservices based platform. And the final blog will share how our new, innovative Majesco Digital1^st platform will help insurers simplify and accelerate the development of microservices apps.

Let’s start with the basic question, “What is 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, 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 monolith unit.

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. Since 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 codebase that must be managed as a single deployment unit.

In contrast, a microservices architecture has the following advantages when done well:

1. Velocity and Agility – Maintenance and evolution of Monolith applications is expensive and slow due to the inadvertent side effects of impacting other functions and services. This requires additional necessary 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.

 

2. Scale – Microservices allow easy monitoring that can predict seasonal or unique business demands on a business function. Since 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.

 

3. Decentralized Governance and Teams – The separated codebase 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 best technology suited for the business function.

 

4. 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 impacting 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.

 

5. 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.

As with all innovation, there is a flip side to the coin.  Unfortunately, not all organizations are ready to adopt a microservices architecture immediately. In particular, if a company cannot build a well-designed monolith, then building a microservices platform will be much harder. Microservices architecture is inherently complex to develop as well as operate, but the rewards of the complexity are, however, worth the hurdles, because microservices will give the reconstructed organization far greater efficiency and future-focused capabilities.

Fundamentally, microservices requires organizational change, not just adoption of a technology pattern. Organizations must rethink end-to-end DevOps by thinking in terms of small business functions, distributed teams, decentralized governance, and continuous delivery. In addition, the organization must embrace multiple technologies suited for a business platform rather than a single technology platform, which is a significant change for organizations schooled in building applications using traditional software development processes.

Even success stories like Amazon and Netflix did not start with a microservices architecture, rather they evolved overtime as they matured. If you are building a MVP (Minimum Viable Product) as a startup, it may not be advisable to delay market launch due to the large upfront effort of establishing microservices. However, startups should consider that at some point they’ll have to invest and migrate to microservices to support scalability and changing business models.

Operating a platform made of hundreds or thousands of microservices, while enabling scalability and growing business demands, does create tremendous complexity for deployment, auto-scaling, monitoring, logging and many other DevOps aspects. Microservices deployment at Amazon and Netflix (Images by AppCentrica) show the complexity of managing a reliable business operation with millions of ongoing deployments within an interconnected ecosystem of microservices — often written using different languages and databases.[i] Companies like Amazon and Netflix deal with this complexity through a high degree of automation and significant investment into sharing and automating the infrastructure to build resiliency.

 

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.

We believe that every organization should exercise patient urgency (“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.” – Chunka Mui) for innovating business platforms using microservices architecture.

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.

 

[i] Images courtesy of AppCentrica Insights, https://www.appcentrica.com/the-rise-of-microservices/