ra2 studio - Fotolia
Hybrid cloud adoption is on the rise. Organizations see the advantages of cloud services, but they also want to afford themselves flexibility and keep some workloads and data under local control.
Despite all the fuss, the "true" definition of a hybrid cloud hasn't always been clear to IT -- particularly because of cloud washing. Hybrid cloud is an IT deployment model that uses a mix of on-premises (private) cloud and third-party (public) cloud services with orchestration between the two platforms.
MarketsandMarkets estimated that hybrid cloud spending will grow 22.5% annually through 2021 to reach almost $92 billion. IDC said spending on traditional on-premises IT infrastructure will remain larger than cloud spending over the next two years. Although, in aggregate, IDC expected that 32% of IT infrastructure budgets will go to external clouds and almost 11% to private cloud. Hybrid is the preferred model among cloud users; a popular 2016 survey from RightScale showed that 71% of cloud users operate a hybrid environment.
A hybrid cloud design is useful in several enterprise IT scenarios. However, the use will partially determine what works and what doesn't. Admins need to learn hybrid cloud best practices so that they can recognize -- and then avoid -- the mistakes and common oversights that have plagued previous cloud implementations.
A popular hybrid cloud deployment practice is to use public cloud services as a disaster recovery (DR) or business continuity (BC) data center for a private cloud. The designs are largely the same, with one primary difference: For BC, the public cloud is always active, while for DR, it's on standby and activated only during an outage. In either situation, the entire infrastructure required to run affected applications must be deployed -- or preconfigured and ready to be spun up -- on both private and public clouds.
A more advanced and complex hybrid design involves splitting application functions across clouds. In this case, some components -- often data stores and authentication or authorization directories -- run in a private cloud. Other components -- such as web front ends, middleware business logic and distributed big data analytics engines (Hadoop, Spark, etc.) -- run on the public cloud.
Such bifurcated designs promise IT the best of both worlds; they feature the tight control over data and user security of private infrastructure combined with the dynamic scalability of public cloud services. This design, however, brings an added difficulty to hybrid cloud management: decoupling data and compute in legacy systems. This means split architectures are best used with new, not legacy, applications.
There are several ways to build hybrid cloud infrastructure that don't always include on-premises systems. Large organizations may prefer to maintain substantial capacity in modern, privately operated data centers. This way, they can connect to public clouds using virtual private networks over the internet or via private WANs that use cloud cross-connections such as Amazon Web Services (AWS) Direct Connect or Microsoft's Azure ExpressRoute. Smaller organizations increasingly run private clouds in a colocation facility or with a managed service provider. The obvious benefit is to offload data center capital expense and management overhead.
Colo facilities have superior network connectivity to carriers and cloud services, which makes it easier and cheaper to build high-speed private connections to the public cloud of choice. Indeed, the importance of fast and reliable low-latency connections between private and public cloud infrastructure in a hybrid architecture cannot be overemphasized.
Hybrid design decisions
An organization must make several important decisions while it plans a hybrid cloud adoption. Assess whether to split and migrate existing apps or only new ones designed for hybrid environments. Legacy applications that can run entirely on virtual infrastructure are good candidates for a hybrid DR/BC design. However, only greenfield systems should try to disaggregate functionality within an application across public and private clouds (e.g., compute on public and data on private). Services such as Azure Site Recovery automate the process of on-site VM inventory, VM image and data replication, and service deployment. This greatly simplifies the use of Azure as a hybrid cloud DR/BC site. Indeed, using the cloud for DR is one of the most common hybrid practices and a good stepping stone to more advanced cloud usage.
When building new apps, decide whether to use low-level infrastructure as a service (IaaS) or more abstracted platform as a service (PaaS). PaaS options such as Azure App Service and Google App Engine make it easier to consume advanced cloud services such as managed databases, big data analytics, machine learning, load balancers and content delivery networks. While IaaS is the logical choice to move legacy, client-server applications to the cloud, it means developers must proactively choose to use native cloud services such as managed SQL databases (e.g., AWS Aurora or Google Cloud SQL) or container runtimes (e.g., AWS Elastic Compute Cloud Container Service or Azure Container Service). PaaS platforms such as Azure App Service, Google App Engine or one of the Cloud Foundry providers -- such as IBM Bluemix -- relieve developers from concerns about runtime infrastructure choices; this allows developers to focus on business logic and database design. Although the use of PaaS increases the risk of cloud provider lock-in, it's a beneficial tradeoff. It reduces costs because it simplifies the development process, improves performance and eliminates overprovisioned VM and storage services.
You should also consider how to handle cloud billing. This largely means deciding before your hybrid cloud adoption whether to use granular, usage-based chargeback for private infrastructure -- and whether to finely allocate public cloud charges by project -- or to roll hybrid cloud deployment into department or business-unit budgets.
Finally, decide how to integrate public cloud usage monitoring into legacy IT billing systems and feed the aforementioned chargeback model. Public clouds provide a variety of powerful monitoring services, such as AWS CloudWatch and Google Stackdriver. However, legacy billing systems must incorporate and process the resulting data to allocate expenses.
Mistakes to avoid
Hybrid cloud adoption can be an organization's first attempt to incorporate public cloud into IT services. That leaves the organization vulnerable to several mistakes that befall most cloud novices. Avoiding these mistakes before your hybrid cloud deployment will save your business grief later on.
Don't forget to complete a service-level agreement (SLA). Cloud buyers must understand enough of the provider's operational details to know whether the service can meet performance, availability and data-protection requirements. An SLA will also help buyers understand and establish roles and responsibilities, available performance and usage metrics, security practices, and enforcement consequences for non-compliance. Buyers should also understand the basics of a provider's storage architecture, which can include the following: measures taken to protect against accidental data loss; options for geographic diversity of storage instances and databases; retention policies for provider-collected data, such as its internal infrastructure metrics; and options to migrate both customer data and provider-collected measurements to another cloud service or internal data center.
Don't inadequately vet potential cloud providers. Although the cloud acts as an information utility, it's not a commodity, and cloud services aren't all the same. Some, such as Azure, have a large portfolio of Windows-based services with tight integration to the entire Microsoft system management and application development ecosystem. Others, such as IBM SoftLayer, Oracle Cloud and Rackspace, offer bare-metal services that can be dynamically instantiated and scaled like a VM -- but with highly predictable performance and greater control over configuration and security details. Some, such as Azure and Google Cloud, provide tight integration between IaaS and PaaS services. This gives developers the ease of working with PaaS as well as the option to use lower-level infrastructure services when needed. Hybrid cloud buyers should clearly identify their needs and study the alternatives before signing up.
Don't start too large. It's far better to build hybrid cloud expertise with small, short-term projects. Project management 101 says you don't start a new, complex endeavor by trying to boil the whole ocean. Hybrid cloud management is no different. Buyers should identify modest hybrid projects that can be completed in weeks and thus provide a low-risk means to develop cloud expertise, identify needed IT process changes and prepare staff for new responsibilities.
Don't fail to redefine IT roles and responsibilities to reflect changed duties when using cloud services. You will also need to retrain staff on newly required cloud skills.
Don't inadequately estimate cloud costs or improperly monitor usage. Such practices can easily lead to overspending.
Don't create an incomplete DR design that doesn't account for and protect all infrastructure and data components.
Don't fail to translate and subsequently migrate existing security policies to cloud infrastructure. The use of cloud services changes how security policies are implemented, and security holes and new vulnerabilities can develop if not addressed during cloud migration.
Don't inadequately automate cloud infrastructure and over-rely on manual processes. Cloud services can quickly mushroom and create management bottlenecks. However, as software-defined elements, cloud services are programmable, which allows routine tasks to be automated for speed and consistency.
Hybrid cloud management tools and their IT functions
Key considerations for partners building a hybrid cloud
Fending off hybrid cloud nightmares with access control