Businesses are adopting microservices for agility and scalability. In managing the complexity of distributed microservices environments, the microservices-based architecture might run into operational challenges, such as service discovery, connectivity, security, and fault tolerance. This is where a service mesh helps in providing critical capabilities that provide a solution for the operational challenges you face. For example, the collaboration of services within a microservice architecture requires the exchange of requests. In case a service is overloaded by requests, the service mesh reroutes the requests to address the overload situation for optimizing the services to work together.

As an application develops, new services are added; this complicates the communication network, increases chances of failure, and adds to the complexity of finding where the problem occurred. A service mesh makes handling the complex network easier as it captures the service-to-service communication details. In a service mesh, the requests between the microservices are routed through the proxies in its own infrastructure layer.

The figure below depicts the microservice environment on the left and the microservice with the service mesh infrastructure on the right. The microservices have individual proxies deployed alongside each service, in a separate container. The service-to-service communication is routed through these proxies.

Since the service mesh is built into the application, it helps in fast and easy communication amongst the services with less downtime as the application grows in size.

Though the service mesh helps in managing a complex landscape of microservices, there is a limitation when it comes to application awareness. It is difficult to achieve application-level enforcement on the requests before they reach the microservices. webMethods AppMesh provides the required solution of applying an application context to a service mesh or microservice deployments.

webMethods AppMesh extends the service mesh platform by providing application awareness through the APIfy action on the microservices, where it provides an API face to the microservices. This enables the reuse, governance, consumption, landscape management capabilities, and drives the API-led integration of microservices.

The figure below depicts an AppMesh deployment, wherein a business context is added to the service mesh through API Gateway. Each service is APIfied and has a Microgateway injected as a sidecar.

AppMesh allows your organizations to manage microservices-led applications to:

In detail, AppMesh provides several critical functions, which include:

Istio is an open source service mesh platform that provides a way to control how microservices share data with one another and is designed to run in a variety of environments; Kubernetes being one of them. Istio support is added to a service by deploying an Envoy proxy that sits alongside a service and routes requests to and from other proxies.

API Gateway provides the capability to discover services in a Kubernetes-based Istio deployment. It allows to APIfy a service, and deploy it back to the Kubernetes environment. After deploying the services back into the Kubernetes environment, you can provision the APIs and service updates from the API Gateway user interface, through the Microgateway injected as a sidecar for the service in the Kubernetes pod.

The APIs that AppMesh creates as a result of the APIfy action are directly linked to and are hosted by Microgateway, and are used to enforce the policies to the service-to-service communication, which is called the East-West traffic.

The figure below depicts the Istio-based AppMesh architecture where the communication between the pods is through the envoy proxy and the Microgateway injected into the pod communicates with the API Gateway.

You can deploy AppMesh in a Kubernetes environment even without a service mesh or Istio deployment. API Gateway provides the capability to discover services, APIfy a service, and deploy it back to the Kubernetes environment. On deploying the AppMesh, the Microgateway is injected as a sidecar for the service in the Kubernetes pods. The Microgateway injected into the pod acts as a proxy for the services for the inter-service communication. You can now provision the APIs and service updates, from the API Gateway user interface, through the Microgateway injected as a sidecar for the service in the Kubernetes pod.

The figure below depicts the Kubernetes-based AppMesh architecture without a service mesh deployment. The Microgateway injected into the pod as a sidecar communicates with API Gateway and any updates to the APIs or policies enforced on the services are provisioned through the Microgateway into the Kubernetes pod.

webMethods AppMesh supports the following platforms:

API Gateway supports Kubernetes versions 1.9 to 1.17.0, and Istio versions 1.5 and 1.6.

The API Gateway license is extended with the AppMesh feature.

You can configure the AppMesh feature license in the Administration > General > License > Configuration section. For details about configuring API Gateway license, see Configuring Licenses.

You can view the AppMesh license details in the Administration > General > License > Details section. For details about viewing license details, see Viewing Licensing Information.

If the API Gateway license does not contain the AppMesh feature support, the following functions are not available in an API Gateway instance: