HashiConf EU 2019 Summary: Hybrid Infrastructure and Application Modernisation
The Ambassador Labs team presented at the recent HashiConf EU event, which has been running annually in Amsterdam for several years. The event is always a lot of fun, and a great opportunity to spend two or three days discussing all-things infrastructure, and exploring how to get the most out of the HashiCorp tooling suite.
This year the keynotes were very polished, and the product announcements focused on the new Consul 1.6 release with additional Layer 7 service mesh features and Mesh Gateways, and the Terraform 0.12 release. I was especially keen to learn more about the latest features of Consul, as this is one of the Ambassador service mesh integrations that are becoming increasingly popular with users. This was also the topic of my talk at the event, about securing communication, from the end-user to service.
The Importance of Hybrid Infrastructure and App Modernisation, and the Corresponding Journey
Armon Dadgar, co-founder of HashiCorp, opened the event by stating that we are currently within the “multi” era of computing: multi-cloud, multi-platform, and multi-service. No longer is it accepted that one cloud vendor will completely dominate, and many organizations are hedging their cloud adoption by using multiple cloud vendors and an array of platforms consisting of VMs, containers, and serverless. This means that infrastructure tooling must work across the various stacks, and provide a consistent, common developer experience.
Armon introduced the HashiCorp Cloud Operating Model, and explored the associated four layers of this model: provisioning, security, connecting, and running. There was a clear evolution from “static” to “dynamic” within each of these layers. For example, within provisioning, we are moving from a fixed and homogenized infrastructure using dedicated physical servers, to a mixed, on-demand infrastructure consisting of VMs, containers, and serverless. In regard to the topic of connecting services, the traditional approach of host-based resolution with static IP addresses and ports is being replaced with a move to service-based identity with dynamic IPs and ephemeral ports.
For each layer in the Cloud Operating Model, HashiCorp offer a solution: provisioning is covered with Terraform, security via Vault, connecting with Consul, and running is supported via Nomad (with increasingly first-class support for Kubernetes).
With organisations looking to modernise their application stacks, the network is playing an increasingly important role, as this is the “bridge” that connects everything together; both old and new. Looking back into computing history, Armon mused how TCP is a fantastic protocol that allows us to connect all manner of devices from all different time periods. As modern web-based applications are increasingly relying on Layer 7, application-level functionality within the OSI model, a modern networking stack must provide excellent support here. This is where Consul shines, and the recent service mesh addition to Consul only make the value proposition clearer.
As networks are modernised, there is a shift in the associated technology stack from centralised hardware (think on-premises bare metal racks, routing appliances, etc) to distributed software (think Consul and Ambassador). The processes connected with managing this technology also shift, from manual, discrete updates, to automated updating driven via APIs. Armon was keen to stress that this won’t be a “big bang” change, and there is likely to be a hybrid combination of technologies and processes as an organisation modernised. Networking and communication tooling must therefore work seamlessly across existing and new technology stacks.
Gateway to the Future: Introducing Mesh Gateway, Powered by Envoy
Next to the stage was Mitchell Hashimoto, co-founder of HashiCorp, and his opening gambit was the introduction of Consul Mesh Gateway: secure service-to-service communication across networks with full end-to-end encryption that works everywhere.
Most organisations do not have flat networks, and often implement network segmentation for geographical, security, and management benefits. In addition, the default install and configuration of newer orchestration technologies, like Kubernetes, can also often lead to network address space collision when teams independently deploy multiple clusters. Mesh Gateways provides the ability to bridge and route across all of these networks segments, while still preserving the service identities and transport encryption provided by the Consul service mesh.
As with Ambassador and Consul Connect, Mesh Gateways are powered by the Envoy Proxy. The functionality within Consul is abstracted behind an interface, which in theory allows the swapping of proxy technology, but the message I took away from the event is that there is a lot of HashiCorp love from Envoy.
The configuration UX for the Mesh Gateway looked, as expected with HashiCorp tooling, straightforward and intuitive. The following proxy-defaults configuration will enable gateways for all Consul services in the local mode, where the Consul proxy makes its outbound connection to a gateway running in the same datacenter, and that gateway is then responsible for ensuring the data gets forwarded along to gateways in the destination datacenter.
Kind = "proxy-defaults"
Name = "global"
MeshGateway {
Mode = "local"
}As this feature extends the management and security benefits of the Consul service mesh across the entire network, I can see this tool being very useful for organisations introducing new cloud and container-based infrastructure into their existing stacks.
After my talk I did receive several questions in relation to the similarity between the Ambassador API gateway and Consul Mesh Gateway. My take is that Ambassador is very much focused on managing ingress, north-south traffic, and Mesh Gateway is tailored to managing service-to-service, east-west traffic, even if this extends across clusters or data centers.
A key thing to bear in mind is that the control plane and functionality within Ambassador has been designed with the idea that you don’t know the source of traffic into your cluster, and therefore support is provided for end user authn/authz via IdPs like Auth0 or Keycloak, HTTPS redirect and TLS termination, and flexible rate limiting. With Mesh Gateways you can assume that traffic traversing across networks has originated within a domain you control (or have provenance for). You still want to provide authn/authz, but this is done at a lower application-level with intentions (what can talk to what), and TLS will be enforced via the use of the service mesh.
HashiCorp’s Kubernetes Support is Now First Class (But Don’t Forget About Nomad)
Mitchell’s closing keynote pitch was that “Consul unifies everything”, which could be easily taken as hype, but with HashiCorp’s track record, I’m inclined to believe in this vision. Compared with the launch of other service meshes, the multi-platform support is genuinely baked-in, the configuration looks intuitive, and the use cases were clearly articulated.
When I attended HashiConf NA last year in San Francisco, it was obvious that Kubernetes support within the HashiCorp ecosystem was becoming increasingly important, but in this keynote it was clear that this is evolving into first class support. As the Datawire and HashiCorp teams worked together on the Ambassador and Consul integration, I watched the evolution of the HashiCorp consul-k8s project, and much of the functionality offered here is now baked into the very useful Consul Helm Chart.
With lots of attention being lavished on Kubernetes, it could be easy to forget about Nomad, HashiCorp’s own orchestrator, but I think the HashiCorp team are playing the long game here. I also chatted to several folks that were happy users of Nomad, and the primary reason they had adopted this tool was simplicity. As Kubernetes and the surrounding ecosystem evolves and picks up the almost inevitable bloat of features, the simplicity of Nomad could become a defining feature. Several folks asked me about Ambassador support for Nomad, and unfortunately we don’t have this. As Ambassador is tightly integrated into Kubernetes in order to provide the best UX and operational performance, and we can route to all platforms via the Consul integration, we don’t yet see enough demand to justify a rewrite. Of course, there is nothing stopping anyone from creating a community-driven project to modify Ambassador :-)
Wrapping Up
I thoroughly enjoyed my time at HashiConf EU, and it’s been amazing to witness the growth of the conference over the past several years. The atmosphere of friendliness, sharing, and learning has remained strong, and this is a testament to all of the HashiCorp team, the community, and everyone else involved.
I’ve got to give a special shout out to Nic Jackson, Anubhav Mishra, and Todd Radel, as they provided so much great guidance during the Ambassador and Consul integration, and they supported my talk at this event and the associated demonstrations we have presented at other conferences like KubeCon EU.
You can find the slides from my HashiConf EU talk “Securing Cloud Native Communication, From End User to Service” on SlideShare, and the following references should be useful, too.
References:
https://www.infoq.com/articles/api-gateway-service-mesh-app-modernisation/
https://www.getambassador.io/user-guide/consul-connect-ambassador/
https://www.getambassador.io/user-guide/consul/
https://www.consul.io/docs/platform/k8s/ambassador.html
https://www.hashicorp.com/blog/hashicorp-consul-supports-microsoft-s-new-service-mesh-framework
Emojify Ambassador and Consul code examples: https://github.com/emojify-app
