Welcome!

Java Authors: Pat Romanski, Liz McMillan, Jackie Kahle, Stephen Boyer, Tad Anderson

Related Topics: DevOps Journal, Java, SOA & WOA, Virtualization, Cloud Expo, SDN Journal

DevOps Journal: Blog Feed Post

Application-Driven vs Feature-Driven Orchestration

One of the challenges in scaling modern data centers rises directly from an increase in network complexity

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.

changes in ntework complexity

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.

feature-driven-integrationThe 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.

application-driven-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.

Read the original blog entry...

More Stories By Lori MacVittie

Lori MacVittie is responsible for education and evangelism of application services available across F5’s entire product suite. Her role includes authorship of technical materials and participation in a number of community-based forums and industry standards organizations, among other efforts. MacVittie has extensive programming experience as an application architect, as well as network and systems development and administration expertise. Prior to joining F5, MacVittie was an award-winning Senior Technology Editor at Network Computing Magazine, where she conducted product research and evaluation focused on integration with application and network architectures, and authored articles on a variety of topics aimed at IT professionals. Her most recent area of focus included SOA-related products and architectures. She holds a B.S. in Information and Computing Science from the University of Wisconsin at Green Bay, and an M.S. in Computer Science from Nova Southeastern University.