RDP Remote Desktop Protocol (RDP) is a proprietary protocol developed by Microsoft to allow remote access to Windows devices, as illustrated in Figure 1.24. RDP is invaluable for managing remote Windows virtual machines, since it allows you to work remotely as if you were locally connected to the server. Microsoft calls the application Remote Desktop Services, formerly Terminal Services. The remote desktop application comes preinstalled on all modern versions of Windows. RDP uses the TCP port 3389.FIGURE 1.24 Local computer running Remote Desktop Services to remotely access a Windows server graphical interface in the cloudThe graphical client will request the name of the remote server in the cloud, and once it's connected, you'll be presented with a standard Windows interface to log in. Then you'll see the standard Windows desktop of the remote server on your local workstation.
SSH The Secure Shell (SSH) protocol has largely replaced Telnet as a remote access method. SSH supports encryption, whereas Telnet does not, making Telnet insecure. To use SSH, the SSH service must be enabled on the VM. This is pretty much standard on any Linux distribution, and it can also be installed on Windows devices.Many SSH clients are available on the market as both commercial software and freeware in the public domain. The SSH client connects over the network using TCP port 22 via an encrypted connection, as shown in Figure 1.25. Once you are connected, you have a command-line interface to manage your cloud services. SSH is a common remote connection method used to configure network devices such as switches and routers.FIGURE 1.25 Secure Shell encrypted remote access
Monitoring Your Cloud Resources
Just because you have created an operational cloud deployment doesn't mean your work is over! You must continually monitor performance and also make sure that there are no interruptions to services. Fortunately, this function has largely been automated. As you'll learn in later chapters, cloud providers offer ways to collect and analyze performance and health metrics. You can also configure automated responses to various events, such as increased application response time or a VM going down. Also, alerts such as text messages, emails, or calls to other applicators can be defined and sent in response to such events.
Monitoring and automation go hand in hand in the cloud. For example, you can use autoscaling to add additional virtual CPUs to a VM if utilization has, for example, exceeded 98 percent for more than 10 minutes. And just like everything else in the cloud, you can configure this automation quickly and adjust it to meet changing requirements.
Writing It All Down (Documentation)
Documentation should be created by the many different teams involved in the cloud deployment, such as the server, virtualization, storage, networking, developer, security, and management teams, as well as the cloud provider.
Once the document is complete, it should be readily accessible, and the procedures to maintain consistency should be clear. A corporate compliance group may be formed to monitor and maintain adherence to the standardization process. Also, since the operations and deployment are constantly evolving and changing, the documentation will need to be constantly modified and updated.
Creating Baselines
Before migrating to the cloud, you should establish baselines for various aspects of your current infrastructure. Baselines to collect include CPU, memory, storage utilization, and database query times. Establishing baselines helps you determine how to size your cloud resources. Baselines also help you tune your monitoring. Use your baseline statistics as a reference, and if a metric goes significantly above or below that value, you can configure an alert to fire or autoscaling to add more capacity. The deviation of a metric from a baseline is called variance.
Because the metrics you'll be monitoring will likely change quickly, minute by minute, as well as slowly over longer periods of time, you'll want to take baseline samplings for both long-term and short-term intervals. For example, suppose a database server running in your data center averages 70 percent CPU utilization over the course of a day, but it occasionally spikes to 90 percent for about 15 minutes when someone runs a complex query. You don't necessarily want to alert every time the CPU utilization spikes. But you might want to know if the average daily CPU utilization begins creeping up to, say, 80 percent. Therefore, having separate baselines for the long term and the short term gives you a better picture of what's really going on in your environment. Keep in mind that monitoring always requires trial and error.
Your baselines help you form a starting point for determining what the normal metrics are for your environment, but they're not to be taken as gospel, since they will change over time. Also, given the huge number of cloud resources available, there are even more metrics that you can monitor. The key is to focus only on the most impactful metrics.
Shared Responsibility Model
Cloud providers operate under what's called a shared responsibility model that defines what you are responsible for and what the provider is responsible for. The model will vary depending on what you are contracting to use and the offerings of the service provider. Let's look at how the division of responsibilities changes with different service models.
IaaS
As the “I” in IaaS suggests, the cloud provider is responsible for the underlying infrastructure they provide as a service—all of the hardware, hypervisors, block storage, and networking. If you're running VMs, you would have responsibility for the operating system and applications, as well as configuration of your virtual network, which includes network access controls and IP routing.
To make it easier to get started, a cloud provider may provide you with a default virtual network for your IaaS resources. Even though such a default network should work right out of the gate, it's still your responsibility to make sure that it's configured properly.
PaaS
With a PaaS service, you're responsible for the applications you choose to run on the service, and the cloud provider would take responsibility for almost everything your application depends on—namely the VMs, OS, and storage. When it comes to the networking, the division of responsibilities may vary. The cloud provider may offer to configure networking for you automatically, giving you unique public and private IP addresses and corresponding DNS entries, or you may provide your own network configuration parameters.
SaaS
When offering Software as a Service, the cloud provider assumes full responsibility for everything, including the software itself. Your responsibility is limited to how you configure and use the software.
Summary
In this introductory chapter, you explored the big picture of cloud computing. You investigated the many types of service models offered in the marketplace today. The core models include IaaS, which strives to emulate the core components of a traditional data center and offer them as a service to facilitate migrations to the cloud. The PaaS and SaaS models extend the benefits of elasticity and pay-as-you-go