Application-driven versus Feature-driven orchestration

#SDAS #devops #ACI #CLUS

One of the challenges in scaling modern data centers rises directly from an increase in network complexity over the past few years. We can argue why complexity has increased, but it's reasonable to say that scaling data centers means more boxes - more servers, more network gear, more middle boxes - and every device (or service) you add increases the complexity of the topology and thus the operational overhead to manage it. Organizations agree - things are somewhat or substantially getting more complex.

.

 

 

 

 

 

 

 

 

 

 

 

 

Software-defined architectures attempt to answer this challenge (among several others) by operationalizing the network. By using APIs to orchestrate provisioning processes and enable the integration necessary to make use of actionable monitoring data generated by various systems across the data center, software-defined architectures accelerate application deployments and reduce risk by eliminating a source of error - manual configuration.

Now, you might think that's where it all ends. But it doesn't. Because the way in which an API is presented and used to enable automation and orchestration can actually introduce the very same complexity that it attempts to address in the first place.

There are basically two ways to approach provisioning and orchestration: application-driven or feature-driven.

Feature-Driven Orchestration

Feature-driven orchestration is so named because the granularity of the API is, basically, at a feature (or capability) level. What that means is that the API exposes individual configuration options and automation systems must invoke each one (often in the right order) to achieve the desired result.

Something like a simple load balancing service is simple only from the perspective of execution, not configuration. A load balancing service requires a virtual IP address (the end point to which clients connect), a pool of resources (each with their own IP addresses and potentially VLAN membership), an algorithm and any associated thresholds and metrics that may be required and health monitors to ensure compliance with availability and performance expectations.

You can imagine that, if the number of applications being load balanced by this service is large enough, that the number of repetitive steps required to configure the service will become as unwieldy as a manual configuration.

The same is true of other application services typically provided by the network, such as those concerned with performance, security and access. Each has a unique set of "steps" that must be performed in the right order to provision a service.

Feature-driven orchestration requires the provisioning engine (or orchestration system) to drive each and every step. That adds complexity to an already complex process, because you really are just tossing a thin veneer of "automation" over an existing method of configuration. Feature-driven orchestration is pretty much manual configuration (line by line) driven by a script. Instead of worrying about fat-fingering a parameter, now you have to worry about catching fifteen or twenty different exceptions and status results and handling them properly from a script.

Application-Driven Orchestration

Application-driven orchestration, on the other hand, takes advantage of constructs like service templates and policies to enable a less complex method of integration with provisioning and orchestration systems.

Rather than focus on encapsulating commands into API calls as is the case with feature-driven orchestration, application-driven orchestration focuses on aggregating only the data necessary to execute a provisioning workflow. This data is encoded in a policy or template and handed over to the service to be acted upon. The service takes the policy or template and manages the provisioning process internally, ensuring that the expected order of operations is followed and eliminating the need for operators to handle exceptions and corner cases and special status codes themselves.

Application-driven orchestration offers a safer and more efficient approach to provisioning.

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

An application-driven orchestration approach not only accelerates application deployment and maintains a lower risk profile but it also enables application migration across disparate environments.

Configuring a service in one environment, driven by a specific provisioning or orchestration engine, is a very specific task. Moving the application and the service to, say,a cloud environment would mean duplicating that same effort again with another provisioning or orchestration engine.

An application-driven approach that leverages templates and policies, on the other hand, can make it possible to migrate an application without incurring the cost and time associated with the repetitive integration work required by feature-driven orchestration. The policy or template can migrate with the application and easily be used to provision the same services - with the same characteristics - in the cloud environment, without incurring a whole lot of time or effort.

 

APis are a good thing. They're a key enabler of software-defined architectures like SDDC, cloud and SDN. But API-enabling infrastructure doesn't necessarily mean only on a checkbox and radio-button basis. That can be valuable but it can also lead to integration efforts that are just as complex (or more so) than their manual counterparts. A template or policy-based (application-driven) approach  coupled with an API through which to deliver and execute such constructs results in a much cleaner, more consistent and stable means of integrating provisioning processes into the greater software-defined architecture.