Transform IT by using the cloud. And then not.

I've been out and about at some shows and conferences recently. I really like attending these things whether as a speaker, stand staff, or attendee. They are always thought provoking in ways that reading literature (even erudite and compellingly written blog posts) are not.

I was in a talk by a guy (I'm not big on details) who had pulled back his infrastructure from the cloud onto some new fancy ultra-dense servers and had seen payback in four months. Although it wasn't the time to try and dissect his ROI modeling, I'm slightly skeptical about the timescale, but not necessarily about the fact that it made economic sense for his business. So what? They probably lost a bit of money by not pulling their services out of the cloud earlier (do we call that raining?). I think they probably gained a lot more from being in the cloud in the first place. When they rebuilt their services internally, you can bet that they won't have built the slow-to provision, static, IT infrastructure we are all trying to evolve away from. They built themselves a scalable, automated cloud-like infrastructure that can flex and scale with them. If they bottleneck in one part of their systems, they can spin up new servers and place them into the working system in minutes. They are using monitoring tools to adapt the infrastructure to the workload. The opportunity cost to them of creating a new infrastructure for a new service is kept low, and DevOps working practices are probably already in place. Many of the benefits of a public cloud, but more cost effective (at least for their business – we know that lots of organizations best ROI is from scalable public cloud).

This got me thinking. Making big changes is a challenge. Turning the supertanker of a large IT organization can be tricky. Sometimes you need an iceberg to align resources around a common goal. Moving services to a public cloud (or virtual private cloud on a public platform) can force the adoption of a more IT-as-a-Service design that embraces automation and enables fast, self-service provisioning. Then, once you have cast your process and design efforts into this new mold, you can in-source your services, if the ROI justifies it. Choose carefully and all you might have to change is some DNS records (I think we have a solution for that somewhere) and the target of your API calls.