Operational expense has an enemy: orchestration!

Orchestration is key to achieving reduced time-to-value. What is this "time to value"? In technology speak, its the measurement of time for a system or resource to be made available to its intended audience. This system might generate revenue, improve productivity, or simply support other, related systems. Whichever it is, the sooner its deployed and operational the quicker its value can be realized. Reducing time-to-value has measurable impact. However, it is not always easy.

Organizations have many a process in place for protecting data, preserving application experience, and increasing resilience against failure. It is the implementation of technologies and services responsible for managing and adhering to such process that impedes faster time to value. They require installation, configuration, patching, integration with logging and authorization systems, and much more. Consequently, many organizations are still hindered by 90-plus day deployment times, or worse.

Why aren’t organizations deploying orchestration systems to remove these deployment delays? Because, programmatically educating the orchestrators in every feature and configuration permutation of all the different vendor systems it must deploy and manage is simply not feasible. It would take years to achieve, assuming no new features or functions were added to any of the technologies involved.

It is for this very reason that we have so many specialized orchestrators, today. Orchestrators for virtualization, orchestrators for networking equipment, orchestrators for platform management, and it often seems each vendor requires its own orchestrator to ensure all their functionality is made available. So, who’s going to run all the orchestrators? From that perspective, orchestration seems an impossible task! Well, impossible without management and configuration abstraction. 

For technologies and services to participate in orchestration they must be able to present an abstraction of their capabilities. Thus, eliminating the orchestrators extensive feature adoption-curve, but they must do so without a reduction in capability or loss of functionality. F5 has presented such a means for simplifying the way it interacts with orchestration systems, while preserving the rich functionality delivered by its application services platform, F5’s BIG-IP.

Using iApps, F5’s application services templates, only simple interaction is exposed to an orchestrator. Application architects and appropriately skilled engineers retain granular control over the iApps and exactly what application services will be configured and how they operate while the orchestrator require only to implement the iApp by providing a much smaller subset of information.

Operational expense has a weakness! Through application services templates, F5 has developed a highly configurable abstraction point that is ripe for orchestration and integration with 3rd party systems while maintaining the application architect’s desired app services policy. Security, application experience, and service resilience are preserved. Achieved through an inversion of responsibility, abstracting the complexity from the orchestrator, automated deployment workflows are a reality.

For detailed information and deployment guides, take a look at the latest Application Services Integration iApp on GitHub, here. This particular iApp was developed for the machine-to-machine communication required for enterprise data center orchestrators. Whether its right for you or not, anyone can create iApps or, using the example above as a starting point, tune it their own environment.

For slightly less detailed information than the aforementioned example, take a look at my colleague’s recent post on F5 programmability: https://www.linkedin.com/pulse/introduction-automation-f5-carl-brothers