The Top Three Cloud Strategy Misses to Avoid

Multi cloud but not as we know it

Introducing or adding additional cloud vendors is typically used as a form of redundancy. By distributing applications across clouds, the risk of a single vendor outage is mitigated. Often a centralised team assigned to deploying and maintaining applications proceed to "tool up" to be able to adopt and work towards the different cloud vendors which naturally increases the cost - the time, skills required and monetary effects of having to use multiple vendor interfaces. Applications become siloed upon the different clouds, and in the event of service disruption, there will likely be periods when they could become inaccessible for days.

A better approach is a multi cloud strategy that not only involves multiple cloud vendors but can move applications across clouds as and when required. Introducing a cloud management platform that offers a high degree of automation can become invaluable in a robust multi cloud strategy.

Going cloud but not cloud native

Once teams have scaled up and become familiar with the various cloud vendor tooling, legacy deployment processes risk locking up the real value - becoming cloud-native. Cloud-native is used to describe building applications that take full advantage of cloud delivery, not simply running on the cloud. This should permeate throughout the organisation to remove bottlenecks and improve the overall efficiency offered up by the shift to the cloud. A typical bottleneck is the deployment process: multiple teams build their respective applications, often having adopted an agile development methodology in some form, and deliver them to a centralised function that deploys and oversees the running of applications. This is a tried-and-tested legacy approach from having in-house servers, where a limited number of system administrators would typically have the authority to make changes and deploy applications.

While this provides clear accountability and can be easily documented, it also creates specialised knowledge pools which are difficult and costly to scale and maintain. It is also contrary to agile development which should, generally, be more than just a development process and instead look to also deliver applications with incremental improvements at high frequency.

By instead providing self-service tooling to teams to readily and easy deploy applications, they can become more autonomous and can release independently. In turn, this can lead to faster release cycles and allow changes and improvements to reach end-users faster.

A cloud management platform brings together all teams and applications into one centralised dashboard to unify deployments - governance and control while facilitating cloud-native adoption.

Lock-in means being locked out

In early phases of cloud, the lure of avoiding vendor lock-in aimed at an age-old enterprise problem: becoming tied to a piece of legacy software which once adopted, become difficult or near-impossible to migrate from. This was especially true of operating system-specific software that would only be supported on certain versions with hefty license renegotiations to upgrade. Migrating to the cloud offered always-up-to-date versions, running anywhere and allowed for more choice and competition to drive down costs.

Cloud lock-in can come in many forms after the initial onboarding - often using very appealing free startup periods that provide ample time to get set up fully and ultimately committed.

Proprietary settings and configurations that cannot be readily exported and re-used can mean a long and challenging process to re-create on another cloud vendor effectively.

Unexpected costs of difficult data migration and transformation, physically exporting data to be rehoused, can incur unforeseen costs.

Using vendor-specific features and services that use proprietary APIs or technologies with no like-for-like alternatives can make migration away require re-architecting applications.

A cloud management platform can abstract away many of the effects of lock-in and by design, being able to interact with multiple cloud vendors, means a built-in awareness of potential lock-in potholes.

How does a cloud management platform avoid becoming another more centralised lock-in point? Divio's answer is the Flavours initiative, an open-source project aimed at making web applications more portable. Rather than using vendor-specific features and terminology, it describes application settings, configurations and dependencies in a human-readable form that can then interpreted by any service that chooses to implement the Flavours specification.