Ben Piper - CompTIA Cloud+ Study Guide

In the IaaS model, cloud providers also offer Domain Name System (DNS), Dynamic Host Configuration Protocol (DHCP), and virtual private cloud networks as part of the service, so you don't have to spin up your own DNS or DHCP servers as you would in a data center environment.

Just as security is a critical component in private and corporate data centers, so is it in the cloud. Cloud service providers offer many security services, including firewalls, access control, intrusion detection and prevention systems, and encryption services.

Large storage arrays and storage area networks exist in the cloud for use by cloud service consumers. Common storage media are solid-state drives (SSDs) and magnetic physical drives. Storage types include object-based, block-based, and filesystem-based systems. Some storage is optimized for high availability and durability, and others are less expensive and offer long-term archival storage.

Cloud providers give you complete control over how open or closed your cloud resources are to the rest of the world. If you want to offer a service that's available to anyone anywhere in the world, you can do that. Ubiquitous access refers to the ability to access cloud resources from anywhere in the network from a variety of devices such as laptops, tables, smartphones, and thin or thick clients. On the other hand, if you want to restrict access only to those within a particular office, you can do that as well. Because most cloud providers are security-conscious, they prohibit access to your cloud resources by default. You have to explicitly allow access.

Organizations that blindly decide to move some of their IT infrastructure to the cloud are sometimes met with an unpleasant surprise when they find out how difficult and expensive it can be. It's not necessarily that the cloud is prohibitively expensive. The surprise comes from failing to understand the dependencies that exist among different IT resources in the data center. When one IT resource moves from the data center to the cloud, it usually has to drag a few other resources with it. For example, moving a database-backed application probably requires moving the database, which might be quite large. Naturally, whoever manages that database is going to have to back it up, so backups will have to be stored in the cloud as well.

Hence, you must have a very clear and detailed understanding of what it is that you are actually moving. This means having updated documentation that reflects all aspects of your operations. To perform a migration, you must know exactly which applications you are running, their dependencies, along with any storage, network, operating system, processing, memory, and any other relevant requirements. The more detailed assessment of your current operations, the better equipped you are to decide whether it makes sense to move to a cloud-based model.

Let's talk about some considerations for migrating on-premises compute resources into the cloud. In the data center, you have virtual machines. It's often possible to migrate a virtual machine directly to the cloud, but the better approach is usually to create a new virtual machine in the cloud and configure it from scratch. One reason for this is that a virtual machine running in your data center will have drivers and other software specific to the virtualization platform that you're using, which will undoubtedly be different than what the cloud provider is using. Performing a “lift and shift” migration to the cloud is asking for trouble.

The sizing of virtual machines—processor power, memory, and storage—should mirror that of your data center VMs. VMs in the cloud are fundamentally no different than the VMs in your data center. There is no “cloud magic” that makes cloud-based VMs more resource efficient. For example, an application that requires 16 GB of memory in the data center will require just as much memory when it's running in the cloud. Make sure that there is ample input/output (I/O) and low latency for storage access, and that there is enough processing and memory allocated to ensure the proper level of performance expected.

One final word on migrating machines to the cloud. Prior to machine virtualization, each physical server ran a single operating system on bare metal . This often meant that one server could host only a handful of applications. Nowadays, machine virtualization is the norm, both in the data center and in the cloud. However, you may occasionally run across an old application that for whatever reason has to run on a bare-metal server. Such applications generally aren't good candidates for moving to the cloud. If you're not sure, you can sometimes smoke out such legacy applications by looking for servers that have been exempted from operating system updates.

Another consideration involves the physical placement of your data center VMs. To ensure resiliency in the event of a virtualization host failure, organizations often use hypervisor affinity rules to ensure that redundant VMs never run on the same hardware. For example, you may have primary and secondary SQL database servers, each running on a different VM host. If the host running the primary SQL VM fails, the secondary VM running on a different host can take over. If both are running on the same host, then both VMs fail, defeating the point of redundant VMs in the first place!

Cloud providers offer the ability to enforce hypervisor affinity rules, although they may use more user-friendly terminology, such as VM-host affinity. As you plan a cloud migration, take note of VMs that are redundant or that appear to serve the same purpose. Chances are that you have hypervisor affinity rules in place that you'll want to re-create in the cloud.

To perform a successful migration to the cloud, it is important to bring together all the interested parties and stakeholders. The traditional IT groups such as development, operations, OSs, storage, networking, and security will be integral parts of the migration teams. Non-IT groups, such as finance and legal, will need to be involved, because cloud computing can significantly change the cost and accounting models of departments and possibly the entire organization. In the data center model, a healthy portion of the budget goes to the up-front expenses of purchasing physical infrastructure such as servers and networking equipment. Accountants call these capital expenditures (capex for short). When moving to the cloud, these huge capital outlays aren't necessary. Instead of spending hundreds of thousands or more on IT infrastructure, you pay the cloud provider a monthly fee based on usage. This expense is ongoing for as long as you use the services, but the amount you have to fork over up front is much less. This is called an operational expenditure (opex) model. In essence, instead of buying or leasing your own equipment, you're leasing the use of the cloud provider's equipment.

If the company does not have the in-house expertise with cloud migrations, it may be advised to enlist the skills of companies specializing in assisting companies moving to the cloud. Also, especially with larger projects, a project manager should be assigned to track and manage the undertaking.

Once you identify the pieces that need to move to the cloud, you need to decide what cloud delivery model you want to use. If you're hosting applications on-prem, do you continue to host the same applications in the cloud using an IaaS model? Or do you offload some of the responsibility to the cloud provider by using a PaaS model? For example, you may have a custom application written in Python. You can continue to run it in VMs as you always have, but just in the cloud using an IaaS model. Or you may instead run it in the cloud without having to bother with the VMs—the PaaS model.