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%1 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.
For those unfamiliar with Azure Stack, this cloud platform is designed to be an extension (or just another region) of Azure in the private cloud, with identical services, tools, and virtual infrastructure. The value is in the ability to easily transfer workloads across hybrid-cloud environments without the need for application refactoring. Meanwhile, consistency in Azure tools and the portal interface reduces management complexity. As an app owner, you can develop and test an app in Azure, then quickly and seamlessly transition it to Azure Stack for production deployment (or vice versa) while supporting both instances with identical enterprise-grade F5 application services.
Compared to Model 1, this hybrid-cloud model combines the benefits of consistent application services and cloud infrastructure while halving the number of system variables from four to two, greatly enhancing application portability and reducing IT management strain. Unifying both the platforms and application services allows network operators and IT management to view their hybrid-cloud architecture as a single, homogenous entity, rather than two individual monoliths.
Running identically on both platforms, F5’s BIG-IP virtual edition (VE) enhances the parity of Azure/Azure Stack architectures through replication of the supporting application services. Developers can not only develop an app in one environment and relocate it to another, they can mirror entire production-ready stacks, inclusive of all the same BIG-IP configurations, policies, and application services. This eliminates the need for countless hours of application refactoring and testing, and allows developers to get on with what they do best: writing code.
Securing applications and their data is often a concern for developers moving apps to the public cloud—but that need not be the case. A developer can build an app in their Azure Stack environment, while a security architect configures the necessary settings on F5’s web application firewall (WAF). The entire stack can be replicated in Azure with the knowledge that the application will be protected by the same industry-leading WAF. With identical policies and rulesets, there won’t be any security loopholes or vulnerabilities that might otherwise be generated by employing disparate WAFs.
And because Azure Stack supports Azure Resource Manager (ARM), F5’s extensive selection of ARM templates can be used to automate the deployment and configuration of BIG-IP VE instances across both environments, significantly reducing spin up times and enhancing hybrid-cloud efficiency. Ultimately, all of the work F5 has done to achieve such a tight integration with Azure now benefits both Azure, and Azure Stack customers.
There are many reasons an organization may choose to invest in a hybrid-cloud strategy, with just as many ways in which they can implement that strategy. By diversifying and using multiple dissimilar cloud platforms and application service providers, companies make the task of implementing and operating a hybrid-cloud architecture exponentially more challenging.
By Standardizing on F5 advanced application services across cloud environments while leveraging the homogenous nature of Microsoft’s Azure and Azure Stack cloud platforms, IT organizations can create a truly hybrid architecture with complete portability of applications between ecosystems. Supporting applications with the same BIG-IP traffic management and security services allows network and security operators to optimize application availability for end users while safeguarding applications and their data with consistent security features and policies.
And in this relatively early chapter in the tale of cloud computing, many IT organizations are under pressure to make difficult decisions on their long-term cloud strategy—whether it should be entirely in the public cloud, entirely in the private cloud, or a mixture of both. F5 application services for Azure and Azure Stack alleviates the impacts of this decision by creating a holistic solution where an entire application portfolio can be migrated between cloud environments at any time, to adapt to changing business requirements.