We will soon redirect you to our application using your account.
2018 was an exciting year for both, open source developers and vendors in the microservices and API space. In this post, we’ll recap the major developments and product announcements, plus make a few predictions for 2019.
In 2018 it felt like any vendor who didn’t already have an API gateway announced a generic or use case-specific one to round out their API management offering. Looking at the announcements that came through our feed this year, we counted at least half a dozen new API gateways and an equal number of new service meshes. 2018 also proved to be a good year for the Istio service mesh project. Istio benefited from the backing of Google, Red Hat, IBM, Lyft and Pivotal, a rapidly growing ecosystem and the ongoing excitement around Kubernetes.
Now, let’s look at a few of the product and company highlights in 2018 in regards to API gateways, microservices and service meshes by starting with Istio!
The Istio project is getting much attention in the Kubernetes world right now, especially amongst developers looking to manage microservices. It is an open-source service mesh originally created by Google, with IBM contributing Amalgam8 and Lyft its Envoy proxy, that helps developers connect, monitor and secure microservices on Kubernetes. Red Hat OpenShift, Pivotal and others announced support early on and thus the project was able to release its production-ready 1.0 version in July, along with a managed version running on GCP and Apigee API Management for Istio.
Additional companies that jumped on the Istio “bandwagon” in 2018 with products based on Istio, product integrations or with adapters include VMware, F5 Networks, NGINX, Datadog, Circonus and Giant Storm.
At AWS re:Invent in November, Amazon announced the public preview of AWS App Mesh, a service mesh control plane that builds on Envoy, like so many others. App Mesh is in early stages, but you can already monitor and control communications across your microservices running in ECS and EKS. The key development this year regarding Amazon API Gateway was the announcement that private endpoints were now supported. With support for private endpoints, developers can have private API endpoints inside their own VPC.
After its initial offering of Istio on GCP back in July, Google, one of the main backers of the Istio service mesh, announced the beta availability of Istio on the Google Kubernetes Engine (GKE) this December.
Microsoft added a Consumption tier to their existing Azure API Management service. This service is an API gateway that is delivered as a fully managed service and enables developers to manage and monitor APIs. The new Consumption tier is offered on shared and dynamically allocated resources, which Microsoft believes will be a better fit for those developing serverless applications.
Buoyant was the company that first coined the term “service mesh” back in 2016, and in September they released a complete rewrite in Rust and Go of their flagship service mesh as Linkerd 2.0. This new Linkerd deploys as a sidecar by default. With the release of 2.0, the Conduit service mesh project became part of Linkerd.
Also in September, the company behind the open source Kong API Gateway announced the availability of version 1.0. This release included support for service mesh deployment patterns enabled by the addition of shared TLS between instances and modifications to the plugin run loop. In December, Kong also announced a fully managed API platform called Kong Cloud.
In June HashiCorp released version 1.2 of their Consul-based service mesh. Previously marketed as service discovery, the new release added HashiCorp Connect which turns it into a service mesh using a sidecar deployment model. Connect furthermore enables service-to-service connection authorization and encryption using mutual TLS. Consul’s approach to service mesh is unique in that it ships with an easy-to-use data plane that is mean to be replaced with a real proxy such as Envoy if the need arises.
In March, Solo.io announced their first open source project, Gloo, an API gateway built for serverless functions. This was followed in November by a service mesh orchestrator called SuperGloo. In December, finally, the company emerged officially from stealth with their new enterprise-ready version of Gloo, called GlooE.
This is a sign of how vital modernization use cases around connecting fast-moving projects to “legacy” environments have become in the enterprise; a trend we expect to continue in 2019.
In a sad turn of events, Turbine Labs shut down in October. Turbine Labs was the company behind Houston, an advanced control plane for the Envoy proxy (which is also used by Istio). It was also the sponsor of the open source Rotor project.
This shutdown serves as a stark reminder to all of us how early and fast-developing the service mesh space still is.
Without a doubt, the biggest announcement in the API management and API gateway space this year was Salesforce’s $6.5 billion acquisition of Mulesoft, announced in March and completed in May. Integration is still a hot topic and will only become hotter the more applications are getting connected.
In December, VMWare announced a beta version of a service mesh of their own, called VMware NSX® Service Mesh. This new offering is based on Istio, which will act as an extension of VMWare’s NSX-T Data Center platform.
Also in December, F5 Networks announced a public beta of its Istio-based service mesh called Aspen Mesh. Aspen Mesh is a fully hosted software-as-a-service (SaaS) platform that comes with professional support.
At the same time, A10 Networks announced yet another service mesh, Secure Service Mesh for Kubernetes. This offering focuses on securing east-west traffic transparently and includes a comprehensive set of features like elastic scaling, automated service discovery, micro-segmentation, encryption between nodes, plus per-service analytics.
Dell Boomi updated their iPaaS offering with an API gateway and developer portal that promises enhanced security and scalability when interacting with third-party services. We have seen many organizations deploy API gateways to enable closer developer collaboration and this announcement plays directly to them.
In May, content delivery network provider Akamai announced Akamai API Gateway. Akamai’s gateway shipped with support for Swagger, RAML, scalable access controls, and user quota enforcement.
Jumping on the API gateway bandwagon, Bank of America Merrill Lynch announced an API gateway that allows its clients to access their banking information and initiate transactions on a real-time basis, plus make direct connections to ERP and treasury management systems.
At Glasnostic, we released version 1.0 of our cloud traffic controller in September and have since been helping enterprises with great success to take control of the complex emergent traffic behaviors of their connected application landscapes, especially around security and IT modernization use cases. Our controller inserts transparently into the network data plane to then apply large-scale, dynamic traffic policies based on network and traffic properties. For our security-focused customers, we added the ability to express policies based on packet contents in December.
Based on the above, we expect three major developments to accelerate over the coming year:
First, the trend to “decouple everything” will accelerate. As API gateways continue to decouple service implementation from product presentation, containers continue to decouple provisioning from services, microservices continue to decouple scaling aspects from applications and parallel teams continue to decouple development effort from applications, so will service meshes continue to decouple service-to-service communication from application logic.
Specifically, as we’ve seen already happening this year, we expect API gateways to become a commodity feature of API management platforms. They will be increasingly used to facilitate and manage intra-enterprise application connections and enterprises that have started down the path of building their own API gateways for this purpose may switch to external products as these use cases solidify. On the service mesh side, we expect Istio to become even more tied to Kubernetes and become part of the distribution itself. At a minimum, we’ll see a high-profile Kubernetes distribution package and expose Istio out of the box by default. We also expect service meshes in general to thrive in 2019, in particular in the container world, even though there is a good chance that Istio will become “the” service mesh, thus drowning out the rest. This scenario could accelerate should service meshes increasingly become an integral and undifferentiated part of container orchestrators. Finally, we expect some of the hype around service meshes in non-containerized environments to recede due to their relatively high operational cost and narrow, service-to-service connection focus.
Second, because of this trend to “decouple everything” by default, we expect that the large-scale connecting of applications and services will accelerate in 2019. Once business capabilities are separated out into individual services, it simply makes too much sense to re-compose them freely to support new products and services. As a result, system landscapes will increasingly live in the presence of continual change.
Third, connecting everything will make heterogeneous environments the new normal. There will be less talk of “legacy” vs. “cloud-native” and instead more talk about application and service landscapes.
Here’s to 2019!