Reducing the Risk of Your Cloud Migration

Modern Digital Applications with Lee Atchison

The scheduling of a cloud migration is a complex undertaking that should be thought and planned in advance. Typically, a migration architect is involved and makes the difficult technical decisions of what to migrate when, in concert with the organization management to take into account the business needs.

But it’s important for a migration to be successful that you limit your risk as much as possible during the migration, so that unforeseen problems don’t show up and cause your migration to go sideways, fail, or result in unexpected outages that negatively impact your business.

When scheduling the migration, there are a number of things you should keep in mind to increase the likelihood of a successful migration and reduce the risk of the migration itself. Here are five key methods to reducing the risk of your cloud migration, and hence increase your overall chance for success.

Links and More Information

The following are links mentioned in this episode, and links to related information:

• Modern Digital Applications Website (https://mdacast.com)

• Lee Atchison Articles and Presentations (https://leeatchison.com)

• Architecting for Scale, published by O’Reilly Media (https://architectingforscale.com)

• Advising and Consulting Services by Lee Atchison (https://atchisontechnology.com)

• Course: Building a Cloud Roadmap, 2018-2019 (https://leeatchison.com/classes/building-a-cloud-roadmap/)

Key #1. Limit the complexity of migrating your data

The process of migrating your data from your on-premise datastores to the cloud is, itself, the hardest, most dangerous, and most time-consuming part of your migration. There are many ways to migrate your data…some of the methods are quite complex and some of them are very basic. Some of them result in no need for downtime, others require significant downtime in order to implement.

There is a tradeoff you need to make between the complexity of the migration process and the impact that complexity has on the migration, including the potential need for site downtime. While in some scenarios you must implement a complex data migration scheme to reduce or eliminate downtime and reduce risk along the way, in general I recommend choosing as simple of a data migration scheme as possible given your system constraints and business constraints. The more complex your data migration strategy, the riskier your migration.

By keeping the data migration process as simple as practical given your business constraints, you reduce the overall risk of failure in your migration.

Be aware, though, that you may require a certain level of migration complexity in order to maintain data redundancy and data availability during the migration itself. So the ultimate simplest migration process may not be available to you. Still, it’s important that you select the simplest migration process that achieves your business and technical migration goals.

Key #2. Reduce the duration of the in-progress migration as much as possible.

Put another way, do as much preparation work before you migrate as you can, and then once you start the migration, move as quickly as possible to completing the migration, postponing as much work as possible until after the migration is complete and validated. By doing as much preparation work before the migration as possible and pushing as much cleanup work to after the migration as possible, you reduce the amount of time and complexity of the migration itself. Given that your application is most at risk of a migration related failure during the migration process itself, reducing this in-migration time is critical to reducing your overall risk.

For example, it may be possible to accept a bit lower overall application performance in the short term—during the migration, in order to get to the end of your migration quicker. Then, after the migration is complete, you can do some performance refactorings to improve your overall performance situation. While postponing an important performance improvement is not normally ideal as it increases your technical debt. In this case, the delay may be more beneficial, because it allows the migration itself to complete quicker which reduces your overall migration related risk. Remember, your application is most at risk for something going wrong after the migration starts until the time when the entire application is moved to the cloud and the migration is complete. By postponing this performance improvement work until post-migration, you are able to keep the time of migration to as short a period as possible, hence reducing your risk.

Key #3. Leave yourself as many options to back out a migration step as you can.

The more options you have to revert a step the less risky your migration will be as a whole. As you take each step of the migration, think before you execute the step. Ask yourself how you could back out of the step if something happened that requires you to backoff. Every step you take that can be reversed if a problem occurs, means your risk of executing the step is reduced. If you take a step that cannot be reversed, you are operating under a higher risk.

Key #4. Be conscious of interim performance issues and the impact on system availability.

If you are doing your cloud migration a service at a time…module at a time…or application at a time, there will be long periods when some services, modules, and applications are in the cloud…and some are still on prem.

Be very careful during these interim times. Latency of communications between components that are in the cloud and components that are still on-prem, will be significantly higher than if both components are either in the cloud, or both are on-prem. This means that, during the migration when some components have migrated and some have not, your overall system latency will be different…potentially significantly worse…than it was before the migration or after the migration. This latency may impact the usability of your system, and it may impact the availability of your system, since a significant change in latency between some components could cause unseen defects to become exposed and cause problems.

During the migration, as some components have been moved, your application will act differently…and slower…than it will any other time. Plan for these differences and use these differences in your determination of which modules to move when.

Key #5. Do as much refactoring before you migrate as you possibly can.

While this is a corollary of many of the previous keys, it is important to stress here as well. The more work you can do to prepare your application for the cloud before you move it, the more likely you will succeed in making the migration successful and the quicker the migration will take overall.

…

So, in summary, the five keys to reducing your cloud migration risk are:

• Limit the complexity of data migration.

• Reduce the duration of all in-progress migrations.

• Leave yourself backout options.

• Be conscious of interim performance issues.

• Do as much refactoring before you begin the migration.

Keeping track of these five keys to risk reduction while you create your migration plan will help reduce your overall migration time and…most importantly…reduce the risk of a migration related failure.

Tech Tapas – Services vs Microservices

There is some controversy in the industry about use of the terms service and microservice.

I personally do not like the term “microservice”. Why is that? It’s because the term “microservice” implies a specific sizing of a service that is not necessarily a healthy assumption.

Yes, many services are small, some are truly “micro”, but many are much larger too. The appropriate size for a service is based on context and is subject to many concerns and criteria.

In my mind the use of the term “microservices” biases this discussion. However, I recognize that the term microservice has gained strong popularity in the industry.

There are also people that pigeon hole the use of the term “service” as part of the broader and older category of “SOA” or “Service Oriented Architectures”. They further pigeon hole the term to refer to a particular type of architecture offering that was popular a decade or more ago.

I find these comparisons inaccurate and confusing, and I do not believe the reference is reasonable. This makes “service” sound old an ancient, which is not at all true.

As far as which term to use…

My personal preference is to use the term “service”, but I recognize many people use the term “microservice”. So, I tend to use both terms in my discussions with other companies, depending on context.

In my mind, both the term service and microservice mean the exact same thing.

And as such, I use the two terms interchangeably. When you hear me talk about services, microservices, service architectures, etc. I am referring to the exact same thing.

This podcast uses the following third-party services for analysis:
Chartable - https://chartable.com/privacy
Podtrac - https://analytics.podtrac.com/privacy-policy-gdrp