Solution Pattern: Comprehensive Service Architecture with API Management and Service Mesh

Architecture

The architecture will need to support these paradigms

  • Control and monitor services-services traffic within the organization boundaries

  • Support the ability to run microservices securely on zero-trust networks

  • Distributed tracing to troubleshoot and isolate bottlenecks in end-to-end request paths

  • Secure service-service communication from other internal teams such as other BUs or LOBs

  • Secure access to services from external clients and partner portals

1. Common Challenges

With the proliferation of microservices, managing how these services interact with each other is a challenge. A service mesh can help in easing some of this burden by standardizing and optimising how services work with each other.
A service mesh

  • creates a centralized point of control in an application

  • adds a transparent layer on existing distributed applications without requiring any changes to the application code

  • provides more complex operational functionality, including A/B testing, canary releases, access control, and end-to-end authentication.

Service meshes manage the east-west type of network communications. East-west traffic indicates a traffic flow inside a data center, Kubernetes cluster, or a distributed system.

02 arch servicemesh ew

On the other hand, APIs are the language of digital business. It’s tough to find a company or organization these days that is not exposing APIs to users, customers, clients, and partners as part of their digital transformation. Examples of capabilities required for traditional API programs include:

  • Scale to large numbers of APIs and request volume

  • End-to-end security with TLS

  • Flexible deployment and traffic routing features to support A/B, Blue/Green, Canary deployments

  • Developer portal to engage and onboard API clients

  • Client authentication and authorization

  • Application-level policy control

  • Analytics

API management is typically used in “north south” architectures where API clients live beyond trust and/or organizational boundaries. API Management makes it easy to manage these APIs, secure, control and monetize them.

02 arch apim nw

At the same time, as customers move to Kube-native and microservices architectures, we begin to deal with communication between large numbers of independent APIs to form complete applications. In these “east west” service architectures, there is a need to combine service mesh capabilities and API management capabilities. Some of the reasons could be

  • common services being built for use by the entire enterprise which needs more formal API Management based communication

  • Different LOBs accessing services with a formalised contract and billing services included

  • Need for Rate limiting, throttling, distributed tracing, mutual TLS

02 arch servicemesh apim

2. Technology Stack

2.1. Red Hat OpenShift Service Mesh

OpenShift Service Mesh helps to connect, manage, and observe microservices-based applications. It is based on open source projects Istio, Jaeger and Kiali to provide connectivity between application services and add capabilities like resiliency, security, observability, routing control, and insights

Key features

  • connect services securely by default with transparent TLS encryption

  • enforce a "zero trust" or "need to know" with fine-grained traffic policies based on application identities

  • control traffic flow with effective traffic management, which makes the applications more resilient

  • use service metrics to monitor application health, reliability, and performance

2.2. Red Hat 3scale API Management

Red Hat 3scale API Management makes it easy to manage your APIs for internal or external users.

  • onboarding new APIs is rapid and easy

  • a custom developer portal and interactive API documentation based on OpenAPI specs provide an easy way for developers to sign for APIs

  • in built analytics, monetization

  • access Control and Security, and setup rate limits

2.3. Red Hat API Management and OpenShift Service Mesh - better together

Most organizations can leverage both API Management and Service Mesh together to build a comprehensive service management architecture.

  • API Management manages traffic which flows outside a domain or enterprise boundary

  • Service Mesh manages traffic within a domain or enterprise boundary

The 3scale WebAssembly extension eases the integration of OpenShift Service Mesh and 3scale API Management, and it provides a standard way to inject 3scale API Management configurations into OpenShift Service Mesh for execution in a single data plane. This allows you to label a service running within the Red Hat OpenShift Service Mesh and integrate that service with the 3scale API Management solution.

3. An in-depth look at the solution’s architecture

Travelz is a local tourism company offering a host of services to their customer from their offices across their city. Their customers would walk into their office and work with an agent to choose a holiday destination package complete with picking a hotel, car services, flights and insurances!

Travelz customer have the following new requirements include
(a) managing how their internal services speak with each other (b) sharing APIs securely with external clients, there could a few challenges that can impact timely delivery.

The team would like to adopt an approach which would enable

  • ease of deployment, setup and maintenance of application infrastructure

  • less or no impact to existing services so as to limit time, efforts and risk

  • comprehensive application security

  • monitoring usage with a possibility to monetize

  • allow external clients to be able to sign up to the services through self-service

architecture step1

This demo takes you step by step how the architecture evolves with the business expansion of the company’s needs.

3.1. Scenario 1 - Launch of Travelz’s Online: Managing and Visualizing the microservices

With the arrival of the Digital World, their loyal customers wanted to Travelz to provide them with the best of holidays wherever the customers are! Travelz had to now go GLOBAL! Travelz’s Online Channel business unit aims to launch online tourism services in a number of different countries across the globe under their various brands!

architecture step2

With the rapid expansion of of their technical footprint, Travelz IT team would like better control over their tech estate. They would like to

  • Manage access of the core Travels services from the online channels. These things cost money!

  • Traffic management

  • Intuitive end-to-end observability

  • Monitor and Trace requests

  • Enforce a "zero trust" network security

For this purpose, Travelz IT introduces a Service Mesh to connect, manage, and observe microservices-based applications. OpenShift Service Mesh is based on open source projects Istio, Jaeger and Kiali to provide connectivity between application services and add capabilities like resiliency, security, observability, routing control, and insights

architecture step2 1

3.2. Scenario 2 - Engaging with Partners: Opening API access to external partners

Travelz tourism becomes super popular! And other travel portals want to partner with Travelz! Now the team has to extend their tech to

  • Allow secure access to internal services to external partners and clients as APIs

  • APIs should be easy to find, understand, integrate with and adopt

So, Travelz introduces an API Management to manage access by the external partners. They adopts a Contract First approach by creating OpenAPI specifications for their existing and new services before onboarding external clients

Travelz build a new version of their Travels service (v2) for partners. So, the Partners will access v2 and while the internal platforms access v1. The intelligent traffic routing capabilities of Service make this extremely easy to do this.

architecture step3

3.3. Scenario 3 - Engaging with Partners: Securing API access - North South or External traffic

  • Travelz IT now manages Partner Access to their APIs in such a way that the partners can only access APIs which are protected by a user_key.

  • The developer portal provides the right platform for partner developers to discover, learn, test and sign up for those services.

3.4. Scenario 4 - Managing and Securing both External & Internal access - Inter Domain Traffic

Travelz IT goes one step further to standardize access of their core Agency Services for both Internal platforms as well External partners.

This is made easy with the use of WebAssembly. WebAssembly (sometimes called Wasm) is a binary instruction format for stack-based virtual machines (VMs). This plugin is deployed as a sidecar to the microservices and it communicates directly with the 3scale API Manager, making it easy to secure and manage the existing services without making any changes to them.

Click here to learn more about the Wasm plugin.

Scenario 4

3.5. Conclusion

3scale API Management and OpenShift Service Mesh deliver the right capabilities for the right traffic at the right time - for both internal and external clients. It allows

  • standardise and secure connectivity with no changes to existing services.

  • Easy onboarding of partners

  • Monitoring, observability

  • All the components are integrated to work well together without having to integrate them by yourself

  • The entire setup can be managed via gitops enabling easy setup across the various envirounment from dev to production