Cloud Neutrality: 5 Things Every CIO Should Plan for When Moving to Cloud

As an Enterprise Architect and Solutions Consultant of a commercial multi-model database company, I frequently have to demonstrate the value of commercial vs. open-source software licensing. Some CIOs, having dealt with large relational database vendors’ unpleasant sales and auditing tactics, have become fearful of using commercial software due to the assumption that it causes vendor lock-in. Therefore, I like to make the distinction between commercial software vs. proprietary storage formats, APIs, and languages.

Those same concerns are even more valid for the cloud. By now, the economic benefits of moving to the cloud are well understood. But an often overlooked consideration is, once you are in the cloud, what if you want to switch cloud providers or bring all or parts of your system back in-house?

Successful planning to move to the cloud is not just about getting data into the cloud, it’s about how you get it out. Below are five important considerations to make to assure cloud neutrality.

1. Multicloud Architecture

For true independence from day one, consider running your primary with one cloud vendor, disaster recovery (DR) with another, and use a third vendor for development. In particular, I recommend AWS because they are the largest vendor at this time. You will have access to more SaaS applications and data that interoperate with AWS than other vendors. If you are already a Microsoft customer, run on Azure. Even if you are not, consider Azure for the value of the Azure stack. If you run primary and DR across different providers, flip the primary and DR provider at least once per quarter. This is the same concept as running across HP/Dell/SuperMicro platforms, Cisco/Juniper/HP, SAP/WorkDay/SFDC, etc. It will be a lot less effort and more reward to run 10 projects across a dual cloud than 6 on one and 4 on the other.

Tip: Build cloud arbitrage into your enterprise architecture approach.

Tip: If you do this, my other recommendations are moot. If you don’t do this, operationalizing the others will be problematic.

2. End of Service Scenarios With Cloud Providers

During a recent meeting, someone told me a story about a cloud vendor relationship gone sour. The vendor was required to return their customers data, but the format wasn’t specified in the service agreement. Did the customer ever get its data back? Yes, via a dump truck full of printed paper at the front door of their office. At another meeting, we heard of a similar situation in which the cloud vendor told the customer that they wouldn’t export the data for the customer as the customer already had access to their data through the cloud-provided front-end application. While technically the customer could access their data, getting it out would require several man-months. The customer now had to weigh the option of suing the cloud vendor to get a data extract versus manually extracting it, likely by purchasing a screen scraper tool to automate clicking through the application, one record at a time, to get back their data.

Tip: Ensure there is a clear clause in your contract stating the specific format, transfer mechanism, and timeframe to be used to return your data.

Tip: Design your cloud-hosted capabilities with the expectation that data and associated metadata, entities, and privileges are application independent.

3. Independent Access Control of Your Data

If access control of your data is independent of your cloud provider, it helps in many ways. Not only might you avoid scenarios like above, but it just simplifies the process of switching system integrators, cloud vendors, or subcontractors. External access control in conjunction with encryption also means that when you move data, it can remain encrypted and safe.

Tip: Maintaining direct access to the back-end database and web services that support your data will improve your future deployment flexibility.

Tip: Building your own custom applications and using a cloud provider primarily for infrastructure services can also help you maintain ownership and control of your data.

Tip: Build your access controls on policies and not on anything that is environment specific. Get role names from a Directory, use a parsable policy, and don’t use code in the cloud to drive access.

4. Independent Third-Party Tools & SLAs

Ensure you use the best tool for a task, instead of relying on a cloud vendor’s tools alone, especially when it comes to data governance or data quality. If you make an access control change and it takes three days to take effect, would this be easy to determine using a cloud vendor’s auditing tool alone? Cloud vendors are not incentivized to audit possible inefficiencies, nor are they incentivized to do de-duplication or pruning of their data. External audit logs under independent control, secure and encrypted, and centrally accessible, should be considered. Taking this even further, SLAs should really be vendor neutral too.

Tip: Ensure you have independent tools to monitor your data and SLA metrics. Consider storing records of access logs and SLA metrics in a secure, external database.

5. Cloud Neutral Technologies

Circling back to the vendor lock-in discussion at the beginning of this post, some things to look for in choosing cloud-neutral technologies – the actual software that will run in the cloud. Many software license agreements are specific to where it runs: cloud, iron or virtual. You want to make sure you have a fluid agreement so the software runs where you want it. Additionally, your software should be able to:

• Run in any cloud or across a variety of cloud vendors at once, as well as on-premise
• Support multiple data storage formats and industry standards
• Replicate data easily across environments
• Offer its own independent security (access control independent of a cloud vendor)
• Have a proven success record for data center migrations, administration changes, with zero downtime

Tip: Also consider data logic and rules portability issues. For example, JSON might move easily between database storage vendors, but JSON pathing is completely different in each vendor’s technology. However, XPath is a standard and portable between vendors.

Tip: Whether proprietary or open source, software must allow CIOs the agility they need to do what is best for their businesses.

The promise of the cloud is to allow users the convenience of storing and running applications from anywhere. Much has been said about the ease of moving to the cloud. However, once it is there it is frequently difficult to leave. As long as your cloud applications are developed to be cloud neutral up front, you use software that allows your storage formats, APIs, and languages to easily moved, you will succeed.

These five considerations should help you design for cloud arbitrage up front and save you time and money in the future.

More Information

On prem, virtualized or in the cloud. Your business should dictate where your data lives, not the limitations of your database. Find out why MarkLogic does it best.

MarkLogic and Amazon Web Services To help you get going in the cloud quickly, MarkLogic provides Amazon Partner Amazon Machine Images (AMIs) and Cloud Formation templates. The templates, which build on the AMIs, can be used to construct MarkLogic Managed Clusters.

MarkLogic on Azure Find out how partnering with Microsoft team will help you deploy MarkLogic clusters on Azure cloud quickly.