On Building a Commercial Networking Product for the DevOps Community. A Founder's Perspective.
I’m excited for tomorrow. Tomorrow is the day that F5 responds to the needs of the DevOps community by re-launching the LineRate brand and product line.
You might be asking yourself what is so important about a DevOps networking product? You might also be asking yourself what is so important about a commercial DevOps networking product? You might be thinking, why would I buy anything when I can roll my own using open source and a bit of ingenuity?!
A confession. I was a roll your own kinda guy when I started LineRate, but I learned a valuable lesson in the process of standing up the company. The first thing I was going to do was set up email with a postfix server when my co-founder Manish slapped some sense into me and convinced me to use Gmail as it just worked. A couple of hours later we had fully a functional email system that “just worked”. Sure it didn’t have a few features that I’d have liked, but we were up and running in no time which was point!
Did we go commercial for everything? Of course not. We bought a pile of disks and built our own filer using FreeBSD and ZFS - still running today - because we couldn’t afford a commercial solution. We focused on what mattered: time-to-market and money.
Not long after the great LineRate infrastructure debates, I had a series of company defining discussions with a variety of companies. One was a large infrastructure SaaS company that would ultimately become our first customer – all we had to do was deliver in a timely fashion. Another was a smaller company that had rolled their own solution using linux and Nginx – maintaining the solution became a serious problem for them as patches kept rolling in requiring repeating retuning and other reintegration efforts. The important common threads were that they all wanted an advanced Layer 7 traffic management platform with the following three key “features” that they couldn’t get any other way:
· Support
· Capacity Pricing
· Full Programmability
Beginning with support, they wanted someone to call to get complex fixes implemented and delivered quickly, without having to hire talented kernel and networking engineers. When pressed there were three key drivers behind the decision to get support from a commercial entity. First, the opportunity cost of deploying precious headcount to non-revenue generating activities, such as networking, was too high. Second, they realized that once those projects were staffed, they’d be staffed for the life of the core product(s) for incremental features and on-going product maintenance. Finally, even if they wanted to, hiring the requisite networking and kernel engineering talent to build high-performance, flexible, and manageable networking platform is a difficult task to accomplish for a non-core product capacity.
However, the support calculus above only makes sense if the pricing model can be aligned with the business’ needs. So after some discussion with the SaaS company we derived (borrowed) a capacity based subscription model that aligned the costs of infrastructure capacity with the traffic and thus revenue of the overall business. This had the added benefit of eliminating the need for complex capacity planning exercises, as one would buy off-the-shelf servers and load software directly onto them. We also added the concept of bursting to the model so that in the event of an unplanned increase in traffic one merely had to add an extra server to the pool and true-up after the fact at a pre-negotiated overage rate.
We also recognized that programmable customization is another key driver for rolling one’s own solution, and customized data path elements can play a crucial role in revenue generating activities. The plan we embarked on was to initially build a rock-solid high-performance vertically scalable Layer 7 networking platform with all the core features and then add extensibility to that data path. In terms of performance and scale, we targeted and delivered with our 1.6 release in April 2012 millions of simultaneous active connections and approximately 200,000 connections per second on an Intel Westmere class platform ($5,000 server at the time).
Why did we limit ourselves to implementing the core features only? Because we realized that there was no way that we as a startup could deliver the breadth of features needed to satisfy the DevOps community and their insatiable quest for differentiated advantages. One can’t call a feature differentiated if everyone gets the feature at the same time… The plan for our 2.x release train was to expose those core features/primitives via a programmable data path and allow our users to develop the rich features they wanted/needed. Want the ability to easily implement a custom load balancing algorithm? Want the ability to query an application server for authorization decisions from the network? Want the ability to translate API queries from one protocol to another? Check, check, and Check. We even talked about ability to bridge HTTP to NFS – possible if someone writes a Node.js NFS module!
Why Node.js and not Python, Perl, Lua, or your other favorite language of choice? That’s a good question, our initial plan was to use Unladen Swallow (Python), but we switched to Node.js for a few important reasons. The most important reason is that we wanted a language that would make it easy for developers to write high-performance data path code without having to be data path programming experts. Python and most other languages have blocking I/O primitives that make it difficult to not block the data path during many operations while Node.js is an event driven model and one has to work to block the data path. Second, we wanted to expose a system with a large and active community; as of this writing the NPM repository has almost 50,000 packages and over 30 million package downloads per week. Finally, node.js is built on top of Google’s V8 javascript engine that delivers amazing performance allowing for complex tasks to be accomplished using a full-featured language rather than us creating a networking optimized language.
With these key features in place, we believe that the incentive is now properly aligned on revenue generating rather than cost minimization activities.
So what is so important about a commercial DevOps networking product?
Freedom. Freedom to focus on what is important. Freedom to focus day in and day out on new, different, cool, and exciting problems!
With that said, I hope everyone will join me in congratulating the team by downloading the full-featured free tier from linerate.f5.com and exploring what the product can do for you.
Thanks and happy coding!
John Giacomoni
Founder, LineRate Systems
Senior Architect, Product Development, F5 Networks