Cloud Horizon Models and Changing Responsibility

The cloud can be a somewhat imprecise term. What does it mean to talk about migrating to the cloud or refactoring an application? In order to clear up some of this ambiguity I’ve found it useful to apply Horizon Models to cloud migration efforts. The use of a Horizon Model is to define the states of modernization against a legacy state. The Horizon Model is relatively old as a concept and the timelines typically attached can seem very long by modern standards, but the general concept still applies. Horizon 1 is current state, Horizon 2 is near term destination, and Horizon 3 is the paradigm changing state, as is shown below.

In consideration to the three Horizons shown above, a company needs to determine what they are moving and what happens when it gets there. For instance, if a company is considering Horizon 2 as a migration strategy to exit a datacenter or to facilitate modern deployment for new VMs, there is an operational model associated with it. In a similar way, the Horizon 3 destination of modern applications and data has its own preferred operational model that differs from simply lifting the datacenter and performing an operational model change.

To help, I’ve developed a grid that helps understand the changes as a company migrates to Horizon 2 and then builds Horizon 3 applications. I’ve broken it down into operational responsibility, deployment approach, configuration management, and backup & recovery:

The fundamental shift above is that as an application moves up the maturity curve the design, build, deployment, and operations moves CLOSER to the business or application team, vs. staying with a separate IT organization. This is similar to how other technologies commoditize the repeatable aspects and move toward shifting the capability back to EVERYONE as opposed to a select group.

Nathan Lasnoski