What if the future of networking was Networkless?
Disclaimer: At the time of writing this series of articles, I am working for Riverbed Technology as a Senior Director. I lead the Technical Evangelist Group that I founded in 2017. The topics and ideas that I am going to develop are my own opinions based on more than 15 years in the Tech Industry (already??); they are not those of my employers.
This is the first article in a series and serves as an introduction to the concept of Networkless, an idea I have been thinking about for the past years.
In the following articles, we will drill-down into more technical details, explore new concepts, putting more meat around the bone.
Where I am coming from
I am a Tech guy, not 100% a software engineer, not 100% a network engineer, I am a Tech guy. It does not mean I am an expert in all kind of technologies, I have always been at the crossroads between Networking and Applications.
I started my career as a Networking engineer for a large car maker in Europe where in addition to designing and building networks, I developed a Netflow collector in C, Perl and PHP. Then, I joined the R&D department to work on Car-2-Car and Car-2-Infrastructure — Cloud was not fancy yet at that time- communications where I developed in Java (OSGI, JSP…) on top of IPv6, 3G and some variations of WiFi for this type of use cases.
Since 2007, I have been working on Application Performance helping Enterprise customers understanding how Applications behave on the network, what the impacts of networking are on user experience, how to mitigate the different effects of latency, application chattiness, bandwidth, identifying the application components responsible for slowness…
In 2016, I made a discovery that ignited this concept of Networkless. As Riverbed Technology was releasing a new product — SteelConnect, their SD-WAN offering — I was looking at ways to demonstrate the power of APIs in the networking world. I developed an Alexa Skill to command the network with an Amazon Echo. It was fun and got really nice feedbacks. Since then, I have been amazed by the power of voice-enabled products and AI in general. The real discovery though was under the hood. Building an Alexa Skill was my first introduction to Serverless computing (also simply called Serverless) starting with AWS Lambda functions.
Welcome to Serverless!
Serverless is often synonymous of Function-as-a-Service a.k.a FaaS like AWS Lambda; in fact, it is much more than that. I won’t go in the details just yet, let’s keep it for later on.
What I found really powerful with Serverless is that it allows developers to focus on the code and you don’t need to build a complex machinery to be able to test and run code. In fact, Serverless brings us close to the holy grail of NoOps and as such differentiate from DevOps.
Of course, you would still need your full code pipeline to make the best use of it. However, you don’t have to provision and manage a server, install a language runtime (Java, Python, Node.js you name it…) and everything else. This is made for you. Upload or copy your code, expose it via APIs (or use other triggers) and you can enjoy your new app.
Another really cool benefit is that you pay only when your code actually runs. That could potentially mean big savings!
There are corner cases where FaaS is not the best approach (yet!), specifically for heavy workloads with processing time longer than 5–15 minutes. Nevertheless, in general, I find that I could address pretty much all my needs with Serverless.
I fell in love with Serverless and for the past 4 years, I have been spending a lot of time following what’s happening in this domain, attending the events (meetups, Azure or AWS local meetings, the Serverless Conf’…) and doing some experimentations. I truly believe that this is the future of Applications.
I have built a lot of small apps to simplify my life, built demos with it and finally with my team, we have developed a complex Serverless system that provisions on-demand demos of Riverbed products for our Technical sales force.
Ok, fine, I am a Serverless believer. Now, what is the link with Networking?
The Application-Networking Continuum
After this discovery, I started to wonder how Serverless could impact the Networking Industry and finally what the future of networking could be.
So I started to think about those two parallel universes: Applications and Networking. How did they evolved in the past years and what could be the next evolutions?
The way Applications are hosted, architected and managed changed a lot over the past 30 years. On the Networking side, not so much… We are still using the same principles. More importantly, we build and operate networks pretty much the same way we did 10 years ago. The way we consume network services remains the same - although we can now subscribe to few of them. Most of our networks are bespoke and built from the ground-up with the operation tools, processes and teams to put in place…
Of course, the industry did not stall. Networks evolved and have been getting better (i.e. more reliable), quicker (bandwidth capacity grew exponentially), easier to manage and the protocol stack got stronger.
We also had to adapt to new environments like Virtualization or the Cloud. SDN and more recently SD-WAN have helped. For example, SD-WAN is really great at connecting users to instances running in the Cloud (IaaS, PaaS, SaaS): you can deploy an appliance in a branch site, have it configured centrally, select the VNETS or VPCs you want to connect to and tunnels are formed automatically. It feels like magic, it simplifies a lot the way we interconnect “sites”, but it is not fundamentally different from what we used to do: we deploy appliances in the branch, that we have to configure someway, connect to uplinks, manage VLANs, configure routing protocols (OSPF, BGP…), add routes, update firmware, keep our security up to date…
As we are starting to see the second wave of Cloud adoption with “Cloud-Native app” being developed based on Micro-services and Serverless, I figured it is probably time to invent the next evolution of networks.
There are already good things happening:
- Network Engineers have started adopting automation (Ansible, Python…) but my experience working with the Fortune-1000 Enterprises makes me say it is far from being mainstream. Still, I am glad to see Cisco’s DevNet community becoming bigger and bigger, with great content, tutorials, sandboxes… Most of newer networking products come along with APIs. It means that the networking industry is going in the right direction.
- Service-Mesh is a very interesting technology to interconnect micro-services together;
- 5G is coming which opens a whole new world of possibilities in mobility and perhaps as we designed branch networking;
- Low-Earth orbit satellite internet…
- And more to come…
How can we leverage those new ideas and what makes Serverless such compeling to build the future of networking?
Could we imagine a network that:
- will be composable and modular,
- will be used on-demand,
- will be billed following a Pay-As-You-Go model,
- with limited or eventually no need for Network Operations,
- grants the best security and remains up to date all the time,
- Automatically scales (up, down…)
I believe it and what I have been dreaming of for few years now. Simon Sinek, one of my favorite authors/speakers, says “Dream Big, start small. But most of all start!”. And when you start a journey, it is probably a good idea to have maps to guide you along the way.
Wardley Maps
If you are interested in the topic of Serverless, it is very likely that you have heard about Simon Wardley and his famous maps.
I met him at the Serverless Conf’ in San Francisco in 2018. His presentation was great and you can find more details about his approach on Medium but also condensed in that very good talk. I also find this post really useful to create maps.
In a nutshell, the idea here is to get a visual, to “map” the environment so you can identify the constraints, dependencies of the things you do, your practices, the data and the knowledge. The two axis are really important: evolution and value chain.
They are a great tool for to communicate, for collaboration and learning patterns.
Here is a map that Simon Wardley tweeted that illustrates how the application world evolved and what could be the next steps:
Application-Networking evolution
So let’s start from the beginning. The below shows how an application has been traditionnaly used in an Enterprise:
As Enterprise started to adopt the cloud, they considered compute as a commodity, lift & shifted their VMs on AWS EC2 and the like of it. Some large Enterprise decided to move all their workloads in the clouds, those are known as Cloud-First companies. When everything is moved, there is no more Datacenter LAN to operate, it is part of the Cloud offering.
Very quickly, we realized that we could use more Cloud-Native services to run Databases (AWS DynamoDB, Azure SQL…) and even webservers.
The rapid (long time after 2006 though!) adoption of the Cloud forced Enterprise networks to adapt and become more agile to support that move. SD-WAN addressed that need and leveraged Internet for transporting data between the branch and the cloud.
Cloud-First customers are moving away from MPLS and are completely relying on the Internet to build their WAN. In addition, as Enterprise customers have started to build their apps as micro-services, we are seeing Kubernetes being adopted as well as Service-Mesh and Cloud-Edge router.
Let’s pause a bit to quickly give more details:
- Kubernetes: it’s a container orchestration system for managing application deployment and scaling;
- Service-Mesh: I found this definition given by Rob Whiteley, from NGINX, quite good for an introduction.
“Think of a service mesh as a specialized Layer 7 network for microservices APIs. It offers authentication, authorization, security, and performance services to optimize the “east/west” traffic running between services. More importantly, it gives you a central point to apply these policies rather than having to code all of this directly into the business logic of your applications.” (Why You Should Care about a Service Mesh — The New Stack)
If you want more details about Service-Mesh, I highly recommend this one too from one of the creators of Service-Mesh.
- Cloud-Edge router: not your dad’s router, look at Traefik from Containous. It is a really cool product. They have also released their own Service-Mesh implementation keeping the same philosophy than from Traefik.
AWS and Azure released managed-services for Kubernetes (respectively EKS and AKS) and Service-Mesh too (App Mesh & Service Mesh Fabric) so we could consider them becoming closer to commodity services. However, since there is still a certain level of complexity, I would keep them as products.
Now you can build really cool applications with FaaS (i.e. AWS Lambda and the like). An user will interact with it via an API gateway.
The link to Kubernetes is not obvious nor always needed. However, I consider EKS — and by extension Kubernetes— part of the AWS Serverless ecosystem. In our case, for the demo platform we have developed, we are using EKS to take care of longer processes and heavy workloads like deploying a network topology via Ansible. We don’t have to manage a set of containers; we just use the computing capabilities and pay for it when needed — to deploy the network topology — then it is recycled.
Now let’s consider a Branch and reflect upon how it evolved the past years. Of course, large campus will still exist in the near future. However, it is also true that there is a growing number of remote or nomad workers: think about your sales force, executives but not only… The success of companies like Upwork demonstrates the growing needs to use distributed resources on a contract basis. Furthermore, the cost of life in large metropoles (San Francisco, New-York, London…) and the competition with GAFAs drive companies to build distributed teams that are working from home.
So, in this context, except for the rare large HQ, regional offices and factories, is there a need for a LAN in the branch?
For remote workers, there is a LAN that is not managed by the Enterprise networking team. I believe that eventually the LAN in branches as we know it will disappear. Actually, it will exist but will be a service offered by the facility where your office is hosted, like any other utility (water, electricity…). Think about it. What is the real value of a LAN? Does it give a competitive advantage to a company? It is just expected to work…
Security is your concern? We will address that in a following post.
What about your WAN? SD-WAN is already an interesting evolution to a traditional WAN and does provide value. Probably one of the most interesting is path resiliency with multiple uplinks and features like packet racing or application SLAs. The fact that it is software defined and managed by a central controller is key too.
Couldn’t we get a service based on SD-WAN with multiple uplinks? Instead of having one single Internet broadband connection, you would ask for SD-WAN service that would provide several uplinks (Internet broadband, 5G, Low-earth orbit satellite…), based on a pay-per-use model with the ability to scale up and down? There is an opportunity for innovative service providers to disrupt the market here. Be aware that Microsoft and AWS are looking at this already: look at Azure Virtual WAN for example…
No more networks?
At this point, I might be considered as an heretic by some, others could be afraid of losing their jobs. Networks will still exist! They will be consumed differently by Enterprise customers. There will be always exception of course and it will slowly evolves.
Networking people, there is an opportunity to move up the stack and innovate. This is what this series is about!
In the next post, I will discuss about disaggregation and how it will define Networkless.
