Today, we are excited to announce the general availability of Tetrate’s Brooklyn release. This marks a major evolution of Tetrate Service Bridge (TSB), a service mesh powered application connectivity platform that enables global enterprises to modernize applications, migrate one or more clouds, achieve zero-trust security, and automate infrastructure resilience. New TSB capabilities will make deploying Istio and Envoy at scale even easier for platform teams, enforcing global policies effortless for security teams, and troubleshooting service mesh workloads self-service for application teams. We’ve also productized best practices and lessons learned from delivering production service mesh for global financial services and federal institutions, so every security-focused organization can benefit from a service mesh without the overhead. In this blog, I will introduce these new TSB capabilities as well as recap relevant recent innovations in Tetrate Istio Distro (TID) and our contributions to open source projects. 

If you are already familiar with TSB and want to dive into the technical details, jump straight into the release notes. 

If you are new to Tetrate, read on for a comprehensive introduction, and register for the demo webinar to get a closer look.

Teams Prioritizing Time to Value and Efficiency

According to Tetrate’s 2022 State of the Service Mesh Market survey, there’s growing urgency for organizations to deploy service mesh with scale and security. In our close collaboration with Fortune 500 enterprises across industries and federal institutions, we also see three core principles remain unchanged:

1. Open source and standard-based: Unwavering support for open standards and open source software, with growing adoption of Istio as the control plane, Envoy as the data plane, Kubernetes Gateway API as the standard for ingress, and BoringCrypto for FIPS 140-2 approved cryptographic algorithm.
2. Zero trust security as a team sport: As zero trust architecture continues to gather interest and momentum, platform, security, and application teams are all more entwined in “shift left” DevSecOps practices.
3. Mixed cloud environments becoming the norm: Most organizations are migrating to at least one or more public clouds, but many still have an on-prem footprint. Likewise, most have adopted Kubernetes and cloud-based services, but many essential services are still running on VMs.

At the same time, we are noticing a change in how these teams are approaching service mesh adoption, with new emphasis on four themes:

1. Time to value: Prove service mesh value sooner with faster deployment of infrastructure and faster onboarding of service owners and their workloads.
2. Efficiency at scale: Apply automation and self-service to take on more complex multi-cloud, multi-environment operations and troubleshooting without growing headcount.
3. Multi-layered zero trust: Enforce security policies in alignment with org hierarchy (e.g., top-down mandates from security or platform teams) while providing flexibility (e.g., exceptions for unique application team use cases).
4. Dynamic resilience: Extend high availability across clusters, regions, and clouds without manual intervention.

Tetrate’s Brooklyn release helps platform and application teams uphold core principles while capturing service mesh’s business value much easier and faster.

New Capabilities in Tetrate’s Brooklyn Release

The Brooklyn release hardens the service mesh for production-grade enterprise needs under diverse workloads, across heterogeneous environments, supporting multiple teams in achieving their goals without compromising security or efficiency. 

To make these new capabilities easier to understand for people not familiar with Tetrate, we will introduce these new features along four thematic benefits:

• Accelerate mesh deployment across environments.
• Streamline collaborative troubleshooting between platform and application teams.
• Automate security policy enforcement.
• Automate high availability across clusters, regions, and clouds.

All features are for Tetrate Service Bridge, unless otherwise noted.

Accelerate Mesh Deployment Across Environments

When it comes to the speed and efficiency of running a service mesh, the most fundamental need is also the most common pain point. Most enterprises operate multiple cloud platforms—EKS, AKS, OpenShift—with multiple Kubernetes or Istio versions as teams follow disparate upgrade cycles. Being able to manage this complex footprint becomes problematic over time. The overhead of tracking compatibility between different Istio and Kubernetes versions becomes too burdensome, and upgrading Istio becomes too complicated in itself. Teams have to take on the burden of upgrading Istio versions and often need to deploy different Istio versions on the same Kubernetes cluster. Not being able to deploy multiple Istio versions often leads to teams falling behind on upgrades and missing critical vulnerability patches and new features.

Introducing Multiple Istio Instances and Isolation Boundaries on Tetrate Service Bridge

In this release, we are making it easier to upgrade Istio by running multiple Istio versions on the same Kubernetes cluster, so you can do canary upgrades to newer Istio versions by migrating production workloads gradually, without disrupting your existing operations. Typically, managing multiple Istio versions and ensuring proper segmentation between them creates an overwhelming amount of operational overhead. With TSB, you can easily deploy new Istio revisions with Helm, and TSB will ensure segmentation between Istio instances. You can also define configurations to specific Istio revisions and TSB will automatically deploy them to the right instance accordingly. Read more about how to deploy multiple Istio instances and Istio isolation boundaries in docs.

Enhancements For Red Hat OpenShift and Amazon EKS

We are also enhancing our compatibility and support across platforms, including Red Hat OpenShift, where we are now a certified partner. Our commitment to simplifying service mesh across clouds doesn’t just end at TSB. Our hardened, performant, and fully upstream Istio distribution, Tetrate Istio Distro, is now deployable on Amazon EKS with a single command via EKS add-ons.

Streamline Collaborative Troubleshooting

The distributed nature of microservices makes observing services within an application very difficult. These services can exist on different clouds, clusters, or even VMs with many potential failure or performance-limiting scenarios. Does the problem lie with the app, the sidecar, the network, an external dependency such as a database, or the configuration? To further complicate troubleshooting, typically there are multiple application teams sharing the service mesh, and they cannot easily obtain diagnostic information because they don’t have administrative access to the production environment. The platform team owning the service mesh simply cannot keep up with the demands for logs, tracing, and other forms of telemetry without more advanced troubleshooting tools.

