Skip to main content
logoTetrate Service BridgeVersion: next

Good Practices for Onboarding Applications

This guide describes basic recommendations to prepare a Tetrate-managed platform for onboarding applications. It applies to both Tetrate Service Express (TSE) and Tetrate Service Bridge (TSB)

For simplicity, this document just considers services deployed on Kubernetes clusters.

User Types​

This document assumes the following two user types:

  • A Platform Owner user has direct access to TSE or TSB, and wishes to pre-configure the platform to receive and host services. The Platform Owner needs to define appropriate defaults and guardrails, and needs to prepare additional services such as DNS or Dashboards.

  • An Application Owner ("App Owner") user does not have access to TSE or TSB, but has access to one or more namespaces in the Kubernetes clusters. Each App Owner wishes to deploy production services to the clusters using standard K8s APIs and tooling, such as a CD pipeline.

TSB User and Role Hierarchy

TSB provides a very rich user and role hierarchy which enables the platform owner to delegate limited TSB functionality to other user types, including multiple App Owner users and teams. This document does not cater for these more complex scenarios.

Rather, this document caters for the simpler "One Platform Owner team, Multiple App Owners, High-Trust" scenario that is supported by both TSE and TSB. It assumes that you will use Kubernetes RBAC or similar to control how App Owners can access Kubernetes namespaces. The document uses Tetrate's 'GitOps' Integration to grant App Owners access to some Tetrate-specific functionality, such as deploying Ingress Gateways. GitOps is enabled by default in TSE, and can be enabled and configured in TSB.

Scenarios​

This document will cover the following scenarios:

  1. Prepare the Clusters​

    The Platform Owner will create namespaces for each App Owner team, and corresponding Tetrate Workspaces. They will configure a Zero-Trust base environment that only permits in-workspace communications. They will deploy Ingress Gateways in namespaces that need to receive external traffic.

  2. Deploy Services and Configure Gateway Rules​

    The App Owner will deploy services within their namespaces and, where necessary, configure an IngressGateway rule to allow external traffic.

  3. Monitor Tetrate Metrics​

    The Platform Owner will configure integration with a third-party metrics system so that the App Owner can observe Tetrate metrics from their applications. Alternatively, the Platform Owner can grant access to the Tetrate Management Plane so that App Owners can access metrics directly.

  4. Extend Security Rules​

    The Platform Owner can 'open up' the Zero Trust environment to allow limited security exceptions. This allows services owned by the App Owners to consume services located in other namespaces and locations.

  5. Manage Traffic between Clusters​

    The Platform Owner can pre-configure exposure and failover measures that will expose origin services in remote clusters, and arrange for local-to-remote failover for redundant service instances.

  6. Achieve High Availability across Clusters​

    The Platform Owner can pre-configure high availability measures that will perform failover from a service instance in one cluster to an instance in another cluster. The App Owner can deploy multiple redundant instances.

  7. Configure Additional Security Measures for a Service​

    The Application Owner can configure Rate Limits, Authentication and Access Control for the services that are accessible through an Ingress Gateway.

Advanced Topics​