Don’t make your cloud migration a house of cards

If you have a cruddy applications design or overall architecture and relocate it the cloud, you end up with cruddy IT assets that are now in the cloud

I’m often taken aback by the number of mistakes IT made with on-premises traditional systems that it’s now replicating in the cloud. If you have a cruddy applications design or overall architecture and relocate it the cloud, you end up with cruddy IT assets that are now in the cloud.

Fact: The cloud is not an automated change agent for bad IT decisions. Indeed, those bad decisions will typically be amplified in the cloud because you can move faster and so encounter mistakes much sooner—and perhaps more often.

The biggest architectural mistake that I see in the cloud involves coupling. Back in the day, applications were tightly coupled between other applications and data sources. If one thing stopped, the entire system stopped. So if the database went down, all connected applications did as well, including any systems that sent or received data from the database.

Years ago, we learned that tight coupling was bad. It killed resiliency, scalability, and the ability to independently use resources such as applications, databases, and queues. Consultants like me gave presentations on it, and books were published on the topic, but IT organizations are still making the same architectural mistakes in 2018 that diminish the value of cloud computing. IT is not fixing things that are moving to the cloud that need fixing.

At the core of the issue is money. Enterprises do not allocate enough funding to fix these issues before they move to the cloud. I assume the hope is that the issues won’t be noticed, or that the use of a more modern platform will magically fix the issues despite their poor architectures. The truth is that cloud computing is just a platform change.

So, what are enterprises to do? Obviously, I recommend that you fix architecture issues before relocating systems to the cloud. This requires spending up to twice as much before you make the big cloud migration. Typically, this work also fixes the issues in migration.

I understand that these architecture fixes also mean added risk, not just the added costs to migrations that are already at scary levels. But if you don’t take steps to correct issues with your architecture, the cloud improves nothing. Where are the cost savings in that approach?

Related: