storage. Even the drive in your personal computer stores data in this way.In the cloud, because VMs may move from host to host, the VM's persistent storage is not attached to the host. In cloud provider terminology, block storage may be called elastic block storage or block blob storage. Notice how the terminology hints at the flexible and abstract nature of the storage.To allocate space from a block storage pool, you create a volume that you can then attach to a VM as a virtual disk. Just as when you provision a VM and the cloud provider dynamically and automatically finds a host to run it on, so too the provider selects some SANs from the storage pool to hold the volume. One big advantage of storage pooling is that your data is stored redundantly on multiple physical SANs; if one fails, your VM can keep on running with no loss of data.As you gain experience with the cloud, you'll notice that as a general rule, the more block storage you allocate to a vDisk, the better the performance you get. The reason for this is that allocating more storage means that storage is spread across more physical drives operating in parallel.Although block storage is typically thought of as an IaaS analog to the SAN, it does come into play in some PaaS services. Some managed SQL database services make use of block storage. Although in most cases the cloud provider manages it, you still may get to choose some aspects of the volume such as speed and size.Although the storage systems are generally external from the physical servers themselves, some cloud providers do let your VM use locally attached drives for temporary storage, like swap files or caching.
Object/File Storage As the name suggests, object/file storage is designed just to store files. You can use object storage to store any file of virtually any size. It's often used for file backups, but it can also be used to store web assets such as images, video, HTML files, and PDF documents. Object/file storage is intended to store files that don't change frequently, so although you can use it to store a database backup, it's not appropriate for storing a live database that's regularly written to.The cloud provider will usually offer multiple interfaces to upload or download files. For example, they may allow you to transfer files via a web interface, command-line tool, or API. They may allow you to use HTTP to download files, effectively letting you use the object store as a static web server.One particularly important use of object storage is storing snapshots of elastic block storage volumes. When you take a snapshot of a VM's volume for backup or cloning, it may be stored in object storage, depending on the cloud provider.
Filesystem Storage Filesystem storage is similar to object/file storage in that both are for storing files. However, filesystem storage is meant for files that change frequently, like a live database. Filesystem storage is a popular choice for applications that need shared read/write access to the same files.The way that you interact with filesystem storage differs from object storage. You access filesystem storage via standardized network filesystem protocols, such as Network File System (NFS) or Server Message Block (SMB). To do this, you must configure your OS to mount the networked filesystem as a volume. The OS can then read and write files, just as it would on any other attached filesystem.In the data center environment, it's common to have file servers dedicated to offering file storage via SMB or NFS, typically for storing user documents. You could still build your own file servers in the cloud, but most cloud providers offer this as a service under the SaaS model.
Organizational Uses of the Cloud
In the cloud, just as in the data center, you don't simply deploy your applications and forget about them. Applications have to be updated or reconfigured, and you'll probably end up adding or retiring applications over time. These operations always carry the risk of breaking working things, something that can be detrimental to your organization. Therefore, it's a best practice to test changes before rolling them out and committing to them. To achieve this, it's common to separate operations into four isolated sections of the cloud:
Production
Quality assurance/test
Staging
Development
As we walk through these categories, keep in mind that they can be broken down differently according to the needs of the organization. The point here is to protect the organization from data loss and downtime caused by changes.
Production
Production environments host the live applications that the organization uses in its normal course of business. These include email, customer-facing services, and any other line-of-business applications.
The use of multiple production environments can become important during the rollout of updates. Depending on the application, you may want to release updates only to a portion of users. For example, if you're adding a new feature to a web application, you can use load balancing to direct a small portion of users (say 10 percent) to the updated version while everyone else uses the old version. If there's an unforeseen problem with the updated version, it impacts only a fraction of your users.
Of course, this is a simple example, and this approach won't necessarily work in more complex cases. If the application update causes irreversible changes to a huge database, a more cautious approach is needed. This is where it may be necessary to replicate the full production environment and test the update there. If all goes well, you cut everyone over to the updated environment. If things don't go so well, your existing production environment remains intact and functional.
Quality Assurance/Test
Quality assurance (QA)/test environments are used for the testing of software updates or new applications. QA/test environments may closely mirror production environments to ensure the accuracy of test results. To achieve this parity, you may need to copy over production data to the QA/test environment, but the environments still remain carefully separated. We'll discuss some testing methods later in the chapter.
When sensitive data exists in the production environment, doing a verbatim copy to QA/test may not be feasible. It may be necessary to use dummy data that mimics the production data.
Staging
Staging environments are used for building out a system prior to releasing it to production. In reality, a staging environment is just a preproduction environment.
Development
Development environments are typically used by software developers for creating new applications. Organizations that don't develop their own software may not need a dedicated development environment.
Scaling and Architecting Cloud Systems Based on Requirements
One of the prime advantages of cloud computing is that it enables on-demand computing, allowing you to deploy and pay for the computing capacity that you are actually using. This is an attractive alternative to having to absorb the costs of servers sitting on standby to address any bursts or cyclical higher compute requirements, such as end-of-month processing or holiday sales loads if, for example, you are a retailer.
Autoscaling is a cloud feature that automatically adds and removes resources based on demand. By paying only for what you need when you need it, you can take advantage of the immense computing power of the cloud without having to pay for servers that are just sitting idle during times of low demand.
For example, let's look at a small sporting goods retailer that uses a public cloud provider to host its e-commerce website. During normal operations, the retailer runs and pays for three web servers. During times of high demand, autoscaling will provision additional web servers to match the increased load. For example,
