Migrating to the Public Cloud
Migration to the cloud means moving data, applications, and even the entire infrastructure from an on-premises site to a virtual environment that is used by multiple clients on demand. This public cloud is responsible for computing, storing and delivering network services at scale.
Why are businesses migrating to the cloud?
Here are three simple reasons why businesses are starting to migrate to the cloud:
Reason 1: Speed and cost savings
With cloud computing, you can scale your business to fit your needs, and with the right management, you can handle any spike in load and save money while keeping your consumption low.
Reason 2: New features such as disaster recovery
If your enterprise's business is global, the cost and complexity of managing end-to-end disaster recovery for on-premises data centers will skyrocket. It is possible to reduce costs by using high-quality cloud infrastructures in a centralized manner.
Reason 3: Continuously updated new technologies and services
Just look at any of the major cloud providers and you will see that they are constantly developing new technologies and services to help customers deliver services. Offers include the most trending solutions, from faster servers to machine learning systems in the cloud.
Why migrate to the cloud? Let's consider in more detail
Regardless of the industry, almost every company is now forced to turn into a technology, and even rather an IT company. Businesses are becoming increasingly IT-dependent. However, in this new role, IT is no longer just supported, but part of the product. Manufactured by factories.
If you are limited to local servers, you are likely to lose in comparison with competitors in scalability and prospects in the horizon of 5-10 years. By contrast, migrating to the cloud offers additional competitive advantages such as speed, scalability, and cost savings.
Rather than continuing to invest in aging and expensive infrastructure that keeps pace with change, moving to the cloud is a choice for the future. In addition to being able to economize and scale IT, you are essentially laying the foundation to respond faster to market changes, grow and drive innovation over the long term.
When planning a cloud migration, understanding how to accomplish it depends on your individual business model and goals, as well as your current infrastructure and applications. You need to rely on the skills and experience of your IT teams to understand the ins and outs of the current environment and the interdependencies of your applications. This will help determine which applications should be migrated to the cloud and how.
What specific business goals should you look out for?
Data Privacy and Compliance Needs: Should Governments or Healthcare Requirements Require Privacy?
Vendor dependency: want to "put all your eggs in one basket"?
Cost: time / money. How long will it actually take to migrate data in response to your company's changing skills and culture?
What else needs to be considered when migrating?
Cloud Migration - Moving, Platform Change, Revision, Rebuild, and Replacement is a great starting point for considering all options for migrating applications to the cloud.
Whether it's the initial migration or the fifth iteration, a successful cloud journey requires strategy and planning. Here's what you need to know.
Number 1: Move
Rehosting is the process of migrating existing physical and virtual servers to the public cloud (Infrastructure as a Service (IaaS)) as is (as is). The main advantage of this approach is that systems can be quickly moved without changing their architecture. Companies often follow this path at the very beginning of their work with cloud technologies. When you move, you essentially treat the cloud-like just another data centre, which means you are not getting the most out of the cloud services available.
Let's take a web application as a simple example. Imagine you have an ASP.NET application running on Windows, and you want to move it to the cloud. You can create a Windows VM that meets the size requirements and deploy the application. After changing the DNS records, you are almost ready to go. This migration is an easy way to move to the cloud. However, this solution is not highly available or scalable and requires you to configure OS updates.
Number 2: Platform Change
It is the process of launching applications on a managed set of services from your cloud provider, also called platform as a service (PaaS). Using PaaS means that developers can reuse frameworks, languages, and containers.
For applications or workloads that can be refactored in the cloud, you can take advantage of some of the cloud features to lower costs and increase scalability. However, the biggest disadvantages of this option are portability risks, lack of functionality, and framework binding. One of the common problems faced by developers is that many PaaS options use irregular data storage. This usually requires a change to the codebase to use cloud storage rather than the local file system for the saved files.
An example of refactoring using PaaS would be taking an existing Ruby on Rails application and deploying it to Heroku, or taking an existing Drupal application and modifying it to run on Acquia Cloud or Pantheon. PaaS options allow you to focus on your application without having to deal with the underlying operating system.
Number 3: Revision
Some applications will need to be modified more seriously to move them to the cloud. Some will require functionality to be added, while others may need to be completely rebuilt before they can be reinstalled or redone and ultimately deployed to the cloud.
This can be difficult as modifying a large array of code to make it cloud-based can be time consuming and costly. An example is to take a complex, monolithic Python-based application and move it to the cloud infrastructure. The design of your application will dictate the amount of changes you need. You may find yourself needing to split it into multiple applications and swap components such as message queues to get the most out of the move.
Number 4: Rebuild
In this scenario, the application is reworked, the original coding is discarded, and it is rebuilt based on the PaaS infrastructure. Reworking the app allows you to take advantage of the more advanced capabilities of your cloud provider to create an even better app. The main disadvantage of this option is vendor binding.
For example, if for a number of reasons cooperation does not work out (for example, the provider violates the service level agreement, makes technical or price changes that the customer cannot accept), the customer is forced to revert to the previous version of the application, which may lead to the loss of part or all of its elements.
Let's say you rebuild your application to be completely serverless. Using serverless technology, you can run your application without having to manage servers yourself. Not all providers have such a service, and therefore, if the current one offers it, then you become to some extent dependent on the contractor. This is not so bad, but this factor will need to be considered.
Number 5: Replacement
In this scenario, you completely replace your existing application (s) with software delivered as a service (SaaS). The advantage of the replacement model is that it avoids development costs. However, you can run into problems with data access, unpredictable data semantics, and provider binding.
This can be a great option for minimizing the number of services and applications that need to be managed. An example would be replacing a local database with a managed option such as Cloud Datastore, Cosmos DB, or Dynamo. This can be one of the easiest ways to raise your SLA level. All of these services are known for their scalability and availability. In contrast, starting the database yourself and working with data replication and recovery can be very time-consuming.
Subtotal
Migration projects of any size require careful planning.
A successful cloud migration needs good preparation. There is no one size fits all approach to cloud migration. Your teams will need in-depth knowledge of the infrastructure and applications that run your business to fully understand the complexity, challenges, and costs of migrating to the cloud.
Risks and Benefits of Cloud Migration
Like most companies, your organization has probably migrated at least one service to the cloud. However, this does not mean that cloud migration is suitable for everyone. While cloud computing environments tend to be scalable, reliable, and highly available, this is not always the only reason to migrate data and infrastructures.
Companies consider many factors when migrating, from the benefits and risks to the cloud service model and type that is right for them. Next, we'll look at the top-level factors to consider when considering moving to the cloud.
The potential benefits of cloud migration
There are many challenges that moving to the cloud can solve. Here are some typical examples where companies have benefited from cloud migration.
The application requires more bandwidth, and it becomes difficult to scale resources on the fly to meet the growing demand
Need to reduce operating costs while improving the efficiency of IT processes
Companies need to deploy and deploy applications quickly; want to focus more on development while reducing infrastructure overhead
Companies looking to expand their business geographically, building a multi-regional infrastructure with associated service, time, human resources and error control efforts will be challenging
Keeping pace with growing storage needs is getting harder and more expensive
There is a need to create a widely distributed development team. Cloud computing enables remote workers to access applications and work over the Internet
You need to create a disaster recovery system, but setting it up for your entire data centre can double the cost. It also requires an elaborate disaster recovery plan. Cloud-based disaster recovery systems can be implemented much faster and also allow for better control over resources
Keeping track of and updating the underlying server software is a time consuming but essential process that requires periodic and sometimes immediate updates. The cloud provider is ready to take care of this. Many other administrative tasks, such as database backups, software updates, and periodic maintenance, are handled similarly with the cloud.
CapEx and OpEx: Cloud computing is shifting IT spending to a pay-as-you-go model, which is an attractive advantage, especially for startups.
Potential risks of cloud migration
There are certain risks of operating in the cloud for every business system. You will need to consider them, as well as the difficulties associated with migration.
If your application stores and receives very important data, you may not be able to serve it in the cloud. Compatibility requirements can also limit your choices.
If your existing infrastructure meets your needs, does not require a lot of maintenance, scalability, and availability, and all your customers are happy, why bother with the clouds?
If some technology that you currently rely on is proprietary, you might not be able to legally deploy it in the cloud, nor is it worth going to the cloud.
Some operations may experience additional latency when using cloud applications over the Internet.
If your hardware is being serviced by someone else, you may lose some transparency and control when dealing with performance issues.
Cloud neighbors can affect how your infrastructure works in the cloud. The specific design and architecture of your application may not fully match the distributed cloud architecture, so some modifications will be required before migration.
Cloud Platform or Vendor Tether: Once hosted in the cloud, it can be difficult to leave or move from one platform to another.
Downtime. It happens to everyone, but you might not like that your availability is being monitored by someone else.
What kind of cloud service model do you need?
Now that you've decided to try the cloud, you need to choose the right resource consumption model.
The most common models:
IaaS: Infrastructure as a Service
PaaS: Platform as a Service
SaaS: Software as a Service (e.g. Google G Suite, Office 365, Salesforce, NetSuite).
IaaS is best suited for companies that don't mind hosting their applications in third-party data centres, but instead prefer to outsource the care of their physical infrastructure to focus more fully on development, deployment, and monitoring.
However, if you prefer to keep your applications portable, you can simply throw your code onto a robust PaaS platform that provides a complete (and transparent) infrastructure. Implementing a PaaS solution will also save time - since the PaaS will be preloaded with most of the required software - you only need to deploy the topmost application tier, in some cases only the application executables.
SaaS is a business model through which centrally hosted productivity software is licensed on a subscription basis.
Public, Private or Hybrid?
You have chosen a resource consumption model, and now it's time to decide on the type of cloud.
There are three main options:
Public: Your resources are entirely hosted by one or more cloud providers.
Private: You create your own private cloud on your hardware.
Hybrid: Your resources are distributed in both private and public sites with monitored connections.
With a balanced balance of on-demand reliability, high availability, security and lower operating costs, a hybrid cloud can be very attractive. Sometimes a hybrid cloud can give you the best of both worlds.
How exactly can a hybrid work?
Let's imagine your web application is rapidly gaining popularity with users. In order to keep up with growing demand, you need a reference resource to scale dynamically. During peak usage, you should be able to deploy as many resources as possible to service requests, and when demand falls, ideally, you should be able to discard unnecessary resources to save money simply. This is possible in the public cloud. But let's say that the data your application collects is very confidential and cannot be stored outside of your facility. A hybrid solution can help. Then you choose which components will live in the public cloud and which will remain in your data centre.
RightScale reported that enterprises are increasingly adopting a multi-cloud strategy (84%) and 58% are planning to use hybrid clouds.
Assessing Cloud Migration Applications
After choosing the model and type of cloud, the real work lies ahead. Now it's time to see if your applications are ready to run in a virtual environment. Here are some factors to consider:
Application design complexity
Some traditional applications are so complex and tightly coupled that customers may not want to redesign them. However, the main requirement for any successful migration is that the application has a distributed architecture and is scalable. Tools like PaaSLane and Cloudamize can help you assess the readiness of your applications for the cloud.
Complexity of integration
Each application has its own points of integration, such as payment gateways, SMTP servers, web services, external storage, and components from third party vendors. It is very important to analyze what impact the migration to the cloud will have on them. Sometimes, you will experience unexpected connectivity or authentication issues that need to be identified and resolved ahead of time. The most important (and tedious) task is to identify all of these integration points. Because older applications may be poorly documented and developers who are familiar with end-to-end functional and non-functional details may not be available, you may have to go through each module manually. The task becomes more difficult if you are considering migrating hundreds of applications currently running in your data center.
Many of these problems can be solved by involving the IT team and using a resource discovery tool (both open source and commercial). This tool can help you identify entire server configurations on a network, along with connection specifics. Let's say you have an online datacenter running about 100 applications. The discovery tool prepares a bird's eye view of the entire system. He will also provide detailed details that may be useful for an overall assessment of capacity management.
Some of the more famous asset discovery tools include BMC Atrium and HP DDMA. Cloudamize provides a tool that can automatically search for applications and machines, and display application dependencies.
Host operating system
When you decide to move to the cloud, it's important to know if you can deploy your applications on the same OS. Your apps can only run on a specific OS (or OS version). If it is not compatible with your cloud service provider, then you need to find a working OS replacement, another vendor, or simply abandon the entire project. For example, most providers do not provide 32-bit OS options, while others may have unexpected subscription requirements. It's best to do your research ahead of time.
Application database
Obviously, the database is a critical part of any application. Customers invest heavily in database servers, and often in licenses. Moreover, given the complexity and sensitivity of your data, you may simply not want to move it right now: moving petabytes of data is not a trivial task. In any case, you should make sure that the migration methods you use are very reliable and have the ability to rollback in the event of unexpected chaos.
Most cloud providers offer migration assistance. Therefore, it is very important to evaluate these proposals before pressing the "start" button. There are also many third-party vendors providing data migration services: Attunity CloudBeam, ATADATA ATAmotion, CloudEndure Live Migration and Racemi DynaCenter.
Net
Most cloud environments do not support multicasting, so if your application relies on multicasting, think carefully.
Cost comparison
Many cloud providers have pricing calculators to help you estimate the real costs of moving to the cloud versus your ongoing costs. The calculator allows you to compare TCO (Total Cost of Ownership) so you can decide which is the best fit based on the application's current workload profiles.
Health check model
It's always a great idea to create a little proof of concept (POC) before you actually move your workload to the cloud. Such models do not solve all possible problems, but they will give you more clarity and understanding of the difficulties you may face.
Some of the things to look for during a POC include:
Performance comparison with your existing application
Difficulty levels associated with application migration
Network problems to be solved
Reliability
Cloud Provider Support Assessment
All the challenges of moving to the cloud in real time cannot be covered in one article. This text describes the main issues that need to be considered before embarking on the migration process.
See more details in my book: The Ultimate Modern Guide to Cloud Computing (https://enamulhaque.co.uk/book%3A-clo...)
A better version of this article could be found here: https://enamulhaque.co.uk/my-articles...
Why are businesses migrating to the cloud?
Here are three simple reasons why businesses are starting to migrate to the cloud:
Reason 1: Speed and cost savings
With cloud computing, you can scale your business to fit your needs, and with the right management, you can handle any spike in load and save money while keeping your consumption low.
Reason 2: New features such as disaster recovery
If your enterprise's business is global, the cost and complexity of managing end-to-end disaster recovery for on-premises data centers will skyrocket. It is possible to reduce costs by using high-quality cloud infrastructures in a centralized manner.
Reason 3: Continuously updated new technologies and services
Just look at any of the major cloud providers and you will see that they are constantly developing new technologies and services to help customers deliver services. Offers include the most trending solutions, from faster servers to machine learning systems in the cloud.
Why migrate to the cloud? Let's consider in more detail
Regardless of the industry, almost every company is now forced to turn into a technology, and even rather an IT company. Businesses are becoming increasingly IT-dependent. However, in this new role, IT is no longer just supported, but part of the product. Manufactured by factories.
If you are limited to local servers, you are likely to lose in comparison with competitors in scalability and prospects in the horizon of 5-10 years. By contrast, migrating to the cloud offers additional competitive advantages such as speed, scalability, and cost savings.
Rather than continuing to invest in aging and expensive infrastructure that keeps pace with change, moving to the cloud is a choice for the future. In addition to being able to economize and scale IT, you are essentially laying the foundation to respond faster to market changes, grow and drive innovation over the long term.
When planning a cloud migration, understanding how to accomplish it depends on your individual business model and goals, as well as your current infrastructure and applications. You need to rely on the skills and experience of your IT teams to understand the ins and outs of the current environment and the interdependencies of your applications. This will help determine which applications should be migrated to the cloud and how.
What specific business goals should you look out for?
Data Privacy and Compliance Needs: Should Governments or Healthcare Requirements Require Privacy?
Vendor dependency: want to "put all your eggs in one basket"?
Cost: time / money. How long will it actually take to migrate data in response to your company's changing skills and culture?
What else needs to be considered when migrating?
Cloud Migration - Moving, Platform Change, Revision, Rebuild, and Replacement is a great starting point for considering all options for migrating applications to the cloud.
Whether it's the initial migration or the fifth iteration, a successful cloud journey requires strategy and planning. Here's what you need to know.
Number 1: Move
Rehosting is the process of migrating existing physical and virtual servers to the public cloud (Infrastructure as a Service (IaaS)) as is (as is). The main advantage of this approach is that systems can be quickly moved without changing their architecture. Companies often follow this path at the very beginning of their work with cloud technologies. When you move, you essentially treat the cloud-like just another data centre, which means you are not getting the most out of the cloud services available.
Let's take a web application as a simple example. Imagine you have an ASP.NET application running on Windows, and you want to move it to the cloud. You can create a Windows VM that meets the size requirements and deploy the application. After changing the DNS records, you are almost ready to go. This migration is an easy way to move to the cloud. However, this solution is not highly available or scalable and requires you to configure OS updates.
Number 2: Platform Change
It is the process of launching applications on a managed set of services from your cloud provider, also called platform as a service (PaaS). Using PaaS means that developers can reuse frameworks, languages, and containers.
For applications or workloads that can be refactored in the cloud, you can take advantage of some of the cloud features to lower costs and increase scalability. However, the biggest disadvantages of this option are portability risks, lack of functionality, and framework binding. One of the common problems faced by developers is that many PaaS options use irregular data storage. This usually requires a change to the codebase to use cloud storage rather than the local file system for the saved files.
An example of refactoring using PaaS would be taking an existing Ruby on Rails application and deploying it to Heroku, or taking an existing Drupal application and modifying it to run on Acquia Cloud or Pantheon. PaaS options allow you to focus on your application without having to deal with the underlying operating system.
Number 3: Revision
Some applications will need to be modified more seriously to move them to the cloud. Some will require functionality to be added, while others may need to be completely rebuilt before they can be reinstalled or redone and ultimately deployed to the cloud.
This can be difficult as modifying a large array of code to make it cloud-based can be time consuming and costly. An example is to take a complex, monolithic Python-based application and move it to the cloud infrastructure. The design of your application will dictate the amount of changes you need. You may find yourself needing to split it into multiple applications and swap components such as message queues to get the most out of the move.
Number 4: Rebuild
In this scenario, the application is reworked, the original coding is discarded, and it is rebuilt based on the PaaS infrastructure. Reworking the app allows you to take advantage of the more advanced capabilities of your cloud provider to create an even better app. The main disadvantage of this option is vendor binding.
For example, if for a number of reasons cooperation does not work out (for example, the provider violates the service level agreement, makes technical or price changes that the customer cannot accept), the customer is forced to revert to the previous version of the application, which may lead to the loss of part or all of its elements.
Let's say you rebuild your application to be completely serverless. Using serverless technology, you can run your application without having to manage servers yourself. Not all providers have such a service, and therefore, if the current one offers it, then you become to some extent dependent on the contractor. This is not so bad, but this factor will need to be considered.
Number 5: Replacement
In this scenario, you completely replace your existing application (s) with software delivered as a service (SaaS). The advantage of the replacement model is that it avoids development costs. However, you can run into problems with data access, unpredictable data semantics, and provider binding.
This can be a great option for minimizing the number of services and applications that need to be managed. An example would be replacing a local database with a managed option such as Cloud Datastore, Cosmos DB, or Dynamo. This can be one of the easiest ways to raise your SLA level. All of these services are known for their scalability and availability. In contrast, starting the database yourself and working with data replication and recovery can be very time-consuming.
Subtotal
Migration projects of any size require careful planning.
A successful cloud migration needs good preparation. There is no one size fits all approach to cloud migration. Your teams will need in-depth knowledge of the infrastructure and applications that run your business to fully understand the complexity, challenges, and costs of migrating to the cloud.
Risks and Benefits of Cloud Migration
Like most companies, your organization has probably migrated at least one service to the cloud. However, this does not mean that cloud migration is suitable for everyone. While cloud computing environments tend to be scalable, reliable, and highly available, this is not always the only reason to migrate data and infrastructures.
Companies consider many factors when migrating, from the benefits and risks to the cloud service model and type that is right for them. Next, we'll look at the top-level factors to consider when considering moving to the cloud.
The potential benefits of cloud migration
There are many challenges that moving to the cloud can solve. Here are some typical examples where companies have benefited from cloud migration.
The application requires more bandwidth, and it becomes difficult to scale resources on the fly to meet the growing demand
Need to reduce operating costs while improving the efficiency of IT processes
Companies need to deploy and deploy applications quickly; want to focus more on development while reducing infrastructure overhead
Companies looking to expand their business geographically, building a multi-regional infrastructure with associated service, time, human resources and error control efforts will be challenging
Keeping pace with growing storage needs is getting harder and more expensive
There is a need to create a widely distributed development team. Cloud computing enables remote workers to access applications and work over the Internet
You need to create a disaster recovery system, but setting it up for your entire data centre can double the cost. It also requires an elaborate disaster recovery plan. Cloud-based disaster recovery systems can be implemented much faster and also allow for better control over resources
Keeping track of and updating the underlying server software is a time consuming but essential process that requires periodic and sometimes immediate updates. The cloud provider is ready to take care of this. Many other administrative tasks, such as database backups, software updates, and periodic maintenance, are handled similarly with the cloud.
CapEx and OpEx: Cloud computing is shifting IT spending to a pay-as-you-go model, which is an attractive advantage, especially for startups.
Potential risks of cloud migration
There are certain risks of operating in the cloud for every business system. You will need to consider them, as well as the difficulties associated with migration.
If your application stores and receives very important data, you may not be able to serve it in the cloud. Compatibility requirements can also limit your choices.
If your existing infrastructure meets your needs, does not require a lot of maintenance, scalability, and availability, and all your customers are happy, why bother with the clouds?
If some technology that you currently rely on is proprietary, you might not be able to legally deploy it in the cloud, nor is it worth going to the cloud.
Some operations may experience additional latency when using cloud applications over the Internet.
If your hardware is being serviced by someone else, you may lose some transparency and control when dealing with performance issues.
Cloud neighbors can affect how your infrastructure works in the cloud. The specific design and architecture of your application may not fully match the distributed cloud architecture, so some modifications will be required before migration.
Cloud Platform or Vendor Tether: Once hosted in the cloud, it can be difficult to leave or move from one platform to another.
Downtime. It happens to everyone, but you might not like that your availability is being monitored by someone else.
What kind of cloud service model do you need?
Now that you've decided to try the cloud, you need to choose the right resource consumption model.
The most common models:
IaaS: Infrastructure as a Service
PaaS: Platform as a Service
SaaS: Software as a Service (e.g. Google G Suite, Office 365, Salesforce, NetSuite).
IaaS is best suited for companies that don't mind hosting their applications in third-party data centres, but instead prefer to outsource the care of their physical infrastructure to focus more fully on development, deployment, and monitoring.
However, if you prefer to keep your applications portable, you can simply throw your code onto a robust PaaS platform that provides a complete (and transparent) infrastructure. Implementing a PaaS solution will also save time - since the PaaS will be preloaded with most of the required software - you only need to deploy the topmost application tier, in some cases only the application executables.
SaaS is a business model through which centrally hosted productivity software is licensed on a subscription basis.
Public, Private or Hybrid?
You have chosen a resource consumption model, and now it's time to decide on the type of cloud.
There are three main options:
Public: Your resources are entirely hosted by one or more cloud providers.
Private: You create your own private cloud on your hardware.
Hybrid: Your resources are distributed in both private and public sites with monitored connections.
With a balanced balance of on-demand reliability, high availability, security and lower operating costs, a hybrid cloud can be very attractive. Sometimes a hybrid cloud can give you the best of both worlds.
How exactly can a hybrid work?
Let's imagine your web application is rapidly gaining popularity with users. In order to keep up with growing demand, you need a reference resource to scale dynamically. During peak usage, you should be able to deploy as many resources as possible to service requests, and when demand falls, ideally, you should be able to discard unnecessary resources to save money simply. This is possible in the public cloud. But let's say that the data your application collects is very confidential and cannot be stored outside of your facility. A hybrid solution can help. Then you choose which components will live in the public cloud and which will remain in your data centre.
RightScale reported that enterprises are increasingly adopting a multi-cloud strategy (84%) and 58% are planning to use hybrid clouds.
Assessing Cloud Migration Applications
After choosing the model and type of cloud, the real work lies ahead. Now it's time to see if your applications are ready to run in a virtual environment. Here are some factors to consider:
Application design complexity
Some traditional applications are so complex and tightly coupled that customers may not want to redesign them. However, the main requirement for any successful migration is that the application has a distributed architecture and is scalable. Tools like PaaSLane and Cloudamize can help you assess the readiness of your applications for the cloud.
Complexity of integration
Each application has its own points of integration, such as payment gateways, SMTP servers, web services, external storage, and components from third party vendors. It is very important to analyze what impact the migration to the cloud will have on them. Sometimes, you will experience unexpected connectivity or authentication issues that need to be identified and resolved ahead of time. The most important (and tedious) task is to identify all of these integration points. Because older applications may be poorly documented and developers who are familiar with end-to-end functional and non-functional details may not be available, you may have to go through each module manually. The task becomes more difficult if you are considering migrating hundreds of applications currently running in your data center.
Many of these problems can be solved by involving the IT team and using a resource discovery tool (both open source and commercial). This tool can help you identify entire server configurations on a network, along with connection specifics. Let's say you have an online datacenter running about 100 applications. The discovery tool prepares a bird's eye view of the entire system. He will also provide detailed details that may be useful for an overall assessment of capacity management.
Some of the more famous asset discovery tools include BMC Atrium and HP DDMA. Cloudamize provides a tool that can automatically search for applications and machines, and display application dependencies.
Host operating system
When you decide to move to the cloud, it's important to know if you can deploy your applications on the same OS. Your apps can only run on a specific OS (or OS version). If it is not compatible with your cloud service provider, then you need to find a working OS replacement, another vendor, or simply abandon the entire project. For example, most providers do not provide 32-bit OS options, while others may have unexpected subscription requirements. It's best to do your research ahead of time.
Application database
Obviously, the database is a critical part of any application. Customers invest heavily in database servers, and often in licenses. Moreover, given the complexity and sensitivity of your data, you may simply not want to move it right now: moving petabytes of data is not a trivial task. In any case, you should make sure that the migration methods you use are very reliable and have the ability to rollback in the event of unexpected chaos.
Most cloud providers offer migration assistance. Therefore, it is very important to evaluate these proposals before pressing the "start" button. There are also many third-party vendors providing data migration services: Attunity CloudBeam, ATADATA ATAmotion, CloudEndure Live Migration and Racemi DynaCenter.
Net
Most cloud environments do not support multicasting, so if your application relies on multicasting, think carefully.
Cost comparison
Many cloud providers have pricing calculators to help you estimate the real costs of moving to the cloud versus your ongoing costs. The calculator allows you to compare TCO (Total Cost of Ownership) so you can decide which is the best fit based on the application's current workload profiles.
Health check model
It's always a great idea to create a little proof of concept (POC) before you actually move your workload to the cloud. Such models do not solve all possible problems, but they will give you more clarity and understanding of the difficulties you may face.
Some of the things to look for during a POC include:
Performance comparison with your existing application
Difficulty levels associated with application migration
Network problems to be solved
Reliability
Cloud Provider Support Assessment
All the challenges of moving to the cloud in real time cannot be covered in one article. This text describes the main issues that need to be considered before embarking on the migration process.
See more details in my book: The Ultimate Modern Guide to Cloud Computing (https://enamulhaque.co.uk/book%3A-clo...)
A better version of this article could be found here: https://enamulhaque.co.uk/my-articles...
No comments have been added yet.