The “Factory” Approach to Seamless Cloud Migration
In today's fast-paced business world, the ability to quickly adapt to changes is crucial for success. Cloud migration is a change that businesses are rapidly adopting to stay competitive.
Challenges of Migration: Debunking Myths
30/06/2023
There is a common belief that cloud migration is a challenging process, but there are ways to make it easier or avoid any issues. Experienced companies can provide recommendations that can help avoid common mistakes during the process of moving any IT infrastructure, whether it is a data center or a small application, to the cloud. Sergey Stromilo, Head of Infrastructure and Applications Management, GDC Services. aims to shed light on why you should migrate, how to do it properly, and which services do not even worth the hustle.
However, there are some notable but not crucial disadvantages of the Lift-and-Shift approach that should be considered when planning a migration using this method:
Assessment — gathering information about the current infrastructure and the business applications that are currently in use. Business does not have a goal to move DNS or AD to the cloud, their focus is specifically on business applications and business processes, such as increasing ERP or CRM systems' fault tolerance or availability, or making the approval process more flexible and less time-consuming. Gathering infrastructure data can be done through the CDB or specialized solutions and document analysis. This stage often uncovers artifacts that were previously unaccounted for or overlooked during planning, for example, in the budgets for the initial defense. This helps identify stakeholders and determine who is actually interested in each system within the infrastructure.
After that, it is necessary to plan the Landing Zones, which involve dividing the cloud account into logical partitions. This allows for domain separation within the future cloud ecosystem, and it also entails planning the network topology, including DMZ and LAN configurations. Even in a Lift-and-Shift migration, there may be an extra router, the IP address might change, or another issue may arise. Planning Landing Zones in advance is crucial, since changing them after implementation can affect all components and result in extra work.
Licensing is an often overlooked aspect, particularly in Lift-and-Shift migrations. Many software vendors may have distinct licensing models for on-premises infrastructure and the cloud, which must be taken into account. If licenses are tied to specific hardware or USB keys, special attention is required during the cloud migration, as virtual machines in the cloud frequently move between different hardware, potentially causing licenses to be lost. Most software vendors have adapted their licensing for the cloud, but outdated software versions may require special attention. Additionally, licenses may be tied to specific IP addresses. IP addresses typically change when moving to the cloud (because in the first stages both the old system with the old IP addresses and the new one must work, and also the pool of public IP addresses is different for each cloud provider), so this should also be taken into account in advance.
Data. Data migration should be planned separately, considering not only the information but also the volume of data to be transferred to the cloud over a reasonable timeframe (not in a single moment). If you have a large amount of critical data (such as 50-60 TB), it can't be moved to the cloud in just 8 hours. And if you don't properly plan data migration, consider data consistency, and plan that consistent moment to keep everything up-to-date in your future cloud ecosystem, you run the risk of losing some of the data.
Auxiliary services (monitoring, backup, automation systems, etc.). While planning the migration, It is essential to decide whether migrating these services or utilizing the default tools provided by the cloud provider would be necessary. Sometimes, investing time and effort into using native cloud tools yields better long-term results in terms of support, cost, and service quality compared to carrying legacy systems that may drag you down and hinder progress. It will be our responsibility to update it and the software versions, whereas otherwise, it will be the responsibility of the cloud provider. If the priority is to be able to restore from a backup not only to the current cloud provider's infrastructure, but also to the on-premises or another provider's ones, then using non-embedded cloud tools may be necessary.
When migrating virtual machines, it is important to consider whether to transfer them "as is" using images or to rebuild them from scratch in the cloud. Migrating via images may require converting them to a compatible format and integrating cloud-init. It turns out that it takes a lot of steps, each of which can present challenges or compatibility issues. Another popular approach is using third-party services that perform block-level disk replication and subsequent synchronization until the final switchover. This approach results in minimal downtime and direct copying between the source and target environments (whereas with image migration you have to download and convert the image in some local environment). Nevertheless, there is a disadvantage. Not all operating systems and core versions are supported, and there may be a license fee for each virtual machine migration. Weighing the pros and cons of these two approaches, sometimes leads to the third approach – deploying a virtual machine and system from scratch. Often this option requires less effort than migrating the virtual machine "as is" and finding and fixing compatibility issues.
Modern operating models (DevOps, IaC, SRE, etc.). We recommend utilizing these methods, because when your infrastructure is described as code, the probability of human error is minimized. After migrating the infrastructure, the IaC templates become an important business asset that remains up to date with the latest changes, unlike traditional infrastructure designs.
Migrating to the cloud is not as daunting as it may seem. Take the first steps on your own or with the help of a reliable technology partner with extensive experience in such migrations.
__________________________________________________
Know more about services:
Lift-and-Shift: Pros and Cons
When considering moving any infrastructure, service, or application to the cloud, the Lift-and-Shift approach is often the starting point. The name of the approach explains it all – everything is moved "as is". With its clear advantages, it is easy to explain to the business:- Flexibility and scalability
Migrating to the cloud "as is" enhances flexibility and scalability, allowing you to easily adjust capacity according to your needs. - Cost optimization
At the migration stage you can plan everything in advance, select transferred services, and closely monitor the costs associated with the overall infrastructure and individual services. This can assist with making effective management decisions. - Reduced business risks
You no longer need to worry about monitoring data centers for TIER 3, PCI DSS, and other certifications, or addressing issues such as cooling, disks, or emergency power unit replacement. - Fault tolerance
Cloud ecosystems come equipped with built-in security features, backup mechanisms, and fault-tolerant data centers. - Data security
Cloud providers diligently monitor and adhere to various government standards, etc.
However, there are some notable but not crucial disadvantages of the Lift-and-Shift approach that should be considered when planning a migration using this method:
- Legacy Software Migration
If your software is not initially cloud-based, then opting for the Lift-and-Shift approach may introduce additional costs for service contracts and software support. Moreover, you can lose skilled technicians who may not want to continue working with the outdated technology stack, potentially impacting their competence and value in the labor market. - Double-work
Let's say, you transfer a fault-tolerant database cluster to the cloud "as is". However, the cloud comes with its own built-in tools, such as DBaaS (Database as Service, i.e., managed databases), which already offer built-in features like backup and fault tolerance, while being much easier in terms of performance. This means that you might end up paying more for infrastructure and its maintenance. Alternatively, if you plan eventually to migrate to PaaS solutions, which include DBaaS, you may need to repeat some of the migration work in the future. - Difficulties in automation (DevOps approaches, IaC)
Migrating infrastructure "as is" typically results in technical debt accumulation rather than reduction, which can lead to increased costs of infrastructure ownership.
Migration Planning: Why It Is Important
There will never be 100% cloud-based infrastructure or exclusively on-premises solutions anymore. Now, there are only hybrid solutions that have more features of either. That's why proper planning is important. However, it is vital to avoid migrating for the sake of migration and instead focus on meticulous planning for each step. Effective planning encompasses five key aspects: timing, technology, SLA\RTO\RPO, people, and communication.- Timing
You must clearly understand and schedule migration timing to avoid delaying your tasks for a couple of months. If you set a goal to complete a transformational project in 3 months, but it ends up taking 6 months, it can have a significant impact on your business. Typically, migration duration should account for the planned hours with an additional 30% to 50% buffer. Various factors can influence timing. For example, virtual machines can migrate to the cloud directly (through block-level copying) or you can recreate them in the cloud and configure the applications from scratch. The former is bandwidth-intensive and less parallelizable (for instance, with 300 Mbit/s bandwidth, you can migrate 4-8 virtual machines per day), while the latter allows for easier parallelization but requires additional configuration time. - Technology
At the preparation stage, selecting the appropriate migration scenario is crucial. Options like Lift-and-Shift or alternatives such as refactoring or transformation (e.g., replacing the database server and transitioning from virtual machines to managed counterparts) can be considered. GDC Services experts often handle such projects. Additionally, deciding whether to proceed independently or involve a partner, consulting or a group of partners should be determined during this stage. - SLA\RTO\RPO
These parameters are defined for most on-prem systems. When migrating, they must be evaluated separately, and their value for the cloud environment must be determined. The cloud's SLA is commonly expected to be at least 99.95%. On the one hand, this is true, but on the other hand, the overall SLA of a designed or migrated system relies on the individual SLAs of its components. For example, if a virtual machine has a 99.95% SLA and a database server has a 99.99% SLA, the system's overall SLA will be 99.94%. Increasing the SLA requires additional measures. Regarding data, careful consideration of RTO\RPO is advised, as data loss often has more severe consequences than infrastructure failures. - People and communication
Two interconnected and pivotal aspects. When it comes to migration, it is crucial to identify people responsible for the entire migration project and its success from both a technical and business standpoint, ones who own each specific business application, and to combine them into a communication team. This team ensures transparent decision-making and assigns responsibilities for each stage of the migration process. This will minimize unnecessary communication and prevent statements like "I did not know this," "I did not agree to this," and "this is a surprise to me." Even for small migrations, a well-defined responsibility assignment matrix is essential. Notably, people and communication are even more critical for small migrations. Even if a small migration is carried out, or some part of the service is migrated, the integration with services and infrastructure components that remain on-premises is often overlooked.
Technical aspects
Moving forward with planning, it is essential to break down the process into key organizational steps:- Assessment
- Landing Zones
- Networks
- Licenses
- Data
- Auxiliary Services
- Virtual Machines
- Modern Work Models
Assessment — gathering information about the current infrastructure and the business applications that are currently in use. Business does not have a goal to move DNS or AD to the cloud, their focus is specifically on business applications and business processes, such as increasing ERP or CRM systems' fault tolerance or availability, or making the approval process more flexible and less time-consuming. Gathering infrastructure data can be done through the CDB or specialized solutions and document analysis. This stage often uncovers artifacts that were previously unaccounted for or overlooked during planning, for example, in the budgets for the initial defense. This helps identify stakeholders and determine who is actually interested in each system within the infrastructure.
After that, it is necessary to plan the Landing Zones, which involve dividing the cloud account into logical partitions. This allows for domain separation within the future cloud ecosystem, and it also entails planning the network topology, including DMZ and LAN configurations. Even in a Lift-and-Shift migration, there may be an extra router, the IP address might change, or another issue may arise. Planning Landing Zones in advance is crucial, since changing them after implementation can affect all components and result in extra work.
Licensing is an often overlooked aspect, particularly in Lift-and-Shift migrations. Many software vendors may have distinct licensing models for on-premises infrastructure and the cloud, which must be taken into account. If licenses are tied to specific hardware or USB keys, special attention is required during the cloud migration, as virtual machines in the cloud frequently move between different hardware, potentially causing licenses to be lost. Most software vendors have adapted their licensing for the cloud, but outdated software versions may require special attention. Additionally, licenses may be tied to specific IP addresses. IP addresses typically change when moving to the cloud (because in the first stages both the old system with the old IP addresses and the new one must work, and also the pool of public IP addresses is different for each cloud provider), so this should also be taken into account in advance.
Data. Data migration should be planned separately, considering not only the information but also the volume of data to be transferred to the cloud over a reasonable timeframe (not in a single moment). If you have a large amount of critical data (such as 50-60 TB), it can't be moved to the cloud in just 8 hours. And if you don't properly plan data migration, consider data consistency, and plan that consistent moment to keep everything up-to-date in your future cloud ecosystem, you run the risk of losing some of the data.
Auxiliary services (monitoring, backup, automation systems, etc.). While planning the migration, It is essential to decide whether migrating these services or utilizing the default tools provided by the cloud provider would be necessary. Sometimes, investing time and effort into using native cloud tools yields better long-term results in terms of support, cost, and service quality compared to carrying legacy systems that may drag you down and hinder progress. It will be our responsibility to update it and the software versions, whereas otherwise, it will be the responsibility of the cloud provider. If the priority is to be able to restore from a backup not only to the current cloud provider's infrastructure, but also to the on-premises or another provider's ones, then using non-embedded cloud tools may be necessary.
When migrating virtual machines, it is important to consider whether to transfer them "as is" using images or to rebuild them from scratch in the cloud. Migrating via images may require converting them to a compatible format and integrating cloud-init. It turns out that it takes a lot of steps, each of which can present challenges or compatibility issues. Another popular approach is using third-party services that perform block-level disk replication and subsequent synchronization until the final switchover. This approach results in minimal downtime and direct copying between the source and target environments (whereas with image migration you have to download and convert the image in some local environment). Nevertheless, there is a disadvantage. Not all operating systems and core versions are supported, and there may be a license fee for each virtual machine migration. Weighing the pros and cons of these two approaches, sometimes leads to the third approach – deploying a virtual machine and system from scratch. Often this option requires less effort than migrating the virtual machine "as is" and finding and fixing compatibility issues.
Modern operating models (DevOps, IaC, SRE, etc.). We recommend utilizing these methods, because when your infrastructure is described as code, the probability of human error is minimized. After migrating the infrastructure, the IaC templates become an important business asset that remains up to date with the latest changes, unlike traditional infrastructure designs.
Maximizing Business Benefits from Cloud Infrastructure
We outline six crucial advantages that businesses should consider when deciding to adopt cloud technology.- Rapid hypothesis testing
The cloud enables quick deployment of new ideas, allowing you to test hypotheses without significant expenses. If a hypothesis proves successful, further development can be pursued without additional costs for maintaining a test ecosystem. - Infrastructure as code
It reduces capital investments and minimizes the risk of human error. - Resource monitoring
It is a very important factor. In the process of being used, any infrastructure often accumulates many unnecessary artifacts. When utilizing the cloud, it is important to establish a culture of tracking which task, project, or business value each specific cloud resource is being used for. Assigning a separate business owner for each task responsible for monitoring cloud resource consumption is ideal. This owner should be able to clearly report how much has been consumed, and what value it brings to the company. Implementing this practice will ensure effective budgeting and help you avoid overpaying. - Increased reliability
Clouds are fault-tolerant data centers with built-in backup, antivirus protection, notifications, and monitoring capabilities, which result in increased reliability. - Partial capital investment reduction
You will no longer pay for your own data center. However, it's important to note that most companies use a hybrid format to support their IT infrastructure, leading to noticeable but not significant budget reductions. - Using services instead of servers
Instead of using virtual machines, consider using containers or services, since you're moving to the cloud. For example, databases can be used as a separate service by force of habit, but if your application is compatible with DBaaS, it can save you a lot of time, money, and help avoid stress.
Migrating to the cloud is not as daunting as it may seem. Take the first steps on your own or with the help of a reliable technology partner with extensive experience in such migrations.
__________________________________________________
Know more about services:
