So, you’re migrating to the cloud as an IT Organization objective, wherever possible.
The goal is to determine which workloads are similar, classify them, and migrate them together as processes, groups, pods, waves, or in some way that makes sense from a business process or IT supporting system perspective.
In an effective, safe, and timely manner.
Or maybe you are down to your last remaining on-premises legacy or monolithic systems and are unclear on where or how to begin or what to do next.
Or maybe you are down to your last remaining on-premises legacy or monolithic systems and are unclear on where or how to begin or what to do next.
In comes the snowflakes…
These are the systems and applications that are ever-so-fragile and yet so vital to day-to-day operations for an organization.
They are the outliers and holdouts that inevitably cause pause, delays, caveats, disclaimers, exceptions, additional considerations, and efforts to the overall cloud journey, strategy, migration, and execution.
No two snowflakes are the same
A snowflake is an application, system, or server that requires special configuration, attention, and precautions beyond that which is covered by normal deployment methods.Each snowflake Is unique in its own way and is typically not fully understood or well documented
In this series of articles, we will explore some key aspects to consider when migrating Legacy and Monolithic systems to the cloud.
We'll take a look at two different approaches that utilize containers, Kubernetes (k8s), and/or Self-Contained Systems at a tactical level to facilitate migration.
With these approaches, we can breathe new cloud capabilities into your Legacy and Monolithic systems without the absolute requirement of:
- A fully operational CI/CD
- A mature DevOps practice
- Application refactoring/modernization
Before we take a closer look at the Legacy or Monolithic system let’s reference some related topics that these articles will assume are understood.
The Six Cloud Migration Strategies (Based on Gartner and Amazon Methodologies)
The six different migration strategies have trade-offs between the level of complexity, project execution time, and associated migration costs.
Choosing the right migration strategy for your Legacy and Monolithic system requires that the trade-offs are deliberately chosen based on the system characteristics and the intended business value to be obtained.
In some cases, you may leverage a rehosting approach if your requirement is cost avoidance and to eliminate the need for a hardware refresh due to a data center lease expiring.
Or, if a longer project timeline is possible you may choose a hybrid approach where you re-host the majority of your application and re-factor once you are running in the cloud.
The same migration strategy for most of your applications will not typically work for your Legacy and Monolithic systems.
It is important to assign specific migration strategies to each application and workload as you go through the Application Discovery phase of your cloud migration strategy.
Once you enter the Cloud Migration Factory phase you will have grouped apps, systems, and workloads with the following attributes defined:
- Business Criticality Level
- Application Complexity Level
- Migration Strategy (based on Application Characteristics and Business Constraints)
Below, we will go over each of the six migration strategies in some detail to define the pros and cons of each approach and their best use cases. The chart below provides a representation of the trade-offs between the level of complexity, project execution time, and associated migration costs.
- Rehost (lift and shift)
- Refactor
- Replatform
- Repurchase
- Retire
- Retain
The 6 Rs of Cloud Migration (Click to expand content..)
RETIRE
Retiring systems and applications that an organization no longer needs is sometimes a valid strategy. During the Application Discovery process, an organization may find applications that are no longer actively used or have limited use. Those types of applications and systems may be viable candidates for retirement and users of those systems (if any) can be provided other alternatives.RETAIN
Some application or workloads are not ideal for a cloud environment. These may include extremely risky applications that have both high business criticality and high complexity due to extreme interdependencies. There are other reasons to retain an in-house system, such as riding out the depreciation value or the cost of migration is too high. Retaining some IT applications and systems on-premise is a popular choice for a hybrid cloud strategy/scenario.REHOST
Rehosting is a popular migration strategy also known as “lift and shift.” It can be a quick solution for migrating to the cloud and moves applications, software, and data to cloud with little effort. The focus is to make as few changes to the underlying system as possible. Usually considered quick-wins as they can be migrated with minimal cost and effort.Rehosting is popular for initial migrations because it involves moving existing physical and virtual servers into an IaaS solution. The IaaS model hosts the infrastructure that is typically found on-premises, such as the servers, storage, and networking hardware and offers a virtualized environment through a hypervisor layer. These applications and systems aren't expected to utilize cloud native features and aren't optimized to run in a cloud environment. Sometimes it may even be more costly to run the newly migrated system in the cloud. Rehosting may lead companies to re-architecting in the future, once a cloud-based operation is active.
REPURCHASE
Repurchasing is the process of switching the legacy application to a new but similar application running in the cloud. An organization may decide to migrate from its legacy financial system to a SaaS-based financial ERP system. SaaS, or software as a service, takes your company’s existing data and applications and runs them in a cloud-based product to help manage operations, such as human resources (HR), customer relationship management (CRM), or content management (CMS).REPLATFORM
Similar to rehosting but requires few changes to the application. Even though this approach closely resembles that of rehosting, it’s categorized differently because it does require some changes. For example, in doing such migrations, an organization may plug its application to a new database system that’s on the cloud or change its web server from a proprietary version such as Weblogic to Apache Tomcat, which is an opensource based web server. Sometimes replatforming can be costly. It tends to be a far better option for companies that cannot restructure their Legacy and Monolithic systems at the time of cloud migration.REFACTOR
Refactoring can require a complete change and reengineering of the system or application logic to fully make use of all the cloud features. After refactoring, applications and systems are fully optimized to utilize cloud native features. The cost and effort of refactoring can be quite high. This approach can be efficient and cost-effective in the long run because the application has been reengineered to make use of cloud native features.A typical example of refactoring is changing a mainframe-based monolithic application from its current form to a microservices-based architecture. The organization should perform a detailed business case analysis to justify the investment of the cost, effort and a potential business impact. Other alternatives should be considered as well. Refactoring is typically the most expensive migration approach and is usually executed after an initial migration via one of the other approaches, like rehosting.
A hybrid approach that leverages containers
At the beginning of this article we mentioned that we will look at two different approaches that utilize containers, Kubernetes (k8s), and/or Self-Contained Systems at a tactical level to facilitate migration.
Our goal is to bring some of the benefits of the cloud to your Legacy and Monolithic systems without refactoring.
Post a Comment