Back in 2008, before Netflix famously began their move to a cloud-based microservices architecture, a single missing semicolon brought down the entire website for several hours. Having an entire system that is a single point of failure has made stringent governance processes necessary and development cycles long. This is in direct conflict with the requirement for businesses to respond quickly to a changing market and is driving the evolution of enterprise IT from the traditional model to the digital enterprise. Today, hundreds of microservices give Netflix the availability, scale, and speed they need to handle the growing number of users and devices, and allow a new level of fault tolerance, as shown by the development of the circuit breaker approach to prevent cascade failures by isolating the failure source.
A more granular architectural approach supports the agility and scalability that is required by the digital enterprise. It demands a flexible platform on which to develop, test, and host, and is a key enabler for DevOps. Whether you call them microservices or something else, breaking down your monolith into smaller chunks allows you to containerize them and deploy anywhere, enabling the move to the cloud.
Diversifying your IT
Moving away from legacy enterprise IT drives a diversification of technologies, breaking down business processes into frameworks where very specific, business-aligned functionality is split out and can be hosted by a variety of different vendors and technologies; whether this is cloud to provide cost-effective and flexible hosting of infrastructure (IaaS), a Software-as-a-Service (SaaS) solution or somewhere in between (PaaS).
The growth in channels through which the consumer interacts with the enterprise (e.g., mobile, internet-of-things), changes the IT model from a request-based approach to one where the key driver is event driven. The always-on economy changes the consumer’s expectations where instant response is the new normal, and IT must respond in real time and scale rapidly to meet the demand. All this requires a much more granular approach to delivering IT solutions.
Integrating the old with the new
Changing to a more granular, flexible approach requires an integration platform at the very heart of the architecture. Application programming interfaces (APIs) are the enabling technology that glues together the disparate components, moving away from proprietary integration technologies to open APIs that unlock the data previously hidden away behind proprietary applications and open it up for wider consumption. This allows individual functions to be treated as swappable components and enables the “citizen integrator”: to drive business innovation in a way that was previously unreachable.
Sitting beneath the APIs are the services that implement enterprise integration patterns or integrate with systems of record and/or external cloud-based services. With third-generation API platforms, the focus is also shifting from the more traditional enterprise service bus (ESB) to a more granular architecture where domain-driven, lightweight code components implement very specific functionality and communicate via open standard interfaces.
Example integration flow using microservices
Open source integration frameworks, such as Apache Camel and Spring Integration, suit a microservices-based integration architecture. They enable developers to implement all the major enterprise integration patterns. Combining with container technologies, such as Docker and Spring Boot, allows for fine-grained, de-coupled microservices to be developed rapidly and better supports a DevOps model with extensive continuous integration tooling. This suits an organization that has existing Java skills but also makes provision for microservices to be developed using the language of choice, or even a mixture of languages depending on the skillsets of the various teams. Because microservices interact via open standard APIs, the implementation of those microservices does not necessarily need to be the same.
The dark side of microservices
“By 2022, 90% of all apps will feature microservices architectures that improve the ability to design, debug, update, and leverage third-party code,” according to IDC. But is it always the right answer? A badly designed microservices approach can lead to “microservice sprawl,” and without that centralized control and discipline, the number of microservices will grow exponentially and create an IT landscape that is complex, difficult to manage, and actually reduce reuse rather than increase it.
This is further exacerbated by the ease of use of cloud services leading to an increase in shadow IT as different parts of the organization start to build their own services rather than waiting for the IT department to build them. Microservices architectures should be designed based on business domains and bounded contexts, where each microservice serves a specific, reusable purpose and has a well-defined scope. The organization then needs to ensure it has a catalog of all its available microservices to ensure they are not duplicated or used inappropriately.
The Capgemini way
Capgemini team works closely with its customers, providing strategic advice that ensures that you take the right direction on your cloud journey. We believe that solution architects and software engineers should spend their valuable time building code that provides business value and not engineering platforms on which to run them.
Thanks for reading!
Read ‘Unlocking the hybrid integration dividend’ thought leadership report or watch the webcast