Over the past few years, IT infrastructure has evolved considerably toward hybrid and multi-cloud models. And for those who have invested in an OpenStack private cloud, there are various options to prepare that environment for a hybrid or multi-cloud deployment.
Multi-cloud benefits and challenges
While there are still reasons to deploy a private cloud, ranging from security to performance requirements, the use of multiple public clouds has also increased. Multi-cloud computing enables an enterprise to tap into a diverse set of cloud services, regardless of provider. For example, users might choose Google for high-performance computing, Amazon Web Services (AWS) for its broad portfolio of features and Oracle for its database-as-a-service offerings.
But to succeed in a multi-cloud deployment, IT teams must evolve their management practices. First, to move applications between cloud platforms, teams need to carefully orchestrate workloads and translate virtual network configuration files. Tools like Ansible can simplify this process, especially for workloads that need to move between OpenStack and a major public cloud. There are also industry efforts to standardize images for both VMs and containers, which should further simplify this kind of application portability.
Still, because cloud providers have different sets of services and APIs, the onus is on IT teams to ensure their applications are compatible with all the platforms they use. Then, teams should shift their focus to data management to avoid performance bottlenecks in a multi-cloud model.
Manage data for a hybrid, multi-cloud deployment
To prepare OpenStack for a hybrid or multi-cloud model, remember that Swift storage has its own proprietary interface that extends beyond the Amazon Simple Storage Service (S3) REST constructs that most cloud providers use. If you want your applications to use local OpenStack data, it's best to limit your deployment to S3 compatibility to maintain a single REST interface across all clouds, which means Ceph is a better choice than Swift.
Avoid the transfer of whole data sets between the public cloud and an OpenStack private cloud, as that process is both time-consuming and costly. Instead, have a data replica in each cloud platform you use to obviate latency. But remember that some data will need a single master copy, and you'll have to choose where to host that copy.
To further mitigate any storage latency issues, run your OpenStack private cloud in a data center with high-bandwidth fiber links. Recent advances in storage snapshots and continuous backup open up more options. Coupled with replication and erasure coding, it is possible to automatically replicate data to multiple clouds. This is typically asynchronous replication, since, otherwise, write performance takes a big hit. The sync window can be as low as a minute, or even less, which is especially useful for applications, such as data analytics, that require close to real-time data.
You might be able to solve latency and data management issues with a mashup of these approaches, but either way, be sure to address them upfront.
In a hybrid or multi-cloud deployment, there is always the question of which clouds "play best" together. All of the major public cloud providers continue to work to interface with OpenStack but have recently focused their integration efforts elsewhere. Microsoft Azure, for example, is focused on more seamless data movement to and from Azure Stack, its OpenStack competitor, and Windows Server. AWS is likely going to serve up better connections to its partner, VMWare, leaving Google, which works with Red Hat, as the cloud provider focused mainly on OpenStack private and public clouds.
Still, there is little evidence that one public cloud platform is going to become the standard, go-to choice to pair with an OpenStack private cloud. Moving forward, the focus for multi-cloud will be unified management across providers and platforms, but frankly, right now, this still looks to be secondary to accessing cloud services and SaaS applications from different cloud providers, meaning APIs are much more important.