Technical resources
Tetrate Enterprise Service Mesh is now on OpenShift
Tetrate is now a Red Hat OpenShift certified technology partner. This gives OpenShift users bleeding edge service mesh capabilities with Tetrate Service Bridge (TSB). TSB provides security, observability, resiliency, and failover across multi-cluster, VM, bare-metal, cloud native, and hybrid environments all from a centralized location. Checkout Tetrate's announcement on OpenShift here.
A service mesh gives the user additional controls over their application, infrastructure, and networking within their cluster(s); it also has the capability to instantly improve security posture through policy enforcement. Ultimately, however, a user can do only so much on a single cluster.
In the real world, things never go as planned
Even the major cloud providers have entire regions go down. This was likely at the forefront of the minds of a group of Istio founders when they created TSB.
TSB is an edge-to-workload application connectivity platform that provides a consistent and unified way to connect and secure services across entire Istio meshes. In layman’s terms, TSB connects and controls service meshes, giving services the ability to failover into other regions, clouds, and availability zones ensuring maximum uptime, reliability, and stability for services.
Combining TSB with OpenShift Container Platform (OCP), built for the hybrid cloud, allows you to run workloads virtually anywhere and abstract away cloud provider details for a completely vendor-agnostic solution. TSB with OCP manages a unified mesh of workloads and services running across a combination of cloud vendors, VMs, and on-premise data centers.
Not just multi-cluster, multi-tenant
TSB gives you the power to create tenants within your business in order to define fine-grained access control and editing rights for teams within shared infrastructure. You can audit the history of changes to services and shared resources from day zero.
Delineation and delegation of responsibilities are clear through the TSB multi-tenancy model, allowing the creation of completely independent teams to reduce communication cost and improve productivity amongst teams.
For organizations that have mastered decoupled microservices, this is significant. For organizations that harbor a monolith or coupled services, fear not. TSB is powered by Envoy, which minces and slices traffic flows like Gordon Ramsey does a fresh Alaskan salmon.
Application modernization
In the fast paced world of software, if you are not continuously improving, you are likely falling behind. For companies undergoing modernization, TSB is a valuable asset.
TSB is powered by a fleet of Envoy proxies, running as gateways, and sidecars which provide visibility, security, identity and routing capabilities across the mesh. You can easily route across multiple versions during testing to allow only a subset of users to see a particular feature, without disturbing your user base, or you may slice parts of the monolith and reroute traffic to newly minted microservices.
Security and zero trust
TSB extends policy enforcement across your entire application fleet. Not only does it dictate who can talk to who, but also the manner in which they speak. TSB does this by controlling the request path and having the ability to add requirements to the request and to drop requests that do not comply. It is a policy-driven orchestration tool where security is a first class citizen.
TSB offers auditability, secure multi-tenancy, end-to-end Mutual Transport Layer Security (mTLS), and the blueprint to implement Zero Trust in multi-cluster service mesh environments.
Security as a first class citizen in TSB allows organizations to maintain agility while keeping a strict security posture and avoiding potential pitfalls by addressing potential risks with policy.
Command line tooling
Tetrate Service Bridge comes with a sleek CLI called tctl which lets you interact with the TSB API, allowing for easy manipulation of objects and configurations in a programmatic and interactive way. The CLI works by submitting YAML representations of TSB or Istio Objects to the TSB Management Plane.
That being said, TSB does not have to be configured imperatively. In fact, TSB complies with industry best practices and can be configured in a completely declarative GitOps fashion.
Architecture
Before diving into the architecture, let's go over a common TSB workflow. The management plane and global control plane sit together in one cluster. Next, remote clusters are added, each containing a remote control plane and data plane. You can put all of these components together in one cluster, but that is not the recommended approach. The management plane should be responsible for the orchestration of all remote meshes and should not be constrained by resources. Likewise, the remote meshes should be focused on running workloads and not be resource constrained.
TSB architecture can be broken down into several planes:
- Management Plane: the primary access point to everything within your environment. This is where you configure networking, security policy, observability, and tenancy. These configurations are propagated throughout the mesh.
- Global Control Plane: a part of the management plane, but is not directly controlled by the user. The user configures the management plane and the global control plane compares the configuration with the global state of the meshes as a whole.
- Remote Control Planes: the istio system namespaces that are controlled by TSB. TSB is responsible for creating VirtualServices, DestinationRules, Gateways, ServiceEntries, AuthorizationPolicy, PeerAuthentication, etc.
- Data Planes: the powerful envoy proxies, fully equipped to handle hundreds of thousands of requests per second. The data planesenable data transfer between services through sidecars that sit beside applications sending and receiving data on their behalf.
A bridge to reliability and resilience
Engineers should stick to their strengths, and if they are developers, then they should not be burdened by the responsibility of managing the mesh. Multi-cluster service mesh is hard, and establishing trust through a fleet of service meshes as well as ensuring constant, reliable, and resilient communication takes a lot of effort. This could be time spent developing, which, in many cases, is where resources should be allocated to drive profit.
TSB allows serious dev shops and applications to grow in a way that is organic to Istio and does the heavy lifting behind the scenes. If this problem sounds familiar, then I highly encourage you to try out TSB.
It is developer friendly, Envoy-powered, created by a team of service mesh experts, and complementary to OpenShift. OpenShift contains hardened, certified versions of several external services that are leveraged by TSB, like Redis, Cert Manager, Elasticsearch, and Postgres. This gives users the promise of reliability that is fundamental to OpenShift with the bleeding edge functionality of TSB, the ultimate combination. To learn more, go here,
