Understanding Cloud Characteristics - Deploying and Managing a Cloud Infrastructure - page 23

In the case of Amazon S3, this would be the object ID with which you can query the
object for read/modify/delete. This extended metadata also becomes part of the system-
generated metadata since the unique identifier of the object is generated by the system to
ensure its uniqueness and coherence with the ID generation scheme.
Physical Layer Abstraction
Extended metadata allows for thorough abstraction of physical storage devices and the whole
underlying storage fabric from the end user or cloud tenant. This also enables the cloud pro-
vider to offer replication and ensure high availability (HA) and data loss prevention even
when multiple servers across data centers experience downtime or, worse, crash.
When you create an object and push it to the public cloud for storage, you do not have
to specify the location where you would want the object to be stored. Instead, when you
make the PUT REST API call for pushing the object, you get a unique identifier as a
response. This ID is persistent throughout the life of the object. Similarly, when you want
to fetch that object and consume the data, all you have to do is make a GET call to the
object storage's REST API and specify the unique ID.
The data object may have hopped several physical storage locations and may have been
replicated several times, but these operational details are abstracted from the consumer of
this data object and you get the data back in response to your GET call to the storage API.
This not only removes all complexity from data storage and access but also gives the cloud
vendor the flexibility to transition backend storage systems without adding any complexity
or even changing the API call signatures.
Data Residency
Public cloud providers are generally not bound to ensure that objects pushed by tenants
or end users are stored in a specific region or data center or physical storage. However, a
higher-level physical distribution is visible to the tenants and can be configured to keep
data objects closest to the end users. For example, Amazon offers the choice of zones that
indicate their data centers spread across the world. If you specify your S3 buckets to be
placed in the West-1 zone, you would know that end users on the U.S. West Coast would be
closest in distance to your data.
Policies
Most of the finer lower-level details and configurations are abstracted from the end user as
we discussed previously. But not every cloud tenant will have the same set of use cases and
configurations for object data storage. The cloud provider has to expose some of the con-
figurations that directly impact the applications a tenant is running, and these applications
are consuming the data elements stored in the cloud provider's object storage system.
Policies are one way to configure the access of data and also impact its life cycle. Users
can set policies that apply to the whole account (or every S3 bucket the user creates, in the
case of Amazon) or specify individual policies for separate pools of objects.
Group policies can be broadly related to file permissions that users can set for individual
files or folders. Not every data object your application sends off to the cloud for storage is