Is cloud migration iterative or waterfall?

Cloud migration projects have two dimensions.

First, they are short-term sprints where a project team migrates a handful of application workloads and data stores to a single or multicloud. They act independently, with little architectural oversite or governance, and last between two to six months. 

Second, is the longer-term architecture including security, governance, management, and monitoring. This may be directed by a cloud business office, the office of the CTO, or a master cloud architect. This set of processes goes on continuously.

Here is the problem. The former seems to overshadow the latter, meaning that we’re moving to the cloud using ad hoc and decoupled sprints, all with little regard for common security and governance layers and any sort of management and monitoring.

The result is something we’ve talked about here before: complexity. Although we built something that seems to work, applications migrated from one platform to another are deployed with different technology stacks. As a result, when they are turned over to operations (cloudops), they are too complex to operate with the current resources. Mistakes are made, systems get breached, or outages become common—all because of iterative migration projects. 

This is not to say that iterative or agile is wrong. It’s not. There needs to be some central command and control, such as a solid reference common architecture that provides the basics: security, governance, data, management/monitoring, and all of the systems that span applications.



Please enter your comment!
Please enter your name here