CompTIA Cloud+ CV0-003 Exam: Basics of Cloud Migrations

Objective: Given a scenario, perform cloud migrations.
Most organizations that are considering deploying resources in the cloud may consider migrating existing solutions from their on-premises environment to the cloud. This approach is very common in enterprise organizations where the networks and applications have been homegrown or bought off the shelf over the years and now it is time to transition to the cloud. Migrating solutions requires a great deal of consideration and planning because a bad migration can result in downtime and extra expense.
There also are born-in-cloud organizations in which the organizations do not have any legacy footprint and start their journey from cloud-native deployments and workloads.
This guide will explore some of the different methods of migrating to the cloud. They will include physical-to-virtual, virtual-to-virtual, and even cloud-to-cloud migrations. Three types of resource migrations also will be explored: operating systems, storage, and database migrations.

Topics:
- Physical to Virtual (P2V)
- Virtual to Virtual (V2V)
- Cloud-to-Cloud Migrations
- Storage Migrations
- Database Migrations

1. Besides manual and fully automated, what other method can be used to perform a physical-to-virtual migration?
2. Which open format can be used to create a virtual appliance?
3. Which term describes when a customer deploys a resource in the cloud that is dependent on software or features that are provided only by a specific cloud vendor?
4. True or false: A nonrelational database is also referred to as a SQL database.

Answers:
1. Semi-automated
2. Open Virtualization Format (OVF)
3. Vendor lock-in
4. False

Physical to Virtual (P2V)
When planning to migrate your operations to the cloud, you will likely need to develop a strategy to transfer operating systems that reside on physical systems to the virtual environment provided by the cloud vendor. This process is referred to as a physical-to-virtual (P2V) migration.

There are three primary methods you can employ to perform a P2V migration:
- Manual: With this method, you deploy your cloud-based virtual machines, manually install any necessary software, and manually transfer any data from the physical OS to the virtual machine. For small migrations, this may be a reasonable solution, but this method does not scale well to large migrations.
- Semi-automated P2V: This technique makes use of a tool that aids in the process of migrating to a virtual machine. This process is semi-automated in the sense that a human is required to start the migration and may be required to answer questions during the migration process. Typically, these tools are provided by cloud vendors free of charge, and they do have the advantage of providing the user with some control of the migration process as it happens. Some of these tools also allow for hot migrations, in which the operating system is live while it is being migrated. However, in very large-scale migrations, semi-automated P2V tools can be very time-consuming to use.
- Fully automated P2V: A fully automated P2V also makes use of a tool, but this tool does not require any human interaction. In some cases, these tools may be able to explore a local network, find systems, and migrate the systems to the target state environment (this depends on the types of operating systems and how the network has been configured). A fully automated P2V works well in large migration deployments, but the software tool may cost money to use.

Virtual to Virtual (V2V)
You may already have virtual machines in your on-premises environment. If that is the case, the process of migrating these operating systems to a cloud infrastructure is called virtual-to-virtual (V2V) migration.
A V2V migration is often easier than a P2V migration because the host operating system is already in a virtualized state. There are also some standards in virtualization that help with this process. For example, the Open Virtualization Format (OVF) is a standard that isn’t tied to any specific hypervisor. It provides a standard for the process of defining (packaging) virtual appliances (software that is run in a virtual environment). Many of the popular hypervisor vendors, including VMware, VirtualBox, Red Hat Enterprise Virtualization, and Oracle VM, provide support for OVF. For example, the figure below demonstrates the process of exporting a virtual machine in OVF format using VirtualBox.


Exporting a Virtual Machine in OVF Format

Many cloud vendors provide support for importing virtual appliances that are in OVF format. Some vendors also provide tools to export virtual machines into a standard format, which can also be helpful for cloud-to-cloud migrations.

Cloud-to-Cloud Migrations
The concept of a cloud-to-cloud migration is that your organization decides to move resources from one cloud vendor to another. This move could be made for a variety of reasons, including cost, features, or security. This section will cover several topics that you should consider when performing a cloud-to-cloud migration.

