When you think of the cloud, what do you think of? If you are like most people, you think of the following:
· File storage (such as Amazon S3, Azure Cloud Storage, or Google Cloud Storage)
· Servers (such as Amazon’s EC2, Azure Servers, or Google Compute Engine)
And in fact, you can utilize the cloud efficiently and effectively using only these two types of resources.
However, cloud companies offer a wide variety of managed services that you can take advantage of to ease your management load, increase your availability, and improve your scalability. Knowing how these components are organized and managed can help determine which capabilities you wish to utilize for your application.
While the concepts discussed here apply to all cloud providers, for this chapter we will focus on AWS for our examples and illustrations.
Structure of Cloud-Based Services
There are three basic types of cloud-based services:
· Raw resource
· Server-based managed resource
· Serverless managed resource
Figure 16-1 illustrates these three types. Raw resources provide basic server virtualization support and nothing else. The application and the operating system that runs the application on the virtualized hardware are all owned and managed by the consumer. Only the virtualization layer is managed by the cloud provider. Server-based managed resources follow the same basic system architecture; they still run software on a virtualized server. The difference is that the software that runs on the server is also managed by the cloud provider. In a serverless managed resource, the software running the resource is managed by the cloud provider, but the infrastructure running the software is invisible to the consumer, and the consumer is not impacted by how the infrastructure is managed.
Figure 16-1. Types of cloud-based services
Let’s look at each of these three types of cloud services in greater detail.
A raw cloud resource provides basic capabilities to the user and provides only basic management. An example of a raw cloud resource is Amazon EC2 or Azure Virtual Server, each of which provides raw server capabilities in a managed manner.
The cloud provides management of the basic server virtualization layer and the creation of the instance and its initial filesystem. However, after the instance is up and running, the operation of the server itself is opaque to the cloud provider (see Figure 16-2).
The cloud provider manages the data flowing into and out of the instance (the network), as well as the CPU and the utilization of the CPU. But the provider does not know anything about what is running within the server itself, nor does it monitor anything that goes on in the server.
Figure 16-2. Raw resource management responsibility
For cloud providers like AWS, this is intentional. What runs on the server is your business, and AWS does not want to be responsible for any aspect of the software running on it. AWS’s line of responsibility ends at the entry/exit points to the virtual server itself. AWS even has a name for this: it’s called the AWS Shared Responsibility Model. For each of AWS’s services, this model describes what is the responsibility of AWS and what is the responsibility of the customer. In the case of EC2, the Shared Responsibility Model describes the end of AWS’s responsibility at the virtualization layer, and the start of the customer’s responsibility at the operating system layer.
Where you can see the impact of using raw resources
You can see the impact of this in a couple different ways.1 For EC2 instances, look at the metrics that AWS collects and provides to you via CloudWatch. All of the metrics are network-level metrics, such as:
· The amount of network traffic to/from the instance
· How much data is read/written to the disks
· The amount of CPU that is being consumed
But missing from this list are some obviously useful metrics that it does not track:
· Amount of free memory and disk space
· Number of processes running
· Swap or paging activity
· Which processes are consuming the most resources
These metrics don’t exist because they depend on the operating system used on the instance, which is not managed by the cloud provider.
You can also see the impact of this in the access control to the instance. AWS manages network-level access to your instance (via ACLs), but you are responsible for user login capabilities to the instance (operating system).
Server-Based Managed Resource
A server-based managed resource is a resource that provides a full stack managed solution for a specific cloud capability. An example of a server-based managed resource is Amazon RDS database or Microsoft Azure SQL database. These services provide a managed database application running on top of a managed server infrastructure. Figure 16-3 shows how server-based managed resources are managed.
Figure 16-3. Server-based managed resource management responsibility
A managed database solution such as Amazon Relational Database Service (RDS) or Microsoft’s Azure SQL runs the database and special management software on an existing managed server, making it possible for the entire stack, server, and software on the server to be managed by the cloud provider. The database software is an industry-standard database (such as MySQL, PostgreSQL, or SQL Server) running in a completely managed manner on top of a standard managed server. These services provide a complete managed database solution, top to bottom.
Take a look at Figure 16-1 again, and you can see how RDS is structured. (Figure 16-3 shows a close-up view of this managed stack.) Basically, when you launch an RDS instance, you launch an EC2 instance that is running a specific OS, special management software, and the database software itself. Amazon manages not only the EC2 server but the entire software stack as well, including the OS and database software.
Where you can see the impact of using server-based managed resources
You can see the impact of this by looking at the CloudWatch metrics provided by RDS instances. Besides the basic EC2 instance information, you get additional monitoring about the database itself, such as the following:
· Number of connections made to the database
· Amount of filesystem space the database is consuming
· Number of queries being run on the database
· Replication delay
These metrics are available only from the OS and the database software itself.
Another way to understand the impact is to consider the type of configuration you can perform. No longer is the configuration just basic information about the server (network connections and disks connected)—you can also configure information about the database itself, such as maximum number of connections, caching information, and other configuration and tuning parameters.
Serverless Managed Resource
Serverless managed resources are resources that provide a specific capability, but do not expose the server infrastructure the capability is running on. There are several examples of this in AWS, including Amazon S3, DynamoDB, and AWS Lambda. From Microsoft, Azure Functions is an example of such a serverless managed service. Figure 16-4 shows how serverless managed resources are architected and managed.
Let’s take a look at a great example of a serverless managed storage service, Amazon S3. This service provides cloud-based file storage and transmission. When you store a file in S3, you communicate directly with the S3 service. There is no server or servers that are allocated on your behalf to perform the actions. The fact that there might be one or more servers running behind the scenes to perform the request is invisible to you.
Figure 16-4. Serverless managed resource management responsibility
The entire operation is managed, but you only have visibility into, and the ability to control, the exposed software interface provided by the service (in the case of S3, that is uploading files, downloading files, deleting files, and so on). You have no visibility into, nor the ability to control, the underlying operating system or the servers that service is running on. These servers are shared among all users of the service, and as such they are managed and controlled by Amazon without your involvement.
Another great example of a serverless service is AWS Lambda. This service provides cloud-based function execution. As is the case in Amazon S3, there is no server or servers that are allocated on your behalf to perform the actions. The fact that there might be one or more servers running behind the scenes to perform the request is invisible to you.
One of the great advantages of serverless services, such as these is their ability to scale without the need for you to take additional actions to allocate resources. If traffic to your application increases suddenly, Amazon will automatically apply the appropriate resources to handle your increase in Amazon S3 or AWS Lambda needs. You do not need to allocate additional resources for this to happen; it is all managed by AWS.
This is opposed to server-based managed services, which require you to take actions based on expected traffic load. When you create an Amazon RDS database instance, you have to size it to match your expected traffic needs. If your traffic needs fall below this level, you waste resources. If your traffic needs fall above this level, you risk running out of database capacity and starving your requests. You have to manage the allocation of resources applied to your application.
Implications of Using Managed Versus Non-Managed Resources
When a service or a part of a service is managed, there are many advantages for you, the user of the service. Here are some in particular:
· You do not need to install or update the software of a managed system.
· You do not need to tune or optimize the system (but you may have some capabilities to do so via the cloud provider).
· You do not need to monitor and validate that the software is performing as expected.
· The cloud provider can provide monitoring data for you to consume, if you desire, without additional software or capabilities.
· The cloud provider can provide backup and replication capabilities for the service.
· The cloud provider can provide a higher level of security to your service.
There are also disadvantages to managed components:
· You typically do not have the ability to significantly change how the software performs its operations.
· You do not have the ability to control when and how the software is upgraded or the version of software that is running.2
· You are limited to the capabilities offered by the cloud provider for monitoring and configuring the service.
When a service or a part of a service is nonmanaged, there are some advantages for you, the user of the service. Here are some in particular:
· You can control what software is running on the service, what version is running, and how it is set up.
· You control when and how upgrades are performed, or if they are performed.
· You can monitor and control the software in whatever manner you want, using whatever mechanisms you want.
There are also disadvantages to nonmanaged components:
· Nothing is free. You are completely responsible for all management and maintenance that the system requires.
· You must make sure you perform your own backup and data replication.
· You must monitor your software to ensure that it is functioning correctly—if you do not, no one will let you know when it fails.
· If the software breaks or fails, you alone are responsible for fixing it. The cloud provider cannot help.
· You have to manage the security of the service—your cloud provider can’t help you nearly as much.
Understanding whether a service is managed or not, and whether it is server-based or serverless, can help you make the best use of the service and help you make decisions on how to utilize the service, especially in a highly scaled application.
1 More information on what AWS monitors with CloudWatch is available at https://oreil.ly/qKvOk.
2 However, the cloud provider can provide you some of these capabilities; for example, RDS provides a range of database versions that it supports, but not all versions are available. In managed systems like S3, you have no control over the software upgrade process at all.