Software-defined network (SDN) technologies have created the opportunity to simplify the way we approach the network and how it supports applications. But most companies that have acquired SDN technologies still look at the network in a way that retains its original point of view and, as a result, its original complexity. The resurgence of container management platforms has created the opportunity to manage the network from the point of view of the application, and to finally take advantage of SDN technologies to truly simplify application deployment.

One of the problems that SDN companies attempted to tackle is the issue of firewall rule explosion. Firewall access control lists (ACLs) are notoriously difficult to understand and process. For example, a customer I worked with at a former company had 50,000 firewall rules on a single firewall device and they did not know if they could remove any one rule without breaking an application! Load balancers have similar problems as firewalls. With hundreds of applications, come thousands of rules that must reside in a single hardware load balancer. Clearly, there is a problem.

One way to attempt to solve this problem is to create network application centricity. There are many network IT vendors that claim application-centric infrastructure and networking. Their view of the problem looks like a network administrator creating an application network flow by adding network objects such as firewalls, load balancers, filters, packet inspectors around an application running in a set of VMs.

The diagram above illustrates how one networking company views the creation of an application. You start outside, go to a firewall, then through a load balancer (LB), then to an app (some VMs), and then through another filter to a database (DB). At each set, a service is inserted into the network flow. Each of those services then needs to be programed and maintained. By using SDN techniques to solve this problem, you get flexibility, but you still have the complexity of the network objects themselves. This complexity, implemented with hardware for each of those network objects is translated into a very difficult-to-manage and expensive system.

Other SDN companies have tried to solve this problem by replacing hardware devices with virtual machines (VMs). In this case, you end up with a VM running an application behind another VM running software firewall or a specialized packet analyzer. You then have to go to the network VM to create rules that relate to the firewall (e.g. open a hole for port 80, accept HTTP protocol, then 443, 4016 for a DB, then maybe 8080). This solves some problems, but also creates new ones – you now have more VMs in the network, and you have to link them together.

The virtualization revolution simplified system deployment but added a plethora of OS endpoints to the network. More VMs mean more IPs, more routes, more subnets, and more network complexity. It also increased the amount of east-west traffic, and generated the requirements for SDN tunneling and network isolation for application segments. It created more costs as new vendors entered the segment to solve the problems created by virtual machines.

What if you could stop thinking of the application’s needs in terms of network objects?

If you place the application in an application platform, specifically a platform that is managing containers instead of VMs, then you can begin to think of the application’s networking requirements from the point of view of the application.

Start with an application running in a container and define a name that will allow you to reach that application— let’s call that name the “route” to the application.

In the above diagram, you have two very simple objects, which are easily understood by an application owner and an administrator. The platform can now implicitly insert every network object needed by the application.

By applying policy-based network controls directly to the application, you can easily scale the application up or down, and the network objects will be added or removed automatically.

This model extends easily as you add more complex objects – like a database – to the model:

This simple structure is in fact a very sophisticated network topology. When an application platform manages the network object under the platform the software firewalls, filters, and load balancers all can be magically inserted into the network flow without having to consult the network administrator. Add a database and automatically get a filter.

This type of implicit network manipulation is becoming commonplace with container management platforms. These platforms are using SDN techniques to wire containers together along with firewalls, load balancers, filters, service discovery, and many other network functions. When done through policy, the platforms hide network complexity and create objects that application programmers can manipulate and exploit for ease of deployment, development, and operational simplicity. Containers + SDN + platform-as-a-serivice (PaaS) create a new paradigm for applications.