Why SDN (or something like it) was Inevitable: Service Velocity

#Agile #Devops #SDN All three core IT groups must align with similar approaches to succeed - and we aren't done yet.

Once upon a time, there was a movement in IT called "agile". Developers adopted it in response to complaints from the business that they needed applications, that applications were everything, that without new applications the business would surely dry up. Dev then began tossing code over the wall faster and more frequently.

At some point, the operations folks responsible for herding these applications and application updates through the road to production decided that if they were going to keep up with development, they needed a new approach.

Enter devops. Operations version of agile as applied to deployment processes. Where app dev focuses on continuous development, operations tries to match their velocity with continuous deployment. 

You can see where this is going, right?

Exactly. The next (hopefully last but perhaps only penultimate) obstacle is the network. It is not yet agile, nor has it fully embraced the notion it needs to be. But it does, because network service velocity is currently a growing issue for organizations, because it is vastly slower than app dev and operations rate of execution.

Thus, SDN (or something like it) was inevitable. Interestingly enough, InformationWeek's most recent SDN survey showed overwhelmingly that improving service velocity - "a more efficient and flexible network that speeds service delivery" - is used to justify investments in SDN by 76% of respondents.

That may because app dev and devops are already running at full tilt but the network? Not so much.

Something had to change, and given that service velocity is significantly impeded today by the network, it just makes sense that it was going to have to change to accommodate the rest of the IT organization.

How SDN Addresses Service Velocity. Or Doesn't As the Case May Be.

If you consider the five key characteristics defined by the ONF as being core to SDN  you'll find that all of them directly or indirectly (by enabling other technologies) address this need for service velocity. 

ONF Characteristic	Address Need for Service Velocity by
Directly programmable	Enabling automation
Agile	Improving responsiveness of netops
Centrally managed	Reduces complexity of the network, which can impede provisioning of services
Open standards-based and vendor-neutral	Can reduce complexity by ensuring consistency of interfaces used for automation and provisioning
Programmatically configured	Assists in automation

SOURCE: Open Networking Foundation

Unfortunately, the classical SDN architecture as defined by ONF (and used by most people as the common definition) is very focused on service velocity of layer 2-3 forwarding functions and some layer 4 services, but not very good at improving service velocity rates for higher order services.

Service Chaining on the Horizon

The reality that SDN's network focus (L2-3) does not adequately address the challenges posed by application layer services (L7) meant some other approach was necessary to complete the full "network" implied by the "N" in SDN. That some other approach appears to be service chaining.

Use Case	Purpose	Benefit
Service Insertion (or Service Chaining)	To create dynamic chains of L4-7 services on a per tenant basis to accommodate self-service L4-7 service selection or policy-based L4-7 (e.g. turning on DDoS protection in response to attacks, self-service firewall, IPS services in hosting environments, DPI in mobile WAN environments)	Provisioning times reduced from weeks to minutes, improved agility and self-service allows for new revenue and service opportunities with substantially lower costs to service

From SDNCentral "SDN Use Cases"

There are already a variety of approaches bubbling to the surface with respect to how best to implement service chaining in conjunction with (and sometimes separately from) SDN architectures.

In general, however, the concept is fairly simple. Applications have a need for application services that operate at L4-7. A reactive SDN architecture is not well-suited to dealing with the requirements to operate said services. Service chaining assumes that all L2-3 traffic routing and switching is managed by the SDN controller, and when an application has need of these services, the SDN controller will ensure that traffic is forwarded to the appropriate service(s), chaining them (in a manner similar to orchestration) if there are more than one that need to be invoked. Some proposals suggest using a new protocol that "tags" (yes, much like VXLAN and NVGRE tag packets for routing purposes) packets and flows in order to enforce execution order, others suggest using policy, others still simply hard coding the order of invocation.

Regardless of the implementation details, the concept of service chaining remains fairly close no matter who is proposing the solution. Rather than coding the "next hop" in each application service, it's software defined so that it can be programmatically and dynamically, if necessary, modified to fit the application.

The good news is that Service Chaining in theory appears to address service velocity needs for application services. Which means in conjunction with an SDN implementation, service chaining provides a full network stack that is software-defined and improves service velocity to match that of the network group's app dev and devops counterparts.

Which is what we need to happen to prevent dev and ops from viewing the provisioning of application services in the network in the same light as booking a cruise with Odysseus.

.