One of the biggest mistakes I see when enterprise customers contemplate a move to the cloud, is that they assume their entire system and architecture will move “as is” into any cloud provider. While this may even be feasible in feature rich cloud platforms, the question is, should I move as is? The reality is that loads of enterprise systems in play today, look they way they do because of a phenomenon called “architecture by evolution”. Nothing is as permanent in IT as the “temporary” fix put in place to overcome a short term issue. Over time, more things get added, and these “bandaids” become part of your platform architecture. The result is that over time, it becomes plenty messy. I have yet to see a customer with a sqeaky clean, crisp architecture…it seems an almost impossible goal to achieve.
As a result of the above, it is best to start fresh when you move systems into cloud platforms. Not only will you achieve the benefits of cloud computing solutions far easier, but starting fresh eliminates all of the issues you had to fix previously. Cloud computing is a big catalyst for change, and you have to be prepared to accept that. Recently I met an enterprise customer still running a pretty key MS-DOS based system. They quickly critised us for not being able to cater for this app in our platform. When I asked the question if there is an updated version of the system available, the answer was “yes, but what we have is stable”. Now looking at a technology adoption bell curve, this is certainly a situation where this MS-DOS based app falls in the laggard category. For me, it would have been better to change the platform to a more modern version.
Here’s the financial impact that the customer is not seeing. By not migrating the application (and thus saving the migration cost), they lose out on the benefits of cost, scalability and speed of deployment that they would have realized from a cloud platform. Incidently, the customer runs this application in an environment where they have certain peak times during the month, such as month ends and weekends. By leveraging the elasticity enabled by a more modern application and elastic cloud scaled resources, they could have run enough resources to operate the app during normal hours. During times of peak load they could then have dynamically scaled the application to take advantage of the elasticity in cloud resources. From a cost point of view the saving is significant, as they only incur costs for the resources they use, when they use them in the cloud model. With their existing model, they have enough hardware and datacentre power and cooling run the app during peak times, even if the bulk of the infrastructure idles during off peak times. During off-peak time they generate heat, consume power etc that could have been saved. Not only is there a saving due to the elasticity of cloud resources, but also an operational cost saving. The complete financial cost, operational efficiency and system upgrade cost has to be compared. It could be that upgrading the old system, while it comes at a cost, suddenly enables other savings that enable a great retun on the investment.
Moving to the cloud makes the old saying “measure twice and cut once” seem like a sensible plan.