Tetrate Streamlines Management of Policies
Tetrate is now making it possible to automatically generate Container Network Interface (CNI) network policies from within its implementation of the open source Istio service mesh.
The Tetrate Service Bridge (TSB) is an instance of Istio running on top of Envoy proxy software that has been extended to support both cloud-native applications running on Kubernetes clusters and monolithic applications running on legacy platforms.
David Wang, head of product at Tetrate, said this latest addition to TSB makes it simpler to enforce the same policies implemented at Layer 7 of the network stack at Layer 4 where CNI runs. In addition, TSB will surface a recommendation when conflicting rules have been implemented.
That approach streamlines the effort required to enforce zero-trust IT policies that are often managed in a way that creates a lot of friction within IT organizations, he added.
Most organizations initially adopt a service mesh such as Istio to manage application programming interfaces (APIs) that integrate microservices running across multiple Kubernetes clusters. Most organizations, however, also have legacy monolithic applications that will not be replaced anytime soon. That need to manage services across multiple classes of applications creates a need to extend Istio to centralize the management of APIs.
It’s still early days as far as the adoption of service mesh platforms in production environments is concerned, but management of networking and security services is on the cusp of major change. Instead of waiting for networking and security operations teams to provision services, each development team will be able to self-service their own requirements within a set of guidelines defined by a central IT organization or dedicated platform engineering team. That approach also promises to make it much simpler to integrate the provisioning of networking and cybersecurity services within DevOps workflows at the level of scale that is increasingly required as more applications are deployed.
There is, of course, no shortage of options when it comes to service mesh platforms, and it will undoubtedly take time for the culture within IT organizations to evolve so that provisioning of networking and cybersecurity services is integrated into those workflows. Each organization will need to decide whether to meld networking, cybersecurity and DevOps teams as service meshes become more widely used. The service mesh can be as complicated to manage as the underlying Kubernetes cluster, so many organizations will need to decide whether to manage these platforms themselves or rely on a managed service.
In the meantime, most organizations that deploy cloud-native applications at any scale will, at some point, need a service mesh. APIs are rapidly multiplying beyond what can be managed using proxy software or API gateway. The only issue left to be determined is how that service mesh will be deployed and managed in an era where cloud-native expertise is still often hard to find and retain.
