How Cloud Native and Container Platforms Change the Way We Think about Networking

Networking has been a foundational component of our economy since the Internet days. In the early days, defining protocols and standards for how to connect, route, and interoperate local, metro, and wide area networks was critical to the businesses strategy. The computer networking exports with their TCP/IP computer centric view of the stack went head to head with the telecommunications giants and their more traditional telephony driven model of switching, FCAPS (Fault, Configurations, Accounting, Performance, and Security management), and OSI Model. As is often the case in these debates, both sides have good architecture and design principles and in the end, while TCP/IP one the war, very important concepts were adopted into the network model to account for Quality of Service (QoS), traffic engineering, segmentation of network traffic for control and data plane, and hierarchy of the network Simply stated, a flat network with no segmentation or hierarchy from the network stack on the computer though the Internet would cause fault, configuration performance, and security issues. This was understood largely by all in the industry and IT.

TCP/IP Model Versus OSI Model

In the past several years as the need to agility and driving time to market down, there has been a major mind shift that I have noticed in the largest of companies. Networking, with all its complexity in configuration, routing and segmentation, was causing major delays in delivering the true speed and agility required by the business. There have been several attempts to address these using technologies like VPN, NAT, and predefined network blocks per deployment region. These solutions are static in nature and the speed at which technologies mature and innovation happens, these solutions were very limiting. In the industry, we have looked at automating and orchestrating the network parameters with an API and called this Software Defined Networking.  SDN is definitely a step in the right direction; however it geared towards Network Administrators and not business owners or developers. Wikipedia has a good explanation of SDN and this simple diagram:

SDN Overview

While SDN is a great step forward – programmable APIs to the network, this is way too complex for the business owner or developer to program against (not in developer language and not written in a developer model) and most importantly, it does not solve the issues of complexity and ease of configuration in a rapidly changing and software centric world.

As cloud computing use increased in the public cloud, the abstraction of the underlying network became an important driver in adoption. No longer is defining or understanding the network important. As the industry moves to containers, the desire to simply and flatten the network is rapidly becoming the new standard for cloud native and container networking, orchestration, and microservices architecture.

While this may appear to be the right direction to take the least path of resistance, the network matters more today than it ever has before. Why you ask, let’s look at the tradition application architecture.

N-Tiered Application Model

In this model, you have the following build in networking parameters:

◈ Presentation – On Isolated Network with NAT/PAT, firewall, and Logical separation of traffic onto a VLAN that is for just web traffic. The control (routing) traffic is on a separate network from the web (data) traffic

◈ Logic – On a separated network isolated behind a firewall on a separate VLAN than the web traffic. The control (routing) traffic is on a separate network from the application logic (data) traffic

◈ Database – On a separate isolated network behind a firewall on a separate VLAN than the web and application logic traffic. The control (routing) traffic is on a separate network from the database (data) traffic

Now let’s compare this to the cloud native architecture:

Cloud Native Application Model

In this new architecture, all traffic is on a common network with no isolation, no segmentation of control and data traffic, and leveraging the Linux kernel networking stack – which is another blog on why that is a very bad idea if you care about performance and scale. With the move to APIs and Rest interface, there is an added level of very chatty API traffic running over the very same network. All the complexity of the application architecture is handled by the network which makes the network more critical today than ever before.

Now, I’m not saying, it’s all about the network. As with all things in life, balance and focusing on what matters most is the best path to take (although it’s the path less traveled)  What I propose is that the intelligence can be built into the network. I like the analogy that everyone uses for cloud native with Pets versus Cattle. My network analogy is that cattle need isolation, direction, and fences! How can we as an industry move to more agile cloud native architecture and still corral the cattle? The answer comes from looking at this from 2 separate but equally important perspectives.

From a top down (application developer) perspective, the network requirements need to be represented as business intent with constraints that the business understands like latency, priority, security, and performance. If we enable a simple definition that is focused on the application’s business objectives, that will make it easy for the business to define what they care about.

From a bottom up (network administrator) perspective, the network administrators understand how to address business objectives and can easily programmatically define network and network security policies to meet the requirements. This will requires extending SDN capabilities to understand application policy and network specification to be created to support cloud native architectures, but these patterns are well known in the networking world today. The next step will be to use data generated by the application, services, and components to enable analytics to address performance, security, reliability, and latency issues in real or almost real time.