Benefits of Using a Service Mesh in Application Integration with IBM App Connect Enterprise
This is the first part of a three-part blog series, describing how an Istio service mesh architecture can be leveraged in Cloud Pak for Integration and OpenShift, when using App Connect Enterprise.
In 2019, Tim Quigly and Claudio Tag highlighted the benefits of using a service mesh like Istio with IBM's containerized integration platform in this video. These Istio patterns demonstrated further integration between containerized services, clarified differences between service mesh and API management, and brought DevOps to traditional integration capabilities with A/B testing, canary deployments, and more.
This happened just around the time of IBM’s acquisition of Red Hat. Red Hat OpenShift is now embedded in IBM’s integration portfolio, not to mention in customer production environments that have long been running IBM software. In this post, we show you the benefits of using a service mesh with IBM App Connect Enterprise.
Service mesh
Going cloud-native is exciting, but not simple. A rise in the number of applications, endpoints, abstraction and distribution inevitably leads to more complex interactions. If you've begun to adopt containers, what was once a single service may have been partitioned into several microservices. You could instruct each single container to communicate with each another container individually, or you could configure the service mesh to monitor and make traffic decisions across many containers.
The Redbook publication Accelerating Modernisation with Agile Integration explores benefits and considerations for microservices in today’s dynamic applications. We see a shift from static endpoint configuration to managed communication between fluctuating endpoints. A service mesh offers simplification, enhancement, and abstraction for this service communication complexity, and is expected to interact natively with Kubernetes.
If a service mesh sounds similar to another trend in integration, you may want to read about how it differentiates from API management here https://developer.ibm.com/apiconnect/2018/11/13/service-mesh-vs-api-management/
Kubernetes and the need for a service mesh
Let’s expand on how Istio enhances functionality of Kubernetes.
Before an application is componentized or microservice-ified, considerations such as security or load-balancing might be hard-coded into the monolith. Why not? At the time of creation, those security rules might apply uniformly to the entire application. There might be only one point of access.
As the application becomes more distributed, and evolves to meet the demands of more release cadences, sprints, language skillsets, third party tools and customizations, considerations that were assessed just once have to be reassessed for each endpoint. The plan to move to a microservice architecture typically accompanies adoption of K8s, which does help meet the mixed demands of people and processes, but it only goes so far.
Kubernetes has simplified application scalability, portability, transparency, version control, and the list goes on. As a container orchestrator, it allows developers to deploy what they want when and where they want. That’s fine until the freedom of decentralized development is confronted with the realities of production environments, in particular the complexity of multiple microservices being rolled out at a high pace.
To address some of those complexities, typically the Kubernetes ecosystem is augmented by a service mesh. At a high level, a service mesh is responsible for:
- Providing efficient communication between services
- Abstracting the mechanism for reliable request/response delivery from the application code
- Handling network failures by using, for example, configurable re-try patterns
- Providing visibility and control of the service-to-service communication
- Simplifying secure communication between services
More specifically, typical functional requirements for a service mesh are:
- Service discovery
- Service registry
- Traffic management
- Traffic encryption
- Observability and traceability
- Authentication and authorization
- Failure recovery
Often a service mesh also enables more complex operational capabilities, like A/B testing and canary rollouts, rate limiting, access control, and end-to-end encryption. From a non-functional point of view, all these capabilities are available to applications and their components without affecting the application code. As a result, developers can leverage them without having to instrument their code.
Istio
Istio (https://istio.io) is one of the most popular implementations of a service mesh. Istio is a Kubernetes-compatible open platform for providing a uniform way to integrate microservices, manage traffic flow across microservices, enforce policies and aggregate telemetry data. From a high-level functionality perspective, Istio allows you to connect, secure, control, and observe your containers as they run on Kubernetes.
Istio is an open source project created by Google, IBM, and Lyft, with contributions by Red Hat. It is one of the fastest growing projects on GitHub (https://octoverse.github.com/#fastest-growing-oss-projects-by-contributors) at the time of writing. It can be integrated into other logging, telemetry, or policy systems. In sum, Istio’s features are designed to support running a distributed microservice architecture with uniform security, connectivity, and monitoring.
Istio is logically split into a data plane - sidecar containers for mediating and controlling network communication between microservices - and control plane - management and configuration of sidecars/proxies. You can learn more about Istio architecture here https://istio.io/v1.5/docs/ops/deployment/architecture/. These sidecar containers let you add Istio capabilities, direct traffic between application services, and collect telemetry data without rearchitecting or rewriting code. Note that sidecar injection can be done either automatically or manually, as this distinction is important for adopting a service mesh in Cloud Pak for Integration. (https://istio.io/latest/blog/2019/data-plane-setup/)
Istio provides little value if there are no application services in containers—so let’s introduce the evolution of the service bus.
IBM App Connect Enterprise
A number of changes were made a few years back to IBM App Connect Enterprise (formerly known as IBM Integration Bus) such that it could more effectively support the containerization and decentralization of integration. Previously, a central integration node was designed to perform an administrative function over integration servers, but now integration servers can be run independently for ease and speed. (https://www.ibm.com/support/knowledgecenter/SSTTDS_11.0.0/com.ibm.etools.mft.doc/bb23850_.html)
The new runtime architecture prescriptively differentiates implementation of IBM App Connect Enterprise (ACE), and the evolution of container culture means today’s modernization conversations are about more than just moving integration flows to someone else’s data center. ACE has long been available as a Docker image, allowing unchanged integration servers to be deployed as “microservices”, but IT isn’t just reactively breaking up the broker anymore. Organizations are proactively seeking new ideas and new patterns for the backbone of their integration estate.
Duplicate resources might traditionally be provisioned for testing out new services or versions, but separate environments alone don’t provide a mechanism for gradual redirection when these tests prove successful. There may be a traffic-splitting flow with a gateway in front of it, both of which require maintenance. The entire process may be even more complex if the monolith application has been partitioned. Service mesh functionality such as Istio and Kiali provide insight into version performance and simplify traffic rerouting, making A/B testing practices and decisions more suitable to the orchestrated container foundation and introducing a livestock not pet approach.
Organizations may discover more control, more convenience, and therefore more frequency in ACE deployments with out-of-the-box Istio functionality. It isn’t a silver bullet, but perhaps because it isn’t an IBM product, it has the misfortune of being overlooked.
Summarising the benefits of adopting a service mesh in integration
In summary, the core reasons for adopting a service mesh in the application integration space are:
- Security: simplify locking down of integrations in a zero-trust model, minimizing threats when they are deployed on progressively shared infrastructure.
- Deployment: simplify and reduce risk when releasing updates to integrations by using canary testing to perform safer rollout and instant rollback.
- Fault tolerance: separate and standardize resilience mechanisms such as retries, circuit breaker patterns and rate-limiting, thus reducing the knowledge of the integration needed to make adjustments at runtime.
- Observability: integrations by definition are always part of a chain of interactions. The mesh enables standardized logging, metrics, and tracing, allowing to perform consistent diagnosis of the whole invocation chain.
- Testing: simulate issues in back end systems through configuration, reducing/removing the need to create and insert mock stubs to test against.
Conclusion
So far, we had a look at the general concepts and theoretical benefits of using Kubernetes, Istio, and ACE. For those interested in the practical details, the second part of this series describes how the OpenShift Service Mesh can be used in practice in Cloud Pak for Integration, with particular focus on the steps needed to make ACE and Istio work together seamlessly.
References
Acknowledgments
This post has been contributed to and reviewed by Kim Clark, Timothy Quigly, and Claudio Tagliabue.
#IBMCloudPakforIntegration(ICP4I)#AppConnectEnterprise(ACE)#integrationplatfrom