6 min read
The contents of this blog post were originally published on Forbes here.
There continues to be a lot of hype around multi-cloud – the ability to run common workloads across multiple clouds – but not a lot of documented evidence around customers or technologists delivering on that promise. There are many facets to the delivery on the promise of multi-cloud. I'm convinced that everyone's afraid to talk openly about a primary rationale: avoiding cloud lock-in. As human beings, we learn from previous generations. It's called evolution, and in the world of technology, you must evolve quickly or die. However, evolving too quickly in technology can result in the loss of the company and/or employment for chief technology officers (CTOs), chief data officers (CDOs), and chief information officers (CIOs). Evolving too slowly can also shorten your career, though. A senior technology leader doesn't want to end up in a position where the CEO reads about something in an in-flight magazine and goes to the technology leader about it, only to find out that the technology leader has no idea what the CEO is talking about.
There are many challenges with the framework of multi-cloud. There's no way to make Redshift (Amazon's Aurora project) run on Google Cloud or Microsoft Azure (Amazon, Google, and Microsoft are MapR partners). That's by design. Amazon invested a lot of time and effort building and delivering this service with a primary business goal of delivering the landing place for existing Oracle customers as well as becoming a high-profile technology leader and thought leader in the database space. Similarly, Bigtable, with its dependency on an underlying Google File System (GFS), is not going to make an attractive option to attempt to run on Amazon Web Services (AWS) or Azure.
What drives multi-cloud? It depends on the business drivers. Financial institutions, rightfully so, abhor single points of failure (SPOF) and a single cloud provider can be just that. While it doesn't happen very often, in some cases it can cost millions if not tens of millions of dollars for minutes of financial application outages. Eliminating SPOFs is a key decision point. Similarly, compliance and regulatory requirements might drive a multi-cloud strategy – data residency requirements when one of the large cloud providers does not have a local data center can be a significant rationale for considering a multi-cloud solution.
The idea of multi-cloud seems easy as the underlying architectures are quite similar across cloud providers. The automation and upgrade capabilities of those providers may differ, but they all work toward higher and higher availability numbers and service-level agreements (SLAs). The latest example is AWS moving to a 99.999 availability SLA to try and match Google. The reality is that if there is a credit by the cloud provider, a production outage will not come close to covering the financial impact and, longer term, the business reputation. Applications running on one cloud provider make it nearly impossible to run multi-cloud because the application architecture, the security requirements, and the interfaces can be so different and may not be compatible.
The business model for cloud providers is to continue to grow without the challenge of capacity loss. It's the business model that drives the cloud providers to innovate on services and, in doing so, to strive to provide optimized capability, where possible, on their cloud services without regard to technical lock-in or limitations.
How do you, as a customer, combat this challenge? The issue is the data. Cross-cloud execution requires a common data fabric that can run on top of different cloud infrastructures and handle the difficult problems of cross-cloud data replication, availability, consistency, security, and protection.
Consider leveraging companies that support industry-standard, open application programming interfaces (APIs) from leading open source technologies like Hadoop and/or NFS, POSIX, etc. In doing so, experienced CIOs, CTOs, and CDOs will naturally ask questions about data migration, support for different data types, scale, and technical innovations.
Supporting open APIs and industry-leading technologies while preventing lock-in is what MapR is all about. We've taken it a step further and can run some of these capabilities on certain cloud providers even faster than their native services, saving precious cloud dollars. This experience and knowledge will go far in helping to identify the challenges of going with a particular service or cloud provider – no matter who the cloud provider is. For example, the standard open source distribution of Hadoop has an out-of-the-box scale limitation. Similarly, limitations exist for a key component in Kafka: topics. These are not by design, but they are a technologist's reality. We've had to eliminate those limitations to support customers at our scale.
Leveraging the best of all worlds requires careful analysis, selection, and implementation when attempting to deliver data on a single cloud. Complexity increases geometrically when you consider multiple clouds, due in large part to the services required to operate on the selected cloud provider. Simplify that by using providers who can run all of your data on a single platform across any type of cloud (public, private, or hybrid).
Stay ahead of the bleeding edge...get the best of Big Data in your inbox.