Four Ways to Solve Cloud Integration, for Better or Worse
For enterprises that have gained even a modicum of experience with cloud architectures, it should already be obvious that the term “the cloud” is about as big a misnomer as there is. The reality is that nearly everyone is using multiple clouds at this point, which in many ways leads to the same advantages and disadvantages as today’s convoluted physical infrastructure.
The advantage to the multi-cloud approach, of course, is that it avoids the kind of vendor lock-in that can ultimately restrict deployment options and prevent much-needed capabilities from being implemented in a timely fashion. But as Ciber’s Chafik Taiebennefs noted recently, the presence of multi-cloud architectures is rarely the product of planned enterprise strategy. With business units becoming savvy cloud users in their own rights, many IT shops are dealing with multiple cloud providers simply by accident. And that can potentially lead to a wealth of difficulties when it comes to harnessing cloud infrastructure in a coordinated, and economically efficient, manner.
The most likely solution, of course, is to institute an overarching cloud management platform, which can do wonders to bridge the gaps between multiple cloud providers but at the cost of subjecting yourself to a single-vendor orchestration layer. Cisco, for example, recently introduced the new InterCloud management software stack as part of its One cloud strategy. The idea is to enable data and application workloads to migrate easily from cloud to cloud without having to rewrite security and network policies for each provider. At the same time, the system ties into leading cloud management systems like CSC/ServiceMesh’s Agility Platform, Red Hat CloudForms and even Microsoft System Center and Windows Server in order to maintain familiarity with legacy cloud architectures.
As well, TwinStrata is out with new CloudArray software that enables file access and sharing, as well as bulk migration and ingestion across multi-cloud infrastructures. The system features a number of self-service tools that enable functions like selective volume migration for long-term archiving and flexible policy implementation for network allocation, security features and other aspects. There is also a secure import feature that provides for high-speed transfer of cloud data into encrypted, on-premises cloud infrastructure.
The alternative to these vendor solutions, of course, is to build your own management portfolio, which is not impossible but will require fairly extensive knowledge of the leading management tools. As Rackspace’s Everett Toews points out, these should include Apache jclouds and libcloud, Fog, pkgcloud and others that allow developers to write code that will span leading provider platforms like AWS, DigitalOcean, Google Compute Engine and, of course, Rackspace. At the same time, IT will need to bone up on the proper use of portable APIs so that the toolkit of each new provider that is brought into the mix can be integrated into an overarching, homegrown management stack.
No matter how it’s handled, however, the presence of a multi-cloud architecture is likely to be rife with complexity and resource duplication. The good news is that with virtually all of the key productivity functions existing in software, the ability to manage and manipulate them will be much easier, at least for human operators, who will leave most of the messy stuff to the automation stack.
The care and feeding of the automation/orchestration layer, then, is likely to become a top priority going forward, with the key decision point at the outset being whether you build your own management layer or go with a vendor solution. And if it’s the latter, whose?