Vendor Lock-in
One of the concerns about migrating to the cloud is the potential of vendor lock-in (also called proprietary lock-in). In this scenario a customer deploys a resource in the cloud that is dependent on software or features that are provided only by a specific cloud vendor.
The problem with vendor lock-in is that it eliminates the flexibility and options for customers who are migrating to the cloud. Vendor lock-in is sometimes the result of decisions made by the cloud vendor to employ a proprietary technology, such as a proprietary file format or encryption method. Although a customer may be able to migrate the resource to another cloud vendor, migration typically comes with a cost, either a financial or time-consuming cost.

PaaS or SaaS Migrations
Recall that with Platform as a Service (PaaS), the cloud vendor provides a platform (an operating system) that you use to deploy your software. There are many things to consider when planning a PaaS migration from one cloud vendor to another, including
- Is the language that your code is written for supported by the cloud vendor?
- Does the cloud vendor provide redundancy in its PaaS solution to prevent downtime? If so, what does the service-level agreement (SLA) provide for guaranteed minimum downtime?
- Does the cloud vendor provide a disaster recovery plan that meets the needs of the customer?
- Does the security of the cloud vendor’s PaaS solution meet the needs of the customer? For example, is data encrypted at rest or in transit?
- What is the data backup policy for the cloud vendor’s PaaS solution, and does this meet the needs of the customer?
- Does the cloud vendor’s PaaS solution provide a Content Delivery Network (CDN)?
- Does the cloud vendor’s PaaS solution meet all regulatory requirements that the customer is required to meet?
- Does the cloud vendor’s support for its PaaS solution meet the needs of the customer?
Keep in mind that many of these concerns are related not only to PaaS migrations but are also concerns for other migrations, such as IaaS and SaaS. However, with PaaS the focus is on ensuring that the customer’s software will function correctly on the cloud vendor’s PaaS.

With Software as a Service (SaaS), the focus shifts to functionality and portability. For example, with SaaS the biggest factors and concerns typically include the following:
- Does the new vendor’s SaaS solution provide the features that are required?
- Is it possible to migrate data from the existing SaaS solution to the new vendor’s SaaS? If so, what is the process (manual, automated, semiautomated, and so on), and what are the associated costs for this migration?
- Does the new vendor’s SaaS solution provide the capability to scale as required by the customer?

Access Control Lists (ACLs)
An access control list is used to determine who is able to access a specific resource within your cloud environment. For example, a network access control list (NACL) can include a list of IP addresses or IP networks that are permitted to access a VPC. Rules for NACLs are associated with network ports (or protocols) and either allow or deny access.
In terms of cloud-to-cloud migration, there are a few things to consider, including
- Does the new vendor provide an ACL solution that is similar to the functionality of the existing vendor’s ACL solution?
- Is it possible to migrate the rules of the current ACL to the new vendor’s ACL?
- Are there limitations to the new vendor’s ACL solution that can result in security issues?

Firewalls
Firewalls provide a similar function to ACLs, but the functionality level is much higher than ACLs. There are also different types of firewalls that can implemented in the cloud. For example, a web application firewall (WAF) is a Layer 7 firewall designed to protect your cloud applications from web-based exploits. There are also various cloud-based firewall appliances, many of which can be deployed on different cloud vendor environments.
Because firewall rules are often complex, migrating from one cloud vendor to another can pose challenges. The wide variety of firewall solutions also tends to limit the chance of an automated solution migrating a firewall from one cloud environment to another.

Storage Migrations
Because storage migrations often involve massive amounts of data, much of which may contain proprietary information, the process of migrating storage solutions from on-premises to the cloud poses certain challenges. When planning for the migrating of storage, take the following issues into consideration:
- Data integrity: There needs to be a method to ensure that the original data is not corrupted during the migration process.
- Monitoring: You need to use a monitoring or logging solution to ensure all data is migrated.
- Security: For most data, it will be critical to ensure that the data is encrypted during transport.
- Bandwidth: Transferring massive amounts of data can take a great deal of time, even with large amounts of bandwidth. This transfer can also impact day-to-day business operations, so bandwidth throttling or data transfer scheduling can be used. Some vendors also provide alternative methods of transferring data, including shipping data using large storage devices or out-of-band data securely connected to the cloud.
- Cost: Depending on the storage solution, there may be a cost involved to transfer data into a cloud storage solution.