Introducing New Diagnostic Visualizations: Time-Lapse View and Envoy Log Drill Down 

We’ve made many UI improvements across the platform to make troubleshooting and mesh management more efficient, but two new diagnostic visualizations stand out.

First is a time-lapse view of the service mesh topology. This feature allows you to identify trends in the overall service mesh health. You can use this view to identify traffic patterns, performance degradations, or errors at a large scale.

Second is the ability to drill down into service metrics, traces, and streaming logs, including the Envoy sidecar, from the high-level topology view. Once you’ve identified an area of interest, you can directly inspect the logs in detail. Using the time-lapse and drill-down views in tandem, you can quickly get the big picture and hone in on the details to troubleshoot more efficiently.

Introducing Role-Based Observability on Tetrate Service Bridge

We are also introducing a new capability that allows application owners to troubleshoot their services much faster on the service mesh. Platform operators can now support troubleshooting for app owners much more efficiently:

• With a single command, the platform can obtain detailed diagnostics (metrics, events, logs, traces) from a cluster and provide them to app teams
• With a suite of tools, application teams can interrogate the diagnostics to query the cluster state, obtain sidecar metrics, identify slow and failed transactions, and generate full traces
• The platform team can confine application team access without granting excess privileges

With this new capability, platform teams can gather the critical troubleshooting data required by app teams to investigate performance and outage issues much faster. Read more about troubleshooting services in the docs.

Automate Security Policy Enforcement

As you decompose monoliths into microservices, the number of policy enforcement points explodes. This is especially true if you adopt a service mesh pattern with sidecars and gateways at the edge, ingress, and across clouds. The traditional approach of security policy enforcement calls for security teams, platform teams, and app teams to manually configure legacy networking software (e.g., API gateways), but that’s no longer possible for two reasons:

• These legacy network solutions have no awareness of the underlying microservices architecture, so the platform, security, and app teams have to manually track what policies should be applied and the dependencies between the policies.
• The underlying services are too dynamic—one service could be replaced by another in a different cluster, or a new service could be added to alleviate the load. These should happen automatically because manual configuration is no longer possible.

Every security-focused organization adopting a microservices architecture needs an automated management plane to define, distribute, and enforce policies to achieve zero trust. 

Introducing Hierarchical Policies and Security Domains on Tetrate Service Bridge

In this release, we’ve made it possible to automate security policy enforcement, and it has two major components:

• We’ve created the ability to define policy hierarchies so that a security or platform team can mandate how security policies should be propagated throughout the service mesh deployment—whether enforcement is mandatory, or are exceptions allowed. This means it’s now possible to guarantee that zero-trust principles such as mTLS are enforced across the board. Define once, enforce everywhere, vastly reducing the complexity and overhead of achieving zero trust. Read more about security hierarchies in docs.
• To maximize flexibility, we’ve also introduced the concept of security domains. It is a way to customize how policies should be applied across hierarchy boundaries, think of a security domain as a logical grouping or an alias that exists alongside the policy hierarchy to safely create exceptions. Security domains provide necessary flexibility for matrixed organizations where a single top-down policy hierarchy definition is insufficient. Read more about how to create Security Domains in docs.

Hierarchical policies and security domains work in tandem to ensure security, maximize flexibility in how organizations want to define, and enforce security automatically. They also seamlessly fit within TSB’s role-based access control framework, so the platform team can also explicitly control the level of autonomy of app teams on the mesh.

Introducing WebAssembly (Wasm) Extensions and Web Application Firewall (WAF) Preview on Tetrate Service Bridge

In this release, we are also laying the groundwork to enable platform teams to offer reusable extensions to app teams. Often app teams have security, auditing, or logging requirements that are expensive to build into services. Wasm is an easy way to attach these kinds of functionalities transparently to services with no application changes through the Envoy sidecar, and Tetrate has a great deal of Wasm expertise through our contribution to the Wazero project. 

To help platform teams get value faster, we are building the ability to use pre-packaged Wasm extensions. In the coming releases, we’ll build up a library of ready-to-go extensions in addition to offering the ability to create your own extensions. Read more about using Wasm extensions in the docs. As an example of running powerful Wasm extensions on TSB, we’ve included a technical preview of WAF capabilities—based on the fast-evolving Coraza project—in the Brooklyn release. Utilizing Wasm and WAF provides flexibility for enterprises to address zero-day exploits with speed. Read more about using WAF in the docs.

Automate Cross-Cluster High Availability

The promise of microservices is resilience at scale—when a service goes down, it should failover to a backup, and the same thing should happen even when entire regions or even cloud service providers have outages to minimize disruption to your business. However, achieving that promise is not possible without automation and, in many cases, without application code changes because microservices have too many distributed services, and the topology is often too dynamic. Every service mesh needs a management plane that takes high-level intent and automatically configures the underlying infrastructure to provide failover.

Introducing HA Workspaces on Tetrate Service Bridge

Along the lines of efficiency, we’ve made it dead-simple to achieve high-availability, or HA, across clusters. We’ve enhanced workspaces—which is simply a logical grouping of services that allows platform operators to configure once and deploy anywhere—so that you can designate a workspace as “high availability”, and make a service HA by adding it to an HA workspace. Read more about configuring automatic failover in docs.

Learn More, Get Started

This concludes the overview of the Brooklyn release. Want to learn more? There are a lot more details in the release notes you can dive into. You can also sign up for a spot in our upcoming webinar to see the new capabilities in action. 

If you are a developer inspired to try Istio for the first time, check out Tetrate Istio Distro—you can deploy it anywhere, but it’s especially easy to get started on Amazon EKS.

If you are a platform operator who wants to evaluate service mesh platforms to modernize your application infrastructure, get in touch with one of our expert solution architects.