Abstraction is needed in order to let the different teams talk to each other. The application guys don’t want to configure the network and the other way around. Since those are different domains they don’t want the other to be in their domain. This creates a problem, which the devops tools like Chef and Puppet are trying to solve now, by going into the network domain. After all, both the applications and the network are needed in order to deliver these applications as a service to the end user. For convenience we don’t even add the security team to this discussion.
Where these domains interact with each other we need to have some kind of abstraction. Both sides need to decide what kind of services they are going to deliver to the end-user and what kind of information they exchange through an API. Such an example could be a Virtual Machine for developers, which needs to be connected to the network through a VLAN, which is connected to a firewall, which should only allow the developer-subnet and the VM is also connected to a storage-network.
If this situation is part of the pre-defined services, i.e. it is in the ITIL service-catalog, it can be abstracted on both sides and the VM-team can tell the network with a single message what to configure. It might get some information, like an ip-address or something back, and the network, including the firewall and the storage-network will be configured.
Will this change when we move to an SDN? Ideally no, the abstracted API is already there, the exchanged information will not change. It will be easier for the network team though, because the don’t have to deal with multiple CLI’s anymore, but the topology and traffic-engineering will not change.
From my perspective the conclusion is that you need to define your services end-to-end. I know that the definition of a service is not very clear but I define it as multiple building-blocks from multiple domains which together offer an application to one or more end-users. When this service is clearly defined and the building blocks also you split them up in the several management domains and define what kind of information you exchange to identify a unique service in order to change, modify or delete that service.
This is not very different from how things are being done today at a lot of companies, but instead of being a fast API the request goes via a or multiple (printed) form(s) which stretches a provisioning action from minutes to days or sometimes even weeks. SDN is not going to solve anything if we are not going to solve this process. And when that is solved you can question if you still need an SDN.