Cloud Computing is not an infrastructure topic

Much of large enterprise IT tends to separate applications ("change") from operations ("run") departments: applications team run projects to implement functionality while the operations teams focus on running infrastructure, such as compute hardware, storage, and networks. Such a setup not only gives the teams conflicting objectives - run is inclined to minimize change and change is off the hook if something breaks - it also stands in the face of modern approaches like DevOps. On top of all this, it also tends to get in the way when internal IT is inevitably faced with the adoption of cloud services.

Cloud started with infrastructure

Pretty much any corporate IT department has realized by now that cloud computing has placed significant pressure on operating on-premise infrastructure, requiring some re-thinking. Therefore, any self-respecting IT department has embarked on a cloud strategy of sorts by now. Infrastructure teams are often in the lead because cloud providers run data centers and provision servers. That's clearly infrastructure. They are also motivated as they see their existing infrastructure services rapidly being commoditized by public cloud providers.

Cloud is about Time (and Cost) to Value

I believe that considering cloud an infrastructure topic misses the main benefits of cloud computing. Being able to provision compute resources quickly and cheaply in a cloud is certainly useful. However, focusing purely on hardware cost misses the real driver behind cloud computing: minimizing the time in which a normal code change can go into production. Minimizing deployment time accelerates the time to value for the business to compete in Economies of Speed - the currency of the digital world. It is also a key factor for elastic scaling: in order to scale to additional servers, running software has to be deployed to those servers. Rapid deployment requires a fully automated tool chain and cloud-ready applications that scale horizontally. Those are certainly not infrastructure topics but are at the heart of application architecture, tool chain, and DevOps.

"It runs in the cloud" doesn't make the mark

Knowing that the real value lies in quickly deploying and scaling applications also implies that popular statements like "app XYZ can run in the cloud" don't carry much meaning. Most applications running on an operating system from this century will run on a server in the cloud somehow. The objective of cloud strategies therefore should not just be to get existing applications to run in the cloud. Rather, applications should take advantage of running in the cloud, such as scaling horizontally or running in a globally distributed setup. Such ambitions are generally a property of the application architecture and tool chain automation, areas that are quite far away from the infrastructure teams.

Moving Up, then Over

Acknowledging all this, cloud computing providers have gone far beyond providing infrastructure services. A minority of Amazon's 70+ cloud services is related to infrastructure: it comprise databases, content delivery, analytics, PaaS, Serverless frameworks, and more. This is clear sign that the rapid commoditization of infrastructure is swiftly moving up the stack from IaaS to middleware and higher-level run-times. Traditionally, when lower layers of the stack became commoditized, IT moved further up the stack: from physical to virtual to IaaS to Paas, etc. With PaaS and FaaS (Functions-as-a-service aka Serverless aka Amazon Lambda/Google Cloud Functions), there isn't much more room to move up to, though. Instead, stretching the metaphor a bit, IT must look "sideways", at the software development lifecycle and tool chain: getting new features into production quickly is the real currency in the digital world.

Architects need to drive IT transformation. Get a head start with 37 Things One Architect Knows About IT Transformation.

If you appreciate my articles, I'd be grateful if you share them with your network.