Explore AppMesh - the convergence of Service Mesh, API Management and Integration technologies that solves real business problems.
We are witnessing a rapid adoption of microservices at a very large scale. Technologies that enable microservices development, operation, and management have also been evolving at a rapid pace. Though technologies such as containerization, DevOps and Service Mesh have simplified the adoption of microservices to a great extent, there is always a next phase of evolution. This is the phase where we will witness the convergence of Service Mesh, API Management and Integration technologies to solve real business problems!
Traditionally in a monolithic Application, all the components of the application are tightly coupled and generally built to be deployed as a single unit. Though on one hand, it reduces overall complexity and operational difficulties, it is also less flexible and less agile. Any fix or change to a small module within a monolith application would then require a full new build and deployment of the entire application, thereby increasing the time to value.
Microservices architecture reduces this overhead enabling application developers to build applications as loosely coupled and tightly integrated services, which facilitates easy maintenance, faster delivery of application changes and notably, removes technology restrictions across different services development teams. In a typical Microservices architecture, a monolith application is split into a set of independent microservices either based on architectural decisions or business requirements. These microservices would then have to be tightly integrated to realize the same business function that you get from a monolithic application. Generally, the onus is on the service developer to orchestrate these services by discovering the service(s) that his/her service should interact with, enable secure connections for, code error handling and fault tolerance logic for, and so on.
What is wrong with Microservices?
Though the microservices architecture provides agility and more flexibility, it also introduces higher operational complexity and cost on the part of the application developers and operations team. As the number of microservices in your application increases, the operational complexity also increases proportionally. Consider a farm of hundreds or even thousands of microservices, which is not that uncommon these days, and then as an application developer to be faced with (at a minimum) the following problems beyond what is needed for your business logic:
- How are these services going to find each other?
- How are these services going to securely connect to each other?
- How are these services going to detect failures and do a retry?
- How does the application log, monitor, and trace the service calls?
Service developers can still code this logic in each of these services, but, considering the volume of services that one has to look at, they would have less time to spend on developing the core business logic.
These are the problems that “service mesh” intends to solve. Service Mesh and its components does the required heavy lifting, relieving application developers from focusing on the network level challenges mentioned above, and by providing them with the critical time needed for solving real business problems. With the proliferation of microservices, containerization and DevOps, service mesh will become the de-facto way for managing a microservices landscape.
A typical service mesh platform, at a minimum, provides the following core set of functions:
- Service discovery
- Fault tolerance
- Connectivity across different protocols
- Security and other network level enforcements through side car proxies
Side car proxies that reside in very close proximity to the microservices that do all the heavy lifting. These side car proxies, which reside in “data plane” are configured and managed through a set of components in the “control plane”.
Service Mesh is great, but
Though service mesh platforms are valuable for managing a complex landscape of microservices, they solve only half of the problem, which in my opinion, are the technical challenges (Layer 4) but fall short when it comes to the application (Layer 7), context awareness. When you look closely, the side car proxies or any of the service mesh components, they are not aware of the microservice it proxies and protects. For these proxies, the microservices are a black box. Now, what if an application developer would want to do some “application level” enforcements on the requests before they reach the microservices, or would want to use the microservices to drive application integration? These microservices cannot work in isolation, they need to be integrated to realize business value. The problems don’t end here. Without the knowledge about the service interface and the functions they provide, how does an application developer prepare his/her microservices for adoption, reuse, and consumption?
These are application level problems that the current service mesh platform does not solve and these problems must be solved if microservices are to provide real business value. If we are able to bridge this gap between the technical and the business world by leveraging all the great benefits that service mesh brings to microservices management, and complement them with application awareness, then we are looking at the next logical evolution of service mesh which is “AppMesh”
So, what is AppMesh and what does it do?
AppMesh symbolizes the convergence of Service Mesh, API Management and Integration technologies. AppMesh extends the service mesh platform by providing application awareness through “APIfication” of the microservices. “APIfication” really means providing an API face to these microservices. With this, you can enable reuse, governance, consumption, landscape management & importantly drives API led integration of these microservices.
API Gateways play a critical role in bringing the API context to the service mesh landscape. With the right level of integration & co-existence with the service mesh components, the API Gateways can provide a real “gateway” for the application/service developers, integration developers and API product managers to work with the services in the mesh.
API Gateways can help application developers to lookup the services in a mesh and enrich the basic connectivity information with enhanced API metadata and standard definitions such as OpenAPI – thereby providing an API face to the microservices. With the API twin at their disposal, the service developers can leverage a large pool of the API policies to provide application level enforcements to the service car proxies.
Integration developers use this API twin to drive their API led integration story. It is important to note that integration of microservices is key. These microservices cannot work in isolation, they need to be integrated to realize business value!
API twin also enables API product managers to prepare these services for consumption and expose them securely to the application developers either within or outside the organization.
Software AG & Service Mesh
With robust API management, integration and microservices technologies, Software AG is well-positioned to offer a strong, platform agnostic AppMesh which intends to work well with different service mesh providers.
For instance, service developers can use webMethods API Gateway to connect to a mesh, create an API twin, enrich service definition, apply API policies, package/deploy the API twin into a micro gateway and deploy this as a sidecar which can work perfectly well with the existing service mesh components in both data plane and control plane. Integration developers can kickstart their API led integration story by publishing their API definition from the API Gateway to our integration platform, build and package the integrations into a microservices runtime, which can then be deployed back to the mesh by leveraging our DevOps tool chain and CI/CD support. If needed, an API twin can be created for these integrations which can again be exposed as an API to the external/internal application developers.
With the ever-increasing adoption of microservices and more importantly at a very large scale, service mesh will become the de-facto way for handling large scale microservices deployments. Apart from the capabilities offered by service mesh platforms, businesses will expect the API management and Integration vendors to complement and strengthen their microservices deployments by improving the control, security, observability, and governance and API led integration through application context to solve real business problems. This expectation will lead to the convergence of the Service Mesh, API and Integration technologies to deliver true business value!