When we talk to people about service mesh, there are a few questions we’re always asked. These questions range from straightforward questions about the history of our project, to deep technical questions on why we made certain decisions for our product and architecture.
To answer those questions we’ll bring you a three-part blog series on our Aspen Mesh journey and why we chose to build on top of Istio.
To begin, I’ll focus on one of the questions I’m most commonly asked.
Why did you decide to focus on service mesh and what was the path that lead you there?
LineRate Systems: High-Performance Software Only Load Balancing
The journey starts with a small Boulder startup called LineRate Systems and the acquisition of that company by F5 Networks in 2013. Besides being one of the smartest and most talented engineering teams I have ever had the privilege of being part of, LineRate was a lightweight high-performing software-only L7 proxy. When I say high performance, I am talking about turning a server you already had in your datacenter 5 years ago into a high performance 20+ Gbps 200,000+ HTTP requests/second fully featured proxy.
While the performance was eye-catching and certainly opened doors for our customers, our hypothesis was that customers wanted to pay for capacity, not hardware. That insight would turn out to be LineRate’s key value proposition. This simple concept would allow customers the ability to change the way that they consumed and deployed load balancers in front of their applications.
To fulfill that need we delivered a product and business model that allowed our customers to replicate the software as many times as needed across COTS hardware, allowing them to get peak performance regardless of how many instances they used. If a customer needed more capacity they simply upgraded their subscription tier and deployed more copies of the product until they reached the bandwidth, request rate or transaction rates the license allowed.
This was attractive, and we had some success there, but soon we had a new insight…
Efficiency Over Performance
It became apparent to us that application architectures were changing and the value curve for our customers was changing along with them. We noticed in conversations with leading-edge teams that they were talking about concepts like efficiency, agility, velocity, footprint and horizontal scale. We also started to hear from innovators in the space about this new technology called Docker, and how it was going to change the way that applications and services were delivered.
The more we talked to these teams and thought about how we were developing our own internal applications the more we realized that a shift was happening. Teams were fundamentally changing how they were delivering their applications, and the result was our customers were beginning to care less about raw performance and more about distributed proxies. There were many benefits to this shift including reducing the failure domains of applications, increased flexibility in deployments and the ability for applications to store their proxy and network configuration as code alongside their application.
At the same time containers and container orchestration systems were just starting to come on the scene, so we went to work on delivering our LineRate product in a container with a new control plane and thinking deeply about how people would be delivering applications using these new technologies in the future.
These early conversations in 2015 drove us to think about what application delivery would look like in the future…
That Idea that Just Won’t Go Away
As we thought more about the future of application delivery, we began to focus on the concept of policy and network services in a cloud-native distributed application world. Even though we had many different priorities and projects to work on, the idea of a changing application landscape, cloud-native applications and DevOps based delivery models remained in the forefront of our minds.
There just has to be a market for something new in this space.
We came up with multiple projects that for various reasons never came to fruition. We lovingly referred to them as v1.0, v1.5, and v2.0. Each of these projects had unique approaches to solving challenges in distributed application architectures (microservices).
So we thought as big as we could. A next-gen ADC architecture: a control plane that’s totally API-driven and separate from the data plane. The data plane comes in any form you can think of: purpose-built hardware, software-on-COTS, or cloud-native components that live right near a microservice (like a service mesh). This infinitely scalable architecture smooths out all tradeoffs and works perfectly for any organization of any size doing any kind of work. Pretty ambitious, huh? We had fallen into the trap of being all things to all users.
Next, we refined our approach in “1.5”, and we decided to define a policy language… The key was defining that open-source policy interface and connecting that seamlessly to the datapath pieces that get the work done. In a truly open platform, some of those datapath pieces are open source too. There were a lot of moving parts that didn’t all fall into place at once; and in hindsight we should have seen some of them coming … The market wasn’t there yet, we didn’t have expertise in open source, and we had trouble describing what we were doing and why.
But the idea just kept burning in the back of our minds, and we didn’t give up…
For Version 2.0, we devised a plan that could help F5’s users who were getting started on their container journey. The technology was new and the market was just starting to mature, but we decided that customers would take three steps on their microservice journey:
- Experimenting – Testing applications in containers on a laptop, server or cloud instance.
- Production Planning – Identifying what technology is needed to start to enable developers to deploy container-based applications in production.
- Operating at Scale – Focus on increasing the observability, operability and security of container applications to reduce the mean-time-to-discovery (MTTD) and mean-time-to-resolution (MTTR) of outages.
We decided there was nothing we could do for experimenting customers, but for production planning, we could create an open source connector for container orchestration environments and BIG-IP. We called this the BIG-IP Container Connector, and we were able to solve existing F5 customers’ problems and start talking to them about the next step in their journey. The container connector team continues to this day to bridge the gap between ADC-as-you-know-it and fast-changing container orchestration environments.
We also started to work on a new lightweight containerized proxy called the Application Services Proxy, or ASP. Like Linkerd and Envoy, it was designed to help microservices talk to each other efficiently, flexibly and observably. Unlike Linkerd and Envoy, it didn’t have any open source community associated with it. We thought about our open source strategy and what it meant for the ASP.
At the same time, a change was taking place within F5…
Aspen Mesh – An F5 Innovation
As we worked on our go to market plans for ASP, F5 changed how it invests in new technologies and nascent markets through incubation programs. These two events, combined with the explosive growth in the container space, led us to the decision to commit to building a product on top of an existing open source service mesh. We picked Istio because of its attractive declarative policy language, scalable control-plane architecture and other things that we’ll cover in more depth as we go.
With a plan in place it was time to pitch our idea for the incubator to the powers that be. Aspen Mesh is the result of that pitch and the end of one journey, and the first step on a new one…
Parts two and three of this series will focus on why we decided to use Istio for our service mesh core and what you can expect to see over the coming months as we build the most fully supported enterprise service mesh on the market.