Ambassador - Developer and DevOps Experience

29.09.2021•Tom Trapp
Cloud Redis Spring Framework Distributed Systems Kubernetes DevOps Framework Hands-on

Developer and DevOps Experience is key with Ambassador!

What is Ambassador?

Ambassador describes himself as ‘Developer-First Kubernetes’. The focus here is on building cloud native applications / microservices from the developer’s point of view.

The company Ambassador Labs (previously Datawire) was founded in 2014 and is strongly focused on DevOps for Kubernetes. The globally active company with its headquarters in Boston offers both open source and commercial products.

What are the components of Ambassador?

DCP - Developer Control Plane

The idea behind this developer-focused control plane is that developers today are responsible for much more than their own code. So far you had your local application, which you developed and tested with a few languages. The whole build & deployment process works somehow and you don’t have to worry about anything else.

As soon as the word DevOps comes into play, everything changes abruptly. As a developer, you are suddenly technically responsible for the entire application, including CI/CD, certificate management, operation, provisioning and so on, and you have to deal with far more tools and languages than before.

The full-stack developer becomes a full-lifecycle developer because he is responsible for testing, Q/A, building & deploying, running, monitoring, etc. in addition to the actual development. This Full Lifecycle or Full Cycle Developer terminology originally comes from Netflix and identifies a new breed of developer.

With the DCP, Ambassador wants to offer a dashboard that supports the full lifecycle developer in these new tasks and is specially tailored to this application.

Figure: Source: 08/31/2021: https://blog.getambassador.io/introducing-the-ambassador-developer-control-plane-339c97fa4716

Basically, there are three major building blocks:

DCP code

This is about the actual development work and the different environments. The developer can configure different environments via the DCP as well as view and explore APIs that are available for development.

Classic tools in this sector are the IDE, Source Control and Continuous Integration Systems (CI). Ambassador’s product in this sector is called Telepresence.

DCP - Ship

This involves publishing updates including Zero Downtime Deployments and Canary Releasing. A canary release describes the concept of a ‘slow’ rollout of a new version. As with a blue / green deployment, the new version is fully deployed, but with a canary release only a few users are directed to the new release. Popular selection criteria of the users in addition to the random principle are e.g. certain user groups. Internal employees are often given access to a new release version before it is released to the outside world. This has the great advantage that a release can first be tested extensively and approved step by step.

It can quickly happen that several versions of an application are published and in use. The important thing here is that this practice is usually not just limited to the application or web server and there is often also a parallel or dedicated database for a new release.

In addition, the DCP enables constant monitoring of the currently published versions and their distribution in the canary release.

Classic tools in this sector are the container management tools, Kubernetes Manifest Templates and Continuous Deployment Systems (CD).

Ambassador does not reinvent the wheel here, but uses proven tools such as ArgoCD.

DCP - Run

This involves monitoring and ensuring 24x7 operation of the application. These parts of the control plane should enable errors or anomalies to be identified and analyzed.

Classic tools in this sector are the API gateways and observability / monitoring systems.

A well-known technology is also used here. The Enovy Proxy also acts as a sidecar container in this setup.

Telepresence

Telepresence allows parts of a complex Kubernetes application to run locally.

Cloud native applications can quickly become too large and complex to launch locally with all moving parts and dependencies. With telepresence, a smart proxy is used to forward traffic from a specific service (microservice) to the local development environment. In this way, your own computer or laptop is integrated into the Kubernetes cluster.

The entire application is then called via a certain preview URL, which activates the routing of the target service to the local machine. From a technical point of view, a header is attached to the request when this preview URL is called. Based on this header, the Telepresence Proxy then decides whether the traffic should be routed to the real service or to the locally running service.

Telepresence was recently released in version 2.0, which is no longer written in Python but in Go Lang. In addition, version 2 was specially developed for use in corporate networks, for example in combination with VPNs.

Specifically, there are two modes that decide how the traffic is forwarded. In the default mode, all traffic is routed directly to the local machine; the running application is thus completely influenced. In collaboration mode, it is possible to direct only certain users to the local running instance of a microservice via a preview URL. The application itself remains unaffected and can continue to be used normally.

The great advantage of this concept is the time saving. With short tests in the cluster, the complete CI / CD process does not always have to be run through, but it is possible to guide only certain users to the local instance. This gives you much faster feedback and makes it much easier to exchange ideas during pair programming. In a heterogeneous system, it is often difficult to reproduce a bug locally. Telepresence can also help here by simply debugging the local instance and then making the necessary fix directly in the cluster.

The architecture of Telepresence is described in the figure below. A so-called Traffic Manager is used to control where certain traffic is routed. As a sidecar proxy container, the traffic agent ensures that all containers can be addressed.

Figure: Source: 08/31/2021: https://www.getambassador.io/docs/telepresence/latest/reference/architecture/

Telepresence must be installed and configured locally and in the cluster. Forwarding can then be started from the local computer with a valid kubeconfig. We will take a closer look at this topic in another TechUp.

Edge Stack

Ambassador Edge Stack describes the complete process of a request from the customer to the application.

This process consists of different components such as B. the Ambassador Kubernetes API Gateway.

The following API Gateway functionalities are supported:

  • Authentication
  • Rate Limiting
  • Access Control

However, the Edge Stack consists of many more components, such as a Kubernetes Ingress Controller, which is responsible for traffic management.

Out-of-the-box, Ambassador also delivers service mesh provider integration for service discovery, end-to-end TLS, and observability. These can be used with well-known service mesh providers such as Istio or LinkerD.

‘Under the hood’ the Edge Stack runs the Envoy Proxy already known from other TechUps (Istio).

Another component of the edge stack are the delivery accelerators. This is a summary of different CI/CD features to be able to quickly and easily deploy microservices directly from GitHub. The open source project Kaniko from Google is used here to be able to quickly build and deploy GitHub code in so-called micro CD pipelines.

The Edge Stack offers, at least at first glance, many components that are useful or necessary in a productive real world case.

Emissary Ingress

Emissary-Ingress is an open source Kubernetes-native API Gateway, Layer 7 Load Balancer, and Kubernetes Ingress (built on Envoy Proxy). This product was formerly known as the Ambassador API Gateway and can now be found in the CNCF landscape as an incubating tool. As an enterprise product, the actual edge stack is completely based on the open source emissary ingress.

Pricing

Ambassador has a very sophisticated pricing model, there are basically three packages:

  • Open source

    • Parts of the Ambassador range are open source such as e.g. Traffic management with Edge Stack
    • The developer portal is not available in the open source version
    • Telepresence only offers the possibility to exchange the service completely and not just guide certain users to the local instance
    • These products are 100% open source and can be used individually or together

  • Free

    • Contains all functionalities for up to 5 services
    • The security features in the edge stack are limited to up to 5 requests per second

  • Standard or Enterprise

    • More than 5 services or 5 requests per second
    • Extensive support

Conclusion

In conclusion, one can say that the whole Ambassador construct sounds very promising in theory, but is fundamentally very opaque. It’s hard to see what is open source and what is paid. Nonetheless, we want to try Ambassador Hands On and see what it can do, what makes it good or passable.

Stay tuned!

This text was automatically translated with our golang markdown translator.

Tom Trapp

Tom Trapp – Problemlöser, Innovator, Sportler. Am liebsten feilt Tom den ganzen Tag an der moderner Software und legt viel Wert auf objektiv sauberen, leanen Code.