DevOps with SDN – Critical To Agility
This blog, about DevOps with SDN, continues my “Seven Things That IT Must Do…” series (see list of prior blogs at the bottom of this blog). SDN stands for Software Defined Networking.
When I think about how DevOps with SDN relates to IT Relevance, I’m considering it from two specific vantage points. The first vantage point is around how SDN supports DevOps by allowing developers, cloud admins, site reliability engineers and the tools that are part of the DevOps tool chain; to request or modify network and security services as code. This is part of the Infrastructure as Code (IaC) approach that I discussed in my last blog.
The second vantage point I want to cover is how using SDN can simplify the process of developing and deploying applications across clouds. As more and more application development teams embrace developing and running applications across a multi-cloud or hybrid cloud landscape, the more SDN will need to become a part of the services that IT teams provide to their line of business partners.
DevOps, SDN, IaC
When I originally first conceived of this blog I thought that I would only focus on the role that SDN plays in supporting cross cloud networking. However, after I wrote my last blog around IT becoming developers and IaC, I realized that I needed to step back and first talk about SDN as part of the IaC movement before talking about how SDN supports multi-cloud application development. The ability to specify network and security policies as code when developers are requesting infrastructure is a key aspect of supporting agility in the development process.
Historically, setting up networking and security services for a new application required that the networking and security teams manually reconfigure physical switches, routers, firewalls and load balancers. They might also need to redeploy physical gear to meet the specific network or security requirements of that new application. The advent of SDN changed all of that. The ability to deploy and configure a virtual network dramatically simplifies network and security operations.
It is far easier add or reconfigure network switches, routers, firewalls, and load balancers when they are virtual. SDN technologies like VMware NSX are by their very nature programmable. That means a developer or a developer tool can specify network and security services as code alongside of requests for virtualized compute and storage resources. If your objective is to rapidly provision a complete infrastructure as part of the DevOps process, then you need to virtualize network and security services alongside of virtualized compute and storage.
Jad El-Zein, a colleague of mine, recently did a short video showing how vRealize Automation leverages NSX as code by embedding NSX network and security constructs within blueprints. vRealize Automation uses blueprints to define specific environments that can include everything from a single VM to complex, multi-tier application stacks. The video covers a lot of ground but one thing it shows clearly is how vRealize Automation can leverage the NSX API to provision network and security services alongside of provisioning compute, storage and even application level resources.
In Jad’s video, services are made available on demand from within the vRealize Automation catalog. However, the ability to leverage network and security services as code is not limited to vRealize Automation. Developers, cloud admins, and SREs can use an automation platform like VMware Integrated OpenStack (VIO), or any other number of solutions, to access network and security services provided by NSX. While vRealize Automation is catalog centric when it comes to requesting infrastructure and application services, OpenStack is all about making requests through the API – whether that be through a CLI or through a program that leverages the API.
What matters in both examples, is that virtualized network and security services are made available through an API and that those services are programmable. If you don’t have to make a special, out of band, request for network and security services during the resource provisioning process, then complete infrastructures – infrastructure that contain compute, storage, network, and security components can be provisioned in minutes. If SDN capabilities are not part of your IT teams tool chest, it is going to be much harder to support the kind of velocity that application development teams are looking to achieve by adopting DevOps principles.
SDN and Multi-Cloud Development and Operations
If SDN did nothing more than allow developers and IT pros to treat network and security as code that would be enough. However, there is a second aspect of SDN that will become increasingly important over time. As more and more organizations embrace multi-cloud strategies, the ability to easily move parts of, or even complete applications, across clouds will become a must have requirement. SDN will play a critical role in meeting this need by giving organizations the ability to treat any cloud they use as if it were part of a single enterprise network.
Mark Schweighardt, my colleague working on NSX, in a recent blog highlights some of the challenges organizations face today as they try to address multi-cloud networking and security. Schweighardt points out that the security and operational challenges inherent with using multiple private and public clouds include:
- Inconsistent constructs across cloud providers
- Cloud, region, or virtual network-specific policies that do not scale operationally
- Limited operational visibility into East-West traffic flows
- Operations tools that are specific to each cloud provider
Dan Conde, in a blog he did last year for Network Computing, sums up the macro level problem (and answer) associated with cross cloud networking this way: “Creating a unified network across different clouds has been difficult. There are different IP address ranges for each cloud, independent control planes and management programs, and separately defined policies enforcing security, such as security groups in AWS. By stretching an overlay network across different clouds it is possible to have a unified IP range that runs across a private cloud and AWS [or any public cloud], a centralized UI and a uniform security policy”.
We are still in the early stages of developing cross cloud capabilities that address every scenario that an enterprise might face as it relates to integrating private and public clouds into a single network plane. Mark’s blog does a good job highlighting where NSX stands today as it relates to the development of these capabilities. But rest assured that cross cloud networking and security capabilities will continue to expand rapidly to support enterprise strategies for multi-cloud or hybrid cloud use.
Summing Up
SDN plays a critical role in supporting enterprises as they seek ever increasing levels of speed and agility. It also offers tremendous operational efficiencies. It is at the heart of the Infrastructure as Code movement and it is also a critical capability organizations will need as they look to execute on multi-cloud strategies for building and running new or refactored applications. If SDN isn’t something your IT team is looking at yet you should look at it soon. It definitely is a “must do” item for IT teams looking to retain or regain relevance with their line of business partners.
The Blog Series Recap
- IT Teams Need To Finally Implement Self-Service Automation
- Marketing Internal IT to Line-of-Business
- IT As Developer Of Infrastructure As Code
Learn More
- Visit VMware vRealize product page
- Visit VMware Integrated OpenStack product page
- Try our Automate IT Hands-on Labs
- Try our Intelligent Operations Hands-on Labs
