The central focus of DevOps has been the continuous delivery (CD) pipeline: A single, traceable path for any new or updated version of software to move through lower environments to a higher environment using automated promotion. However, in my recent experience, DevOps is also serving as the bridge between the “expectations chasm” — the gap between the three personas in the above diagram.

Each persona (CIO, Ops and App Teams) have varying expectations for the move to public cloud. For CIO, the motivation to move to the public cloud is based on key selling points — dealing with capacity constraints, mounting on-premises data center costs, reducing the Time to Value (TtV), and increasing innovation. The Ops Team is expecting a tooling maturity on par with on-premises including Capacity Planning, HA, compliance and monitoring. The Apps team is expecting to use the languages, tools, and CI process that they are already using, but in the context of new PaaS services. They also expect the same level of compliance and resilience from the underlying infrastructure services.

Unfortunately, as we will see in a moment, these expectations are hard to meet, despite the rapid innovation and cadence of releases in the cloud.

Consider these examples:

We will start with expectation mismatch from the perspective of the Apps Team. While Azure API Management is a useful service with many capabilities, the only option for CI is GitHub. Similarly, App Teams expect to minimize the refactoring needed to their existing applications when moving to PaaS. PaaS like “Cloud Services” Web Role provide that, but at the same time require customization to the Guest OS to meet all the compliance needs like installing certificates, instrumentation agents and proxy settings.

Ops teams face a similar dilemma. They expect that Azure capabilities like VNETs will inter-operate with their on-premises tools for DHCP, DNS and IP Management. Similarly, Ops will want to take snapshots of virtual machine images, something that their on-premises hypervisors allowed them to do easily.

I believe that the above “expectations chasm” is here to stay for two reasons. 1) The pace of innovation in the cloud means that new services are being introduced at a clip where it is hard for the tooling to keep up, and 2)  Cloud providers thrive in homogeneity (need I bring up “Pets vs Cattle” analogy?) and at the same time, there are just too many on-premises variants to support.

This is where sprinkling just a little bit of DevOps pixie dust can help. Dev and Ops teams, in the true spirit of DevOps can help bridge each of the examples mentioned above. Whether it is a small Azure CLI script to deploy the API Management policies stored in VSTS, or a PowerShell script that executes when a Cloud Service instance is starting up and customizes the Guest OS. Likewise, a script that takes Azure Blog storage level snapshots or an API that integrates VNETs with an on-premises IP management tool.

In my experience, bridging these gaps is an important role for DevOps – a role that can make the difference between success and failure in the cloud.