Service Chaining is Business Process Orchestration in the Network
#SDN #NFV #devops #interop Service chaining allows the network to grow up and really participate in business processes
The term "service chaining" hasn't quite yet made it into the mainstream IT vernacular. It's current viewed as a technical mechanism for directing packets ,flows or messages (depending on where you sit in the network stack) around the network. Service chaining is the answer to "how do orchestrate the flow of data across the great divide that exists between L2-3 and L4-7"? There are already multiple implementations, some that take advantage of virtual overlay protocols like VXLAN and NVGRE, others that use proprietary tags, and some that even operate at layer 7 and take advantage of HTTP's natural redirection capabilities to move data from one service to another.
What's important is not only the mechanism (a variety of IETF proposals already exist discussing this) but recognizing that what we're really trying to do is orchestrate a business process across application and network services.
The one thing SDN and NFV have been unable to do is break the belief that the network is just a pipe and the services hosted in the network are just packet pushing variations on a theme. To many, "network services" still means "a VLAN" or "QoS policies" or "bandwidth limitations". Even higher order stack services like load balancing and application acceleration are viewed not as services but as discrete network functions. This fails to recognize what a "service" is in the context of infrastructure and emerging technologies like SDN, cloud and NFV, which in turn keeps their relationship to business processes from becoming readily apparent.
Service providers are likely closer to recognizing that technologies like service chaining are as much about orchestrating a business process as they are how to direct traffic around a network. Consider a few of the more common "value added services (VAS)" offered by service providers to both application providers and subscribers (consumers) alike.
Consider, now, that these services are applied only in the case when they are appropriate to the subscriber (and one hopes that traffic). If I have not subscribed to the "parental controls" service, my data should not be wasting cycles by being processed by said service. This is true for all VAS in a service provider's network - cycles wasted on processing is wasted money.
So there must be a way for operators to designate the appropriate "chain of services" through which a given subscriber's traffic should flow based on whether or not they are customers of that service (i.e. they've paid for it). That's a business problem and a business process being orchestrated, not a technical exercise in determining out which port a packet should be tossed.
In the enterprise, there are similar services that must be orchestrated as part of a larger process. As applications decompose into APIs and micro-services, the need to orchestrate application flows across services becomes imperative. But this is not just about the applications, but also the application and network services that are part of those flows; those processes.
There are a variety of application services that live in the network and application infrastructure that are part of larger, orchestrated processes. Not every response to a consumer request needs authentication, nor does every response or request need to be examined by the fraud system.
What determines the need to evaluate, analyze or further process inbound or outbound traffic in both data centers and service provider networks is a business process. The ability to orchestrate the network and application services based on that business process is in part what emerging technologies like SDN and NFV are offering.
We can call it flexibility or agility or some other "ity" if you like or even start saying "policy-driven" again, but the reality is that technologies that enable orchestration of services do so in order to implement a business process - whether that's across applications or networks or both.
Thus, service chaining is likely to be a critical and foundational technology, as it answers the question of "how are we going to orchestrate in the network" to enable and support the orchestration of the business processes that run the business and impact the bottom line.
Service chaining is business process orchestration in the network. The organizations that figure this out and use it to their advantage will have, well, a significant advantage.