Hybrid Cloud Realized: F5, Azure and Azure Stack

In this day and age, many IT departments are pressured by leadership groups to move away from the static nature of traditional in-house data centers to more dynamic, cloud-centric architectures—increasing agility, flexibility, and scalability while reducing operational cost. And because public and private clouds each have their pros and cons, around 71%¹ of businesses implement hybrid models to benefit from more of the pros, while nullifying many of the cons. However, almost all of these organizations do so by employing nonhomogeneous cloud infrastructure and application services, which drastically increases complexity for the cross-functional teams tasked with architecting and maintaining these deployments.

Linking two (or more) distinct cloud environments to fabricate a hybrid-cloud is not only beneficial from an agility, flexibility, and scaling standpoint, it also enables a whole host of specialized use cases that would be much more difficult—or impossible—to implement. Arguably, the most common of these are:

Establishing and maintaining a highly available, geographically redundant backup of a private cloud to prevent downtime of essential applications is very expensive and would likely double the investment required to run a single private cloud. Not only would you need twice as much physical hardware, you’d need a separate data center, with its own power, cooling, and staffing in a geographically separate location.

Alternatively, HA and DR environments can be housed in the public cloud for a fraction of the cost. The application data is stored each time it’s backed up from the private cloud while the actual application and networking resources lie dormant until required, i.e., in the case of a disaster or private cloud failure. If needed, these applications and resources are spun up and operationalized using the stored data, ensuring application availability and business continuity.

Developing a new application in a private cloud can be substantially more expensive than in the public cloud. It requires up-front capital investment to run the workload, ­with no guarantee it will work or be adopted in the current market. For these reasons, companies are following the ‘fail fast, fail cheap’ mantra by using the on-demand capacity of the public cloud to develop, test, and run new apps in production mode. Once deemed operationally sound or seen to be widely adopted by users, apps can be migrated to the private cloud, which may be more secure and operationally cheaper in the long-run. Alternatively, they could stay in the public cloud, deployed in a longer-term, more cost-effective environment, using cheaper reserved instances and the like.

Often considered the most desirable hybrid-cloud capability, cloud bursting is probably the hardest to actually implement, frequently becoming the white whale of many hybrid-cloud strategies. With cloud bursting, an application runs predominantly in the private cloud. When demand exceeds capacity, additional requests are redirected to an exact replica running in the public cloud on rented infrastructure. However, this is a temporary state, designed to handle unexpected traffic spikes which last for short periods of time. Once higher traffic periods become sustained, companies can scale up the capacity of their private cloud.

Configuring a hybrid-cloud environment for cloud bursting is inherently difficult and complex. It requires a synergistic relationship between the two environments, as well as failsafe orchestration to ensure redirection happens autonomously and seamlessly, with little or no impact on the end users experience. The difficulty is further amplified for the teams tasked with configuration and management when the infrastructure, services, and tools used to run and support the applications are different for each environment.

It shouldn’t surprise you to know that not all clouds are alike. Each has its own unique infrastructure, networking and application services, developer tools, user interface, and differentiation over other cloud competitors. For example, it’s much easier for users of Sharepoint, Exchange, SQL Server, or other Microsoft technologies to migrate to Microsoft Azure than it would be for them to relocate to AWS or Google Cloud. These platform and service dissimilarities lead to incompatibilities between clouds and make the task of developing hybrid-cloud environments incredibly challenging.

However, Microsoft has made considerable progress toward supporting hybrid-cloud creation by offering synonymous resources and services across both public and private cloud environments through Azure and Azure Stack, respectively. Azure Stack, which was only recently unveiled, gives users many of the features and benefits of public cloud with the control and security of an in-house data center.

We’ll compare three common, high-level hybrid-cloud models to demonstrate how this new approach, when combined with F5 advanced application services, drastically simplifies hybrid-cloud development and operation.

Model 1 – Nonhomogeneous Cloud Platforms and Application Services

Our first example is a hybrid-cloud environment using Azure with Azure-native application services for the public cloud aspect, while leveraging VMware with F5 application services for the private cloud component, as shown in figure 1.

The distinct lack of consistency across environments makes this the most difficult model to implement and operate. With the HA/DR use case discussed earlier, an application would have to be individually configured to run identically in each cloud. Given the differences in virtual machines, APIs, and underpinning networking resources, this is unlikely to be a straightforward task. These differences contribute to reducing the overall portability of the application due to the complex plumbing required to operationalize the app in each cloud—which effectively doubles the work required to achieve similar results. Furthermore, each platform also has its own unique portal interface and developer/administrator tools, this model quickly becomes prohibitively complicated.

And that’s just considering the differences in platforms. When you add the effect of dissimilar application services, with disparate interfaces, administration tools, and configuration requirements, the complexity grows exponentially. And management dysfunction isn’t the only problem; feature inconsistencies prevent applications from being configured with the same services in each cloud, exposing you to additional risk. For example, dissimilar security services lead to separate firewall rulesets and policies. These can create security loopholes resulting in application down time or loss of customer data as a result of any ensuing cyberattacks.

Model 2 – Nonhomogeneous Cloud Platforms with Homogenous Application Services

This set-up is similar to the one in Model 1, but with each cloud environment supported by F5 application services, as depicted in figure 2.

With consistent application services, all F5 services, configurations, and policies can be replicated across environments with single-pane-of-glass management, reducing the strain on system administrators. Instead of learning and balancing two separate sets of features, interfaces, and terminology - one standardized, feature-rich set of services can be deployed across the hybrid-cloud environment. And these services are cloud agnostic (i.e. they run identically in all clouds), eliminating fears of vendor lock-in that can be associated with using cloud-native services. However, this model doesn’t address the issues associated with disparate platform infrastructure, which will need to be taken into account.

Model 3 – Homogenous Cloud Platforms and Application Services

This final model sees further incremental improvement; taking the configuration described in Model 2, and replacing the VMware private cloud with Microsoft Azure Stack, as illustrated in figure 3.