Network Automation and Orchestration with Openstack and Cloudify

In my previous post I discussed the evolution of networking in the cloud - from commodity hardware to the cloud, and the need for the virtualization of network functions, and the different drivers for change.  In this post I will focus on orchestrating your networking through OpenStack’s Neutron, its challenges and potential.

Bringing the Network and Applications Together

So, as I mentioned in my previous post, when OpenStack introduced its networking API, known as Neutron, this provided a new way to set up networking services and configurations such as routers, subnets, floating IPs, security groups, and more through a simple API.  Until now we used to think of network configuration and application deployments as two separate things. This also goes back to the way most of our IT is structured.  We have different groups for networking operations and for applications’ operations and in most cases they have a fairly loose interface between one another.

As with DevOps once we open our infrastructure layers through APIs we can break those traditional boundaries between networking and apps. In a networking context, this means being able to create and configure our network as part of the application deployment.  To understand what this really means, let’s examine what the typical steps that we need to follow to set up networking for our application.

Typical Network Configuration:

1. Set up admin network for our application monitoring and control services
2. Set up application network to allow internet access to the relevant machines
3. Set up the security group per application tier (open only the ports and IPs relevant for that tier)
4. Set up floating IPs where needed
5. Set up a load balancer and configure it to route traffic to our web containers

Adding Continuous Availability

There are a set of additional network configuration steps that needs to be considered when we think of high availability.

Such steps often include:

1. Partitioning our services into separate availability zones and regions
2. Setting up connectivity between the availability zones and regions (which often run on separate networks)
3. Switching back and forth between each availability zone in case of a failure

Orchestrating and Automating  Network Configurations as a Part of Application Deployment

Today most of the steps required to set up our network are often done manually and externally to our applications. Now that we have API access, and our networking is basically software-driven, we can automate this entire process.  As many of those steps tie in more directly to our application services, we need to include them with our application deployment.

Network Orchestration Through a Simple Blueprint

With an orchestrator, users can define their own gateways, routers, and security groups through simple software configuration files, or blueprints, that are written in a language that the orchestrator (software operator) can understand.

With the latest Cloudify 2.7 release we added the ability for users to set up their network configuration as part of their application deployment blueprint. This allows users to set up security groups, separate networks, isolate the management network from the application’s network, define whether a certain piece of your application will run in the same availability zone or not, control if the storage will be close to the application geographically (i.e. the affinity rule).  Read about Network Automation to see how such a blueprint should look.

Final words

Bringing the application and networking together provides an easy way for users to capture the value of newly available network capabilities without having to become a network operator themselves. This significantly simplifies the complexities involved with exposing networking elements to the user by abstracting the networking piece of our deployment into an application blueprint.

In addition, the fact that we can setup our network configuration as part of our application deployment allows us to harden our security to match our application topology exactly . For example, we can choose to open only the necessary nodes to internet access, setup security groups dynamically to match the ports and IP addresses that are allowed to access our service and other such customizations. In this way, setting up an application and its network configuration is infinitely simplified for an application developer.