Enterprise Cloud Strategy Part 1 - The 5 R's

Microsoft has released the 2nd edition of it's Enterprise Cloud Strategy book, and it has a ton of good content for companies looking to make the jump to cloud.  The beauty of this type of book is that it really is "cloud agnostic".  While specific examples and references are made to the Azure platform, you can use the concepts in here to plan your cloud strategy regardless of the target cloud.

I wanted to do a book review on this book, but I quickly realized that it would be a large undertaking.  There is so many core concepts discussed in this book and it would be hard to capture all of it in one post.  I've decided to write a short series on different aspects covered and my thoughts/experiences in dealing with clients in these specific areas.

Part 1, this post, will chat about the 5 R's of modernization.

When enterprises are making the move to the cloud, there is generally a business reason to do so.  The business derives values from the applications that IT hosts/maintains/builds for them, and therefore, a lot of cloud migration discussion focus on how to get applications "to the cloud".  We are not all fortunate to work with green-field cloud apps, and the 5 R's represent a set of actions one could take to migrate their apps.

The first one is retire.  This is an often overlooked option when reviewing applications for a cloud migration.  Simply put, there is always an option to mark an application for retirement and not consider it for a cloud migration.  Start working with the business to decommission the application and determine a best fit for areas of capability that are still required.

The second option is to replace.  From experience, I find that very few companies are interested in the replace option as a first step, but it is important to consider as part of the process.  With the pace of technological innovation, especially in the SaaS space, there is a good chance that the legacy application in scope might have an acceptable alternative in the marketplace.  I always suggest a short period where business SMEs and a cloud architect investigate options in the field.  One important note is that this is generally only viable when the application is non-differentiating.  Applications that act as the 'secret sauce' that separate your client from it's competition are generally not good for a pre-canned SaaS app.  Another con to this approach is integration.  Chaining SaaS applications together to deliver business value can be a difficult task.

The third option is to retain, wrap, and expand.  When considering this option, one must understand why we are moving the particular application to the cloud.  Retain/Wrap strategies are good when changes cannot be made to the application.  In my experience, I have rarely seen legacy applications written to be able to accommodate such a pattern.  Data replication patterns seem to be a best fit here, allowing you to isolate the application (and then move it) while still making the data accessible to other downstream systems.  Generally this method is used to save costs, so one must understand the ingress/egress and storage costs associated.

Expanding an application is a interesting one.  One use case I have seen is the idea of batched operation, particular for simulations.  Cloud services can be used to provide on-demand capacity to existing processes.  Many Azure batch functions work with existing HPC techniques and toolsets.

The next option is to rehost.  I always think of this as one of the "boring" approaches to cloud migrations.  In most cases, you can mimic your existing environment in the cloud, and simply move the hosting of the application there.  One thing that is often overlooked in this approach is the cost of integration with downstream systems, security systems, etc.  I've rarely found an isolated application (of value) that did not involve some degree of conversation around integration when this approach is used.  Further, integration methods that work great on-premises could have large latency/bandwidth considerations in the cloud.

The last option is reenvision.  Many companies without large development teams in-house tend to shy away from this approach.  Others have their development teams engaged in new features and not available to completely redesign the application.  While this approach may seem daunting, it often can be justified from a cost perspective.  The development time spent not only allows a legacy system to better meet the current business requirements, a modern architecture can help the application better scale/integrate/etc, allowing for easier enhancements into the future. 

In conclusion, there are pros/cons to every approach from a cloud migration perspective.  One must really understand the main business drivers for the overall cloud strategy as well as the particular application before choosing a suitable method.  Cost/Time/Resource concerns all play in to picking a successful migration strategy.