Software AG Layers App Mesh Over Service Meshes
Software AG this week launched webMethods AppMesh, a configurable control plane based on its application programming interface (API) management platform that is designed to be deployed on top of any service mesh.
Dr. Stefan Sigg, chief product officer for Software AG, says the webMethods AppMesh approach to managing microservices can enable IT teams to more easily apply business rules to drive application-specific behavior; create application-level governance and security policies that are applied at runtime; add more services and capabilities; and make use of more context-aware application routing and orchestration.
Service meshes are emerging as a mechanism for providing a layer of governance and control for microservices that are deployed on top of container orchestration platforms such as Kubernetes. The webMethods AppMesh platform takes that concept to another level by filling a semantic gap between applications and the underlying service mesh, says Sigg.
IT teams can employ webMethods AppMesh can via a dashboard now trace the path a transaction takes through your service mesh. They can also add and remove services in addition to enabling one service to automatically inherit the policies assigned to all other services in an application. The webMethods AppMesh platform also makes an API signature available for every service in the mesh to facilitate reuse across the application environment.
Additionally, limits to service invocations during specific time intervals for identified clients can also be applied, and traffic requests and responses can be analyzed using log data.
In general, microservices make applications more flexible and resilient because they can be managed and updated in isolation from one another. However, microservices can quickly become too much of a good thing as IT teams struggle to manage thousands of them. Sigg says webMethods AppMesh leverages API management technologies to bring a more application-centric approach to microservices, each of which exposes its own set of APIs.
Sigg notes the IT operations teams are now becoming more involved in the management of both APIs and microservices. DevOps teams may have created those APIs and microservices, but it falls to IT operations teams to tune and secure them within enterprise IT organizations, he says.
Decisions concerning how to manage APIs and microservices often come down to the role developers assume within any organization. DevOps purists tend to argue developers should be responsible for every part of their application. However, some enterprise IT organizations have access to only a limited number of developers that they would prefer to see spending most of their time writing new code. The degree to which organizations will want developers to manage microservices will naturally vary by organization. There may be instances when developers employ APIs to programmatically update a microservice while someone on the IT operations team who lacks programming skills uses the webMethods AppMesh dashboard to perform an update.
When it comes to microservices and APIs there is obviously no one right management answer. Most organizations will need to define their set of best practices. The one thing that is clear, however, is that managing even hundreds of microservices will not be feasible without finding some way to apply DevOps principles.
