One of the unintended consequences of cloud is the operational inconsistency it introduces. That inconsistency is introduced because cloud commoditizes the infrastructure we're used to having control over and visibility into. everything from the core network to the application services upon which business and operations relies to ensure performance, availability and security are often times obscured behind simplified services whose policies and configurations cannot be reconciled with those we maintain on-premise.
You do not provision resources or deploy apps the same way in the cloud as you do in the data center. In fact, it's unlikely you'll provision resources or deploy apps the same way in cloud A as you do in cloud B. And even if you implement a private cloud, the way you provision resources and deploys apps will almost certainly be different than how you do it in the cloud.
Which leaves the question of just how do you really operationalize that?
In many cases, this isn't going to change. Organizations will not be able to reconcile core network services necessarily obscured behind the abstraction that is cloud with networking policies in place on-premise.
But for those services exhibiting more affinity with - and therefore more influence over and impact on - applications, organizations do have a choice. The same on-premise services can generally be deployed in the cloud and therefore are able to be provisioned, managed and, therefore, governed by the same policies as are their on-premise counterparts. By ensuring a consistent service abstraction layer through the use of a standardized platform, organizations are given the opportunity to operationalize those services in a way that maintains consistent application security, performance and availability policies.
The key is ensuring that the services can be deployed in the cloud and that there exist a management and orchestration solution capable of providing control over those services whether they're in the cloud or in the data center, on-premise.
This is exactly what our intelligent Orchestration System, BIG-IQ, provides within F5 Synthesis.
Operationalizing a Hybrid World
Operationalizing in a hybrid world requires the same level of programmability as is required to operationalize the network. Additionally, however, it requires the ability to extend its reach into the cloud by connecting to those environments through cloud APIs designed to allow the remote provisioning and management of resources. Because those resources are essentially virtual machines through which F5 Software Defined Application Services (SDAS) can be delivered, BIG-IQ can reach out, to the cloud, and provision and manage SDAS in a hybrid world.
This means operationalization is near. BIG-IQ provides a centralized command and control center through which provisioning and management of application services can be automated and orchestrated. Common tasks such as deployment, auto-scaling and configuration changes are managed through the same system whether deployed in the data center or in the cloud.
This means consistent of policy, of management, and reporting. It means an efficient, operationalized deployment of applications in a hybrid environment, enabling the same ease of deployment whether in the data center or in the cloud.
The bulk of the services required in the cloud are going to be those which display the most affinity with applications; in other words, application services like identity and access control, performance, availability, security and mobility. All SDAS, all available through the same, common platform, BIG-IP, in the cloud and in the data center.
But what about ...
All those other services you've got deployed that aren't delivered via F5 Synthesis or the BIG-IP platform? To operationalize those requires either a solution similar to BIG-IQ. Assuming you have such a system, and it, like BIG-IQ is enabled with an API designed to facilitate integration and automation, then you can operationalize deployment by orchestrating a process inclusive of both solutions, each provisioning and managing their respective services. The key in this case is to ensure that you can deploy, provision and manage services in the same way in all environments that comprise your hybrid world.
Lacking a solution similar to BIG-IQ, if the service platform is API-enabled, you can script up an automated solution, though this option requires far more intimate knowledge of both the service platform's API and the cloud provider's API, as deployment, provisioning and management will have to be able to do so through the cloud provider's API while using the service platform's API. This is no trivial task, and why it's generally suggested that a management platform be used whenever possible to reduce the complexity and risk associated with developing scripts to recreate.
You'll note the common theme, here, is architectural parity. While it is not unpossible (yes, that is too a word) to develop a custom system which interprets a declarative policy representative of operational and corporate policies regarding security, performance and availability, and then uses the appropriate programmatic methods of the services and clouds to implement, like the custom integration path, this is quite an undertaking. This is a model similar to that of OpenStack. The issue with OpenStack is its currently limited support for services (only the most basic application service (yes, that is singular) is available today) and cloud providers.
In a nutshell, to operationalize a hybrid world you're going to have to either code and integrate yourself, or take a good hard look at your service delivery strategy to determine whether or not the various pieces of its comprising infrastructure fit into your vision of a hybridized world. It may be a good time to re-evaluate what platforms and products you're using to deliver what services with an eye toward how well they are able to support operationalization of a hybrid world.