What if the future of networking was Networkless? Part 2
In the previous part, I made the case for a Networkless future. Very much alike with Serverless where there are still actual servers that you don’t manage and you are requesting computing capabilities for some time to run your business logic; in the Networkless world that I envision, there will still be networks, you won’t manage them and will request networking capabilities to transport the data.
In this post and the following, I will share more details to build that new world.
First of all, I’d like to highlight a movement that happened a few years ago in the industry: the network disaggregation.
Network Disaggregation
Andrew Lerner from Gartner explained that trend in one of his posts in 2014 (!) and said it was cool. It is indeed. It means that we decouple the software from the hardware. Why is that a good idea?
Traditionally, in the network world, for the longest times, you would buy an appliance, an offer that combines hardware and software offered by the same vendor. You could not go around that.
That separation have been made available in the server world for many years: you buy an x86 server and then you deploy on top the OS you want (Windows, the Linux Distribution you want, VMware VSphere…).
It is a good thing that it came in the Networking industry too. It should help reduce vendor lock-in with more competitive prices (reducing huge margins on hardware…).
Hyperscale companies embraced it years ago. Nevertheless, it is far from being mainstream in the Enterprise market.
One of the main reasons from my point of view is that we kept a legacy approach, both on the vendor side (building monolith OS, high margin both on appliance and support, limited API/automation…) and on the network operator side - equally end-customers (adoption of automation/NetDevOps, fear that system will be less reliable, “always done that way” syndrome…) as well as service providers (they have their processes, impact on SLAs, very tight relationship with big vendors…).
Of course, vendors have been offering virtual appliances too that can run on top on VMware vSphere, Microsoft HyperV and sometimes KVM. However, the points I raised earlier are valid for the virtual form factor of the offerings.
Vendors’ appliances in the Cloud? Yes, of course, they tick the box for RFPs. Those are merely VM packaged to run on Azure and AWS and are not leveraging the power of the Cloud.
Instead of going the disaggregated way which is kind of equivalent to a “lift & shift” approach, let’s embrace the Cloud-Native approach to develop new network services!
I believe that we should reinvent and design the future of Networking with composability in mind.
How are Serverless apps built?
Allow me another digression so I can make once again a parallel with the application world.
What I have found super powerful with Serverless (in fact with Microservices) is the ability to leverage key bricks to built an application. You don’t have to reinvent the wheel each time building undifferentiated features (i.e. not your core business) or setting up systems:
- authentication (Okta, Auth0, AWS Cognito…),
- payment (Stripe…),
- storage (AWS S3…),
- database (FireStore, DynamoDB, Aurora, CosmosDB…),
- maps (Here, Google Maps…),
- secure vault (AWS SSM Parameter Store…),
- security…
You can leverage existing proven solutions that are kept updated by focused teams who are expert on the matter. They will always be offering the latest and greatest for the benefits of your end-users. If that solution does not fit your requirements (features, SLAs, support reactivity…) anymore, just switch to another vendor.
Sam Kroonenburg described his experience building the A Cloud Guru platform in an inspiring blog post. He is sharing some of his amazing results: building from the ground-up a complete application in 4 weeks enabling a complete new business which four years later is thriving. He leveraged the power of composability with many different services:
What if we could consume Networking services in such a way? I think it would enable companies to speed up their time to market and drive lower costs.
Composability for Networking
Back to our LAN and WAN, today how can I build my network with different bricks that are responsible for different tasks?
Easy will you say. We have done that for ages. You can have a box for each type of services: Firewall, WAN optimization, Proxy, Router… We discussed already that this age of appliance is passed. Besides, service chaining is a dream that have never been really implemented, even between appliances of the same vendor, let alone between different vendors.
What is the Cloud-Native way? How could we consume network services following that approach?
There are some interesting services already available. Zscaler is a good example of a cloud security company that has been successful the past years. In their model, you don’t need firewalls in all sites for scrubbing the traffic and look for malwares, virus and other threats. Your internet traffic is analyzed and your security policies enforced in the Cloud.
Cloud Access Security Brokers (CASB) like Netskope, Forcepoint or Palo Alto Networks and the new Secure Access Service Edge (SASE) offering are evidence of the transformation the Networking market is going through.
This is a nascent market and a lot will happen in the coming years. One of the challenge though is the service chaining or how to get access to those service at scale. The automation brought by SD-WAN helped. Riverbed Technology (I am an employee at the time I write this article) offered the first SD-WAN solution that could connect in an easy way those types of cloud services.
Besides cybersecurity, there are very few types of offering that are consumable from the Cloud. One of them is UCaaS with the like of RingCentral, Microsoft Teams or Cisco. Those bricks are really independant from the rest of the network with limited integration.
If we look at all network functions, almost none have transformed. Vendors will have to transition faster or will disappear…
Network functions as a API
End of last year, I met Twilio. I did not really know what they were doing. I heard of them, saw their ads in San Francisco and on the web. They have had a tremendous growth on the stock market.
I think it is a great example of a next generation of network/telecommunications services. They offer SMS, Email, phone calls and chatbots via APIs.
This company has built a fantastic business on telecom services offered to developers. This is also how I envision the future of networking and will share that vision in the next and final part of this series about Networkless.
