Sometimes, big things come in small packages, and that’s certainly the case when it comes to developing with microservices.
Microservices architecture is a distinctive approach to software development that – according to IDC, at least – will account for 80% of application development on cloud platforms by the year 2021. In another recent survey, more than 75% of developers said they are working with microservices. The reasons are clear: Unlike traditional, “monolithic” applications, which are built and deployed as a single unit, microservices-based application architectures are composed of small, independently versioned and scalable services, each of which is designed to fulfill a specific purpose. Acting together, they address a larger, more complex business goal, using a well-defined interface and standard protocols.
Because they are independent of each other, software services built using this architecture can be deployed, tested, tweaked and then redeployed without impacting the overall system. Contrast that with monolithic applications, in which a small change to any module requires rebuilding and testing the entire system, leading to downtime and system inaccessibility.
Microservices in Action
Considering today’s need for continuous and ongoing innovation in customer-facing features and services, it’s clear why the use of microservices is on the rise, but it’s not an approach to enter into lightly. Migrating to a microservices architecture poses several challenges, including increased complexity, a fast-changing system landscape, performance issues arising from remote service communication and increased risk of service failures.
Many of these challenges can be addressed through the use of a microservices reference architecture. For example, we recently worked with a leading U.S. healthcare company to create an agile platform for addressing dynamic business and consumer-centric needs. The existing process was fragmented, with many manual and nonstandardized steps. Further, the existing system presented several drawbacks:
- The highly monolithic systems were unable to adapt and scale according to the company’s digital needs.
- The system’s highly batch-driven processing limited real-time data accessibility and slowed down analytics and decision making.
- Data management existed in silos, resulting in inconsistent data.
- Governance was highly complex.
- A lack of automation caused data latency and redundancy.
In designing and implementing our solution, we used a cloud services platform and a microservices architecture which enabled the following:
- Data consistency: Integration between the microservices and a dedicated event processing system drives data consistency across the enterprise by communicating data changes with other systems.
- Automated intersystem workflows: Events are sent between services that can trigger key business process in other systems.
- Better decision making and predictive analysis: Agility is ensured through historical, enterprise-level aggregated event data, contextual business rules and predictive analysis methods.
Because the implementation was cloud-based, the following advantages were also realized:
- Elasticity and rapid provisioning: The dynamic nature of the cloud architecture allows microservices to be quickly spun-up.
- Designed for failure: Microservices are distributed across the data centers, with the built-in high availability of the cloud architecture.
- Monitoring: Microservices leverage the rich monitoring capability of the cloud to resolve the chain of failures.
With the microservices-based implementation, the healthcare provider realized the following benefits:
- Improved agility, through faster time to market of business data.
- Enhanced consumer experience, through easier and simpler integration with consumer apps; expanded consumer reach with availability of enterprise data over APIs; and faster response times for services.
- Faster developer onboarding and increased efficiency. Developers have increased their adoption of APIs, enabled by a customized developer portal and standardization of API specification design
- Improved maintenance and faster deployment, as components are deployed independently.
Making the Migration
Microservices aren’t the answer to every question. A monolith-first or monolith-only approach is still appropriate under these conditions:
- The proposed or existing application will be easier to maintain and manage in monolithic form.
- It makes business sense to avoid the upfront costs of investing in microservice architecture.
- Decoupled application components are not important to near-term business strategies.
- The right talent to support microservices is not available.
- The business doesn’t have enough tools and technologies to support microservices.
When using microservices, development teams need to work closely with users to develop clear and specific business requirements for the solution in question. It’s also vital to have an efficient IT governance model to ensure thorough version management and uniform documentation practices. While microservices are more flexible than a monolithic development approach, implementing so many different and rapidly evolving components requires careful coordination.
To begin the migration to microservices, organizations can identify monolithic legacy systems that can be “decomposed” into a cluster of microservices, rendering a set of autonomous, independently deployable and scalable components. This approach can help them leverage the thinking and processes required to migrate to microservices, and spark ideas for new customer-facing features and services.
One way or another, the time is fast arriving when businesses will need to begin the move toward microservices – and realize the resulting agility, resiliency, scalability, flexibility and speed to market.
Vijay Francis (Senior Director, Cognizant Digital Systems & Technology) and Abhijit Bharadwaj (Associate Director, Cognizant Digital Systems & Technology) contributed to this blog post.