Ask Sendai

Today, we’re thrilled to announce the beta of Ambassador Developer Portal. The Developer Portal gives your developers a central self-service hub for your APIs. With the Developer Portal, developers are able to onboard and start using your APIs right away. The Developer Portal beta includes the following features: To publish API documentation to the Developer Portal, update your service to pubish a Swagger or OpenAPI specification at .ambassador-internal/openapi-docs/. Then, publish your service to Kubernetes and register the service with an Ambassador Mapping.

An increasing number of organizations are migrating from a datacenter composed of virtual machines (VMs) to a “next-generation” cloud-native platform that is built around container technologies like Docker and Kubernetes. However, due to the inherent complexity of this move, a migration doesn’t happen overnight. Instead, an organisation will typically be running a hybrid multi-infrastructure and multi-platform environment in which applications span both VMs and containers. Beginning a migration at the edge of a system, using functionality provided by a cloud-native API gateway, and working inwards towards the application opens up several strategies to minimize the pain and risk.

Ambassador uses Envoy Proxy as its core L7 routing engine. Envoy Proxy provides a configurable access logging mechanism. Ambassador uses the default format string for Envoy’s access logs. These access logs provide an extensive amount of information that can be used to troubleshoot issues. These provide additional details about the response or connection if any above and beyond the standard response code. Possible values for HTTP and TCP requests include UH (no healthy upstream hosts); UF(upstream connection failure); UO (upstream overflow); NR (no route configured); URX (rejected because of upstream retry limit or maximum connection attempts reached).

We’re releasing Ambassador 0.73 today, with native support for the Linkerd 2.0 service mesh and the Knative serverless platform. Ambassador focuses on the ingress (“north-south”) use case for traffic management within modern cloud-native applications, and accordingly we’ve had integrations for quite some time with service meshes that focus on the service-to-service (“east-west”) use cases, such as Istio, Consul, and Linkerd. At the recent KubeCon EU, we saw an increased amount of interest around Linkerd, and also some potentially avoidable friction with the integration, and so we’ve improved the operator experience around this (more details below).

One of the core goals when modernising software systems is to decouple applications from the underlying infrastructure on which they are running. This can provide many benefits, including: workload portability, integration with cloud AI/ML services, reducing costs, and improving/delegating specific aspects of security. The use of containers and orchestration frameworks like Kubernetes can decouple the deployment and execution of applications from the underlying hardware. In the previous article of this series I explored how to begin the technical journey within an application modernisation program by deploying an Ambassador API gateway at the edge of your system and routing user traffic across existing VM-based services and newly deployed Kubernetes-based services.

In a Cloud Native world, microservices are running with ephemeral containers that are regularly deployed to multiple availability zones, regions, and even multiple clouds. As these cloud native applications become more complex, our supporting solutions like monitoring, have also had to become more complex. Today, more traditional monitoring responsibilities are being automated, and monitoring has become less human centric. In the first part of this series, we’ve summarized some of the most popular monitoring solutions with Ambassador.

This article provides an insight into the creation of the Ambassador open source API gateway for Kubernetes, and discusses the technical challenges and lessons learned from building a developer-focused control plane for managing ingress or ‘edge’ traffic within microservice-based applications. Key Takeaways Developed by Datawire, Ambassador is an open source API gateway designed specifically for use with the Kubernetes container orchestration framework. At its core, Ambassador is a control plane tailored for edge/API configuration for managing the Envoy Proxy “data plane”.

We are pleased to announce the GA release of Ambassador 0.50, with the headline features of Server Name Indication (SNI) support, more powerful rate limiting semantics, and a new AuthService. This release includes a major re-architecture under the hood that adds support for the Envoy Proxy v2 API and also uses the Aggregate Discovery Service (ADS) functionality, which removes the need for hot restarts. We are extremely grateful for everyone who contributed to this release, and also those who offered feedback via GitHub and our Slack.

We’ve discussed many interesting use cases for SNI support within the edge proxy/gateway with both open source and commercially supported users of Ambassador. In a nutshell (and with thanks to Wikipedia), SNI is an extension to the TLS protocol which allows a client to indicate which hostname it is attempting to connect to at the start of the TCP handshaking process. This allows the server to present multiple certificates on the same IP address and TCP port number, which in turn enables the serving of multiple secure websites or API services without requiring all those sites to use the same certificate.

I’m sure many of you have heard of the “Death Star Security” model—the hardening of the perimeter, without much attention paid to the inner core—and while this is generally considered bad form in the current cloud native landscape, there is still many things that do need to be implemented at edge in order to provide both operational and business logic support. One of these things is rate limiting. Modern applications and APIs can experience a burst of traffic over a short time period, for both good and bad reasons, but this needs to be managed well if your business model relies upon the successful completion of requests by paying customers.