Technological progress never stops, and the goal of any enterprise architecture is to build harmony between multiple technologies. Merge them together, take the best of each, and use those technologies to become more efficient in your particular business area. Also, the intent is to simplify: Make different stacks work for you instead of spending all your time managing different pillars of your infrastructure.

AWS ECS Anywhere (ECS-A) is one of those cases where customers get the best of all worlds: a cloud-hosted and managed stack– extended to your on-premise data center– and running tasks inside of Docker containers on the hardware hosted in your datacenter.

In a very detailed video, Massimo Re Ferre demonstrates the step-by-step process of an ECS Anywhere roll-outl. Following this video will surely give you a great start with ECS-A deployment in your datacenter. (Spoiler: With ECS-A you can use “my on-prem datacenter” with any compute instance that is outside of AWS Cloud. In his video, Massimo uses Raspberry PI devices).

TSB provides the missing pieces of the puzzle:

• Steering traffic to your ECS-A tasks (what traffic, on what conditions, etc)
• Managing authentication, authorization, and encryption in transit between ECS-A workloads and between ECS-A workloads and end-users or other non-ECS-A workloads
• Integrating the tasks with any of your workloads running outside of ECS-A, (e.g. Kubernetes or VMs)
• A management plane that provides centralized management, global policy enforcement, multitenancy, workflows and process integration, global service inventory, and configuration safeguards 
• Observability of traffic flow– including metrics, distributed tracing, and logging, via a powerful graphical interface

What is Tetrate Service Bridge (TSB)?

Created by Istio founders, Tetrate Service Bridge is the only edge-to-workload application connectivity platform that provides enterprises with a consistent, unified way to connect and secure services across an entire mesh-managed environment.

TSB sits at the application edge, at cluster ingress, and between workloads in your Kubernetes and traditional compute clusters. Edge and ingress gateways route and load balance application traffic across clusters and clouds while the mesh controls connectivity between services. A single management plane configures connectivity, security, and observability for your entire application network.

Let’s have a look at an example deployment of workloads running in EKS as well as ECS and ECS-Anywhere, and then cover some of the technical details:

To summarize what’s happening here:

• ECS Tasks (that are in essence Docker containers) are deployed in the cloud
• An AWS customer deploys tasks to ECS-A – which are Docker containers running on the on-prem servers, an AWS agent (running as Docker container) deploys tasks (that also run as docker containers)
• Tetrate Service Bridge (TSB) deploys an Envoy proxy (as a Docker container) on every running on-prem service managed by ECS-A
• TSB configures the Envoy proxies to provide routing and secure connections between ECS-A tasks as well as between ECS-A tasks and workloads running in the cloud. (In this case, tasks are running in the ECS cloud and workloads in EKS).
• TSB provides service discovery for ECS-A tasks and they are now are part of the mesh. All mesh capabilities such as traffic steering, resiliency, security, and monitoring can be applied to tasks the same way these rules are applied to workloads outside of ECS-A
• Additional scenarios that come out of the box:
  • Task1 (running on VM1) can call Task2 on the same box. Everything will be happening inside of the mesh – monitored, secured, and controlled by TSB
  • Task1 (running on VM1) can call Task2 running on VM2. Everything will be happening inside of the mesh – monitored, secured, and controlled by TSB
  • An application running on VM that belongs to the mesh (via Envoy proxy) can call ECS-A Tasks and everything will be happening inside of the mesh – monitored, secured, and controlled by TSB
  • A user outside of the mesh can call ECS-A task and as soon as the user’s call enters the mesh, TSB provides all benefits of controlling and monitoring traffic
  • Kubernetes service (from EKS or standalone) can call ECS-A task and again, everything will be happening inside of the mesh – monitored, secured, and controlled by TSB

A few details on the technical implementation and if you want to try it yourself:

• Follow ECS-A documentation steps and onboard on-prem service to ECS-A, then deploy a task
• By now you should have Docker running on your server with amazon-ecs-agent and your task containers
• For TSB the following tasks are required to add ECS-A instances to TSB:
  • Create a WorkloadEntry describing the server, ServiceEntry instructing other Kubernetes workloads that ECS-A task is reachable 
  • tctl utility (TSB CLI) will read WorkloadEntry, create a bundle with configuration files and required certificates, connects to ESC-A instance adds Envoy-proxy container with the required configuration, and connects the instance to the mesh

Now docker ps will return something like this:

When traffic is sent to this task it will follow all the rules described in TSB. Below is an example of how the task is presented in the TSB dashboard:

• The call is initiated by a workload in EKS
• Metrics on the link between EKS and ECS-A instance is measured
• On the right side of the screen metrics that are associated with the task are shown
• Also, the lock icon demonstrates that the traffic between EKS and ECS is encrypted

In summary, ECS-A and TSB provide a very complete solution that allows to deploy, manage, and monitor ECS Tasks running in an AWS customer datacenter.