The rest of this section will cover specific considerations for block, file, and object migrations.
On-premises block storage solutions are those that are stored on disk volumes. When migrating this sort of data, you should consider which cloud storage solution you want to migrate the data to. While storing the data in a cloud block storage solution might make sense, you may also consider storing the data in a file storage solution or even an object storage solution.
In terms of which solution would be easiest, typically a block-to-block migration would require the least amount of effort. This method also would allow you to maintain the same file system structure (such as NTFS, ext4, and FAT) as the original storage solution. Maintaining the same structure can be important if the data on the existing file systems is secured by file system features, like permissions.
A block-to-file migration solution is typically not much more complex than a block-to-block solution, but transferring individual files may be more time-consuming. However, transferring block data to object data will be more complex unless using a tool provided by the cloud vendor. It is important to note that features, such as file system permissions and the hierarchy of file systems (subdirectories or subfolder trees), are often lost in these sorts of migrations.

File
Because file storage solutions are being widely used on-premises and these solutions are network-based, transferring this data to a cloud solution is typically one of the easier migrations. Many cloud vendors also provide tools to make this migration process easy.
A file-to-block migration is not normally a viable or desired solution. However, a file-to-object migration is worth considering because object storage solutions may have benefits that file storage doesn’t have (ACLs, capability to share via a URL, and so on).

Object
On-premises object-based solutions, like MinIO, Ceph, and LeoFS, can also be migrated to a cloud solution. The process of migrating this data to the cloud may seem simple, but object metadata, security, and access methods will complicate the process.

Database Migrations
When you’re performing a database migration, there are several things to consider, including:
- Scalability: In most cases when you implement a cloud database solution, you associate the database with hardware (such as CPU, storage space, and network bandwidth). Although this hardware should fit the needs of your current database, you need to ensure that the hardware can be scaled to meet the future needs of your database solution.
- Security: Because your database will now be stored in the cloud, security may become even more of a priority.
- Regulatory: Any time that you are dealing with data, you may need to also adhere to compliance rules. These rules may originate from government regulatory agencies or third-party organizations, like banks. With your database now being stored in the cloud, you need to ensure that where and how the data is stored and maintained meet all regulatory requirements.
- Architecture: While all of these topics are important to consider when migrating a database solution to the cloud, the architecture of the database itself might be the most important. You might need to perform a heterogeneous migration where the source database architecture is different from the destination database.
- Cost: As with any cloud migration, cost must always be considered. This includes not only the cost of the database service that the vendor charges but also the costs of modifying software that uses the data and potentially needing to train employees on how to utilize the new database.

Objective 3.5 is the only one on the CompTIA Cloud+ certification exam that addresses databases. This topic is only a very small part of the exam.

Relational
A relational database is one in which data is stored in tables, which consist of columns and rows. In many ways it is similar to a spreadsheet, but there are some key differences. The data within each row is referred to as a record. In a relational database there must be a column that contains a unique value. This value is called the key.
Relational databases are often called Structured Query Language (SQL) databases. SQL isn’t really a database type, but rather a language that is used to create, modify, and query data in a relational database.
The relational part of relational databases is the feature that allows a connection (relation) between different tables in the database.

Here are some advantages of relational databases:
- They work well for structured data.
- The query times are typically very fast.
- Many software tools provide SQL functionality.
- The format of the database (rows and columns) is easy for users to conceptualize.
- There are many on-premises and cloud relational database management systems (RDBMS) solutions available.

Nonrelational
Nonrelational databases, also called NoSQL databases, employ a different method of storing data. There are four different types of nonrelational databases:
- Document: This database is used to store document types of data, which are normally encoded in a data format like JSON, XML, or YAML.
- Columnar: This database is similar to relational database, but with some key differences. For example, in a relational database, every record must have a value for every column. This is not a requirement for nonrelational databases.
- Key-value: A key is associated with a value in this type of database.
- Graph: In this type of database, complex relationships between data sets can be developed.

Here are some advantages of nonrelational databases:
- Very flexible structure
- Good for document-oriented data
- Great for Big Data situations

Quiz:
1. Which of the following is not considered a P2V migration method? A.Manual B.Semi-automated C.Fully automated D.Semimanual
2. A(n) _____ is used to determine who is able to access a specific resource within your cloud environment. A.ACL B.Firewall C.Vendor lock D.SaaS
3. Which of the following is not a consideration when performing a storage migration? A.Data integrity B.Security C.Bandwidth D.User accessibility

Answers:
1. Semimanual
2. ACL
3. User accessibility