- You can use automation without software-defined networking (SDN), but you cannot use SDN without automation.
- Many enterprises will gain enough benefits from automation and may not need to migrate to SDN.
The answer, of course, is whatever option works for you is the one that’s best, but that is a little too facile, so let’s dig in a bit. Automating operations such as scripting configuration changes and responding to events has enormous value for any IT department. When I actually worked in a data center, my rule of thumb was: if I did something more than three times in a month, I’d automate it, including the little atomic actions such as changing the syslog entries on a switch which could take as many as five to seven command line entries. Automation saved me hours, perhaps days, per month executing configuration changes (and even more because I had far fewer errors).
SDN is another thing altogether. With SDN, the network is simply an abstract series of connections between the nodes such as servers, load balancers, and firewalls that make up an application, and that abstraction can be displayed like a chain, a mesh, a ring, or whatever makes sense. The physical network topology connecting those nodes may in actuality be an N-tier hierarchy, leaf-spine, or a single tier, but that does not matter (much) to the SDN topology, which is largely independent of the physical one. Defining that topology is done via software and the controller automates element configuration.
You can use automation without SDN, but you cannot use SDN without automation.
For example: Automation can be used to handle the details of configuring the network itself while orchestration automates IT changes across multiple systems such as servers, storage, and networking, making sure prerequisites are met before moving on. You cannot automatically attach a storage volume over iSCSI without first having the network connection established to the NAS. At a very basic level, OpenStack Neutron offers orchestration but not SDN, because it is only configuring individual network elements according to a script. I believe that most IT environments can go a long way with just automation, because it is one of those types of processes that you can start small and grow as needed. Before you know it, you will have automation running throughout your data center… but the design of the network is still very much driven by the physical topology and the constraints of Ethernet.
A software-defined network exposes its APIs to other systems so that they can automate it, but determines how the connections will be made based on what the orchestration system requests. For example, rather than OpenStack talking directly to switches, it tells a controller it needs connectivity between VMs on a set of hypervisors and the SDN controller makes the connections, provisions the ports and necessary network services, and then hands it back to OpenStack. If your data center requirements dictate a highly dynamic and versatile network that breaks the constraints of Ethernet, such as defining arbitrary paths through the network on demand, SDN is for you.
Many enterprises could gain enough benefits from automation alone and may not need to migrate to SDN, though doing so does provide several advantages in the form of more granular and flexible network control. However, there are hard capital and operational costs associated with SDN not found in an automated network, such as: the increasing cost of acquiring SDN software licenses; a long, shallow learning curve; complicating traffic monitoring and troubleshooting; an increasing dependence on integration; and application development challenges that you need to factor into the equation.