Turing award winner and MIT professor Barbara Liskov famously championed the power of "abstraction" as a change agent in computer science and system design.  So when I heard about an emerging service-level abstraction that has the potential to be to microservices what TCP/IP was to client-server, I was intrigued to learn more.

I recently had the opportunity to speak again with Oliver Gould co-author of the Linkerd project, about the version 1.0 release and the idea behind why its novel "service mesh" solution is becoming an essential component of the cloud-native computing stack.

VMblog:  First, start with what Linkerd is and the problems it solves.

Oliver Gould:  Once you have an application in a cloud-native environment with several services, operating that application at scale becomes pretty difficult because it can fail in a lot of ways, and it fails in ways that Docker and Kubernetes can't handle. Interactions of the services themselves becomes a fragile thing. That's the basic problem domain that Linkerd is targeting, and what we encapsulate with the notion of a "service mesh."

Linkerd is a dedicated layer for communication between microservices in a cloud-native application. Similar to how how TCP/IP provides an abstraction for reliably delivering bytes between network endpoints, Linkerd's service mesh model abstracts the reliable delivery of requests between services in a cloud native application.

VMblog:  Linkerd has an interesting origin story, born at Twitter.  Tell us a little bit about the back story.

Gould:  The interactions between services were so hard to get right at Twitter. When you saw the "Fail Whale", there's a good chance it was due to communication errors between services. When we started I was on the team tasked to unify service discovery at Twitter and root out those complexities.

If you are at a Facebook, Twitter, Uber or Lyft type of hyper-growth company, there are huge armies of engineers to build custom technologies. For this general services communication challenge, Twitter built a project called Finagle. I was a part of that team.

Work on Finagle started in October 2010. We open sourced it a year later. Our platform engineers were building a service to handle all of Twitter's traffic. They realized that every team was solving all these problems across programming languages and ecosystems and we needed to consolidate that. Load balancing, connection pooling, things like timeouts and retries, and all kinds of complex operational features--those were behind the thinking of some of the major abstractions in Finagle.

As you know, Linkerd is not the first example of infrastructure innovation born out of the scaling pains in the Fail Whale days at Twitter. Similar to the early adoption path of Apache Mesos, Linkerd is gaining traction by offering the type of tooling that platform engineers need when they are supporting cloud-native, microservices architectures. I think we're seeing this pattern of infrastructure startups that were inspired by home-grown solutions that were critical to major web-scale startups' success, and wanted to create a more consumable format for the enterprise market at large. And that certainly describes what we're trying to do.

VMblog:  How have you and the community taken Linkerd beyond the original Finagle capabilities?

Gould:  Linkerd took some of the key components of Finagle and wrapped it up with additional capabilities and a much more consumable format. We started by deciding to wrap Finagle as a proxy, giving it all the integrations to make it fit into existing stacks (talks to Consul, the Marathon API, etc.). And you configure it with YAML instead of Scala code. The explosion of microservices and move to cloud native stack has people writing in different languages and you need something that runs across all the stacks. Those are the types of things that we designed into Linkerd to make it more consumable by the masses.

It's sort of similar to how Mesosphere took raw Apache Mesos (which by itself is extremely challenging to install, configure and scale) -- and created DC/OS to provide more consumable packaging and a range of more enterprise-grade features.

VMblog:  If you don't face Twitter or Facebook-scale traffic levels, what circumstances do you have to have to start facing these challenges?

Gould: One of the main drivers for the cloud-native approach is to divide the responsibility for a large application among several teams, each of whom are responsible for independent services. The tools we're used to don't really make it easy for these teams to work together. I would say it's less about the amount of traffic and more about the need to separate concerns between microservices.

We've also found that companies increasingly have small platform teams. These platform engineers--the people running Kubernetes or Mesos in the company--want to give the application teams enough tools to do their job without impacting each other. This type of ownership and autonomy allowed Twitter to move quickly at scale -- we're seeing that play out in the enterprise now too, and they need the type of operational tools that companies like Twitter had, minus having to build it themselves.

VMblog: What's the common "stack" that Linkerd is a part of?

Gould: Linkerd shines when things are moving quickly. Think of Kubernetes, Consul, Marathon, Aurora, Mesos, Docker, Zookeeper, Opentracing. Looking forward, we're focused on HTTP/2 (new version of the web protocol) and Google's gRPC. All of these technologies allow companies to scale their applications and teams in new and exciting ways.

Rather than focus on TCP/IP connections, we deal with requests. We can layer over many network topologies, and that's another important aspect of the overall Linkerd abstraction.

##