Why I Joined Netris
I love computer networks, I always have. In high school I bought my first 2400 baud modem and it changed the course of my life. Someone helped me peck out some AT commands and gave me a printout with a bunch of names and phone numbers on it and I got my first glimpse of online communication, BBSs. From the moment I saw that logon screen I was hooked. I came home from school every day and logged on, to chat with friends and download games. With a 2400 baud modem, you are very quickly going to learn the basics of networking such as bits vs. bytes, transfer times, Quality of Service (i.e. telling everyone in the house not to use the phone for the next hour), and more. I followed the normal path in college and learned all about operating systems, databases, programming, and IT management. But somewhere back in 1992 my course was set, I was going into networking.
I recently made the decision to join Netris, a startup focused on building the world’s best networking automation technology for on-prem deployments. I’ve worked for networking startups for roughly the past 10 years, in fact, when my recent startup was acquired by a large router manufacturer, I knew early on that I needed to leave. Not because I didn’t like the new job, the people were great, but because I didn’t think I had done “it” just yet. What is “it”? What is the itch I’m still trying to scratch? It sort of boils down to one thing.
Networking is still broken.
Well obviously I don’t mean this literally, otherwise all of the phones in all of the NOCs of the world would be ringing right now. But obviously they are indeed ringing in some NOCs, and hey why do we need so many NOCs anyhow? Running them is exorbitantly expensive, and they only serve to centralize communications, take the heat off the network engineers who work the 9 to 5, and keep the network from blowing up on the evenings and weekends.
NOCs aren’t going away anytime soon, but let’s explore some of the problems that still plague networking. Network architects are still building new networks, for as much activity as there is in the cloud, modern companies still need to run their own data centers and networks.
But the advent of cloud computing has forced us to reconsider how we provision and manage most IT systems, network included. Cloud introduced a radically simplified way of handling resources, the user experience is amazing. It has allowed us to focus on the applications and how we can grow the business without worrying about the underlying infrastructure.
If you’ve been using the cloud for a while, you have probably realized that it is not “one size fits all”. There are many situations where cloud simply won’t work, a few examples include low latency applications, compliance issues, and processing huge amounts of data. And then finally, there is the issue of cost, which is causing a lot of businesses to reconsider their move to the cloud. As stated in this excellent article:
“You’re crazy if you don’t start in the cloud, you’re crazy if you stay on it.”
But if you decide to move applications out of the cloud, what sort of experience are you going to want? Do you want to use the legacy model of having 4 different teams managing pieces of a single deployment workflow? Of course not, we still want to have that simple management model we’re now used to.
So the next major goal in IT (and in networking specifically) is to make the physical infrastructure have the same interface and simplicity of the cloud.
This is a HUGE area for improvement, and Netris is here to fill this gap.
But moving your cloud-born cloud-native business into your first data center is daunting. You have to buy exotic and strange new equipment, select between networking vendors who are not very well differentiated, and hire some experts to get it all to work together seamlessly. At a certain point you’ll likely realize that cloud networking is only easy in the cloud. The truth is that even with all the virtualization, containerization, and automation in the world, you are still going to have trouble getting the traffic to your application front end. Why does application networking remain so challenging for most businesses?
First, let’s consider that there are three different types of networks:
Internet Egress – Internet Service Providers and Internet Carriers interface with your equipment and forward the packets into your data center or colocation rental. Service providers have gradually improved reliability and performance while driving cost down. You can select from a huge number of providers and buy as much bandwidth and redundancy as you need.
Service Network – Handles inbound traffic from the internet by directing and transforming the traffic
Compute Network – Connect large numbers of servers together. Leaf-Spine Clos fabrics have become the standard in this space, minimizing cost while providing the necessary Layer-2 and Layer-3 transports to support both legacy and next generation applications. These networks also include the virtual overlay networks as well as control plane networking needed for things like Kubernetes. Kubernetes networking is reliable and fairly simple, and if you need additional functionality you can select your own ingress and CNI (Tigera and Isovalent are two fabulous options).
What about the Service Networks? Why is there no detailed description of the solution here?
This is the crux of the problem. The service networks take packets from the internet users and pass them to the application networks. It sounds simple, but it’s not. The service network is responsible for ALL of the following:
|Handle peering with the ISP and carriers that you contract with.||Edge Router|
|For every data packet, find the best route out of the 700,000+ internet routes that represent the global Internet routing table||Edge Router|
|Forward the packets at close to line rate into your network||Edge Router|
|Filter out bad traffic, only allowing the desired traffic types and patterns||Firewall|
|Convert from private IP addresses to public, obscuring the addressing and layout of your network||Firewall|
|Application specific fixups and service offloading (query/cookie sticky routing, SSL offload, etc)||Load Balancer|
|Properly distribute the traffic to the front end application servers, depending on how loaded they currently are||Load Balancer|
This is actually incredibly hard to do on the best days, and it’s made even harder by the rapidly changing application layout, new servers are coming online, new addresses are to be advertised to the internet, and security profiles need to be updated.
What makes it so difficult is that all of these features are provided by different equipment and technology, and those systems do not integrate with each other very well. You end up with this frankenstein-like service chaining model, with each system requiring its own management system and operators. Few people know how to manage all of these devices.
Application requirements and logical design dictate all of the things that are needed from the service layer. Why can’t we just have the applications describe what they need to function and continuously update the service layer with those requirements?
If you run your own cloud or have on-prem Kubernetes pods, you already know most of this. You can expose an external IP address and ports that represent the application endpoint, but how do you actually get the proper traffic to that destination? You have three options:
- Pick up the phone and call your on-staff networking team, open a ticket, and then wait for them to configure all of the devices needed
- Try to do it yourself. Surely this router CLI will be easy to navigate, right? If I type “help” at the command prompt will it activate a configuration wizard?
- Email your consultant and ask them to make the necessary changes, hope that they are free that day and not busy with someone with a larger wallet
That is what Netris is designed to do. Automated Netops is the ability to dynamically and assuredly install the network plumbing based on the application’s own behavior or resource descriptors. Netris directly integrates with the application’s control plane (ex. Kubernetes API), enabling the application to automatically initiate the creation and updating of network policies and services based on a Custom Resource Definition (CRD). These actions can be driven by Netris automatically, or you can require operator input to make the necessary changes.
Netris was designed from the ground up to integrate with modern application hosting environments, and to take care of these routine actions automagically.
We call this new operating model Automatic NetOps.
And Netris does much more than just the services, it is designed to address the entire network stack, including simplified edge routing and an easy workflow for designing and building the compute networks with any design you choose. It is a single tool to create the entire application infrastructure for your on-prem enterprise, branch, edge, colocation, or ISP networks.
Now that I have piqued your interest, I hope you will join me on this exciting journey, it is going to be an amazing ride.
– Josh Saul
Director of Product Marketing