AUSTIN – If 2017 was the year of Kubernetes within the cloud-native computing movement, 2018 looks like it might be a year in which all of those companies embracing microservices realize they now need something else to make sure all those services can communicate.
Over the last six months, there’s been growing interest in a technology called the service mesh, and it was a hot topic this week at CloudNativeCon and KubeCon 2017. During our conversation last month at Structure 2017, no less an authority on massive distributed systems than Google’s Urs Hölzle described the Istio service-mesh open-source project backed by Google as potentially even more important than Kubernetes.
At CloudNativeCon this week, William Morgan, co-founder and CEO of Buoyant, described the service mesh as a “dedicated software layer for managing service to service communications” during a whirlwind talk Wednesday. Morgan co-founded Buoyant last year to take advantage of his experience helping Twitter navigate through the scaling problems that nearly killed the company before it got off the ground, and one of the key insights from that experience is that microservices are great, but super complicated.
There has been a general movement over the past five years or so to break down older applications developed in what’s called a “monolithic” style, in which one gigantic slab of code was written to develop the app, into apps based around microservices.
Monolithic apps are fine for some things, but companies ran into problems scaling them as web activity took off, and they’re much harder to update because monolithic apps have a lot of dependencies that can cause problems if one part of the chain is changed. Microservices allowed companies to build apps comprised of lots of separate little specialized services, and this greatly improved reliability and security because apps could now be updated much faster. And apps based around microservices can more easily take advantage of containers to run across multiple data centers or cloud providers.
But, like most advancements in the history of computing, microservices-based apps have now become so complicated that it can be hard for development teams to stay on top of everything. Couple that with the usual problems in software development — bugs and unpredictable hardware — and cloud-native software starts to run into reliability issues as more and more containers are run across different environments, Morgan said.
So companies wind up writing custom software to handle these issues, and that’s just not a good use of anybody’s time, said Ben Sigelman, co-founder and CEO of Lightstep.
“We often find ourselves wanting to build application software but we’re writing code to do the same thing over and over again,” he said.
Enter the service mesh. This technology provides a simpler way for services to talk to each other as they are deployed across containerized environments, which helps prevent outages as requirements change.
“Github going down can have a significant impact on the software industry,” said Jesse Newland, principal site reliability engineer at Github, the central code repository that virtually the entire software development industry uses as part of their workflow. The company built its own service mesh technology to deal with these issues, but is considering adding Envoy, an open-source project originally developed at Lyft, to its mix, he said.
Buoyant has developed two separate service-mesh projects: linkerd, which is part of the Cloud Native Computing Foundation, and Conduit, which was released earlier in the week at CloudNativeCon. Conduit is designed specifically for Kubernetes, while linkerd can be used across different cloud-native environments.
Istio, released earlier this year by Google, IBM, and Lyft and based on Envoy, is another open-source service-mesh project that comes up in these discussions.
#kubecon @IstioMesh session is packed, hot topic! pic.twitter.com/V9l1iKYKEy
— chanezon (@chanezon) December 8, 2017
“We’re really doubling down with Istio, the service management layer that’s built on top of Kubernetes, which may actually turn out to be more important than Kubernetes itself,” Google’s Hölzle said at Structure in November.
It’s not clear if cloud-forward development organizations will embrace the service mesh as quickly as they have projects like Kubernetes, but this definitely feels like a space to watch in 2018 as Kubernetes settles into a stable role as the container-orchestration project of choice. Companies don’t necessarily need to be Kubernetes users to take advantage of the service mesh, but this seems like the way new webscale services will be built as we round out the decade.
