Category Archives: Cloud

Software, Buildings, and Artifacts

Decentralization is at the core of modern web services. We need a framework which acknowledges and leverages it. This framework will provide a common base in the form of design patterns, architectural principles, code libraries, REST APIs, documentation. This is a journey to undertake by collecting and communicating the necessary information. What does all this have to do with buildings? Well, quite a lot in my opinion.
My ideas about this came about during my engineering school years and from my humanistic upbringing during junior and high school. In all those years, a common thread has been my admiration for things that, not only serve the purpose for which they are built but also for their simplicity in design and elegance. You can relate this to the artists and engineers of the Renaissance, such as Leonardo and Michelangelo, who traced their work philosophies back to the traditions of the ancient Romans and Greeks.

As I progressed in my training and, later during my work years as an engineer and a writer, I concluded that if I wanted my “artifacts” to serve their purpose and to be simple and elegant by design, I better follow the masters, albeit in a humble manner. Any artifact I was going to build, no matter how simple or how complex, had to be thought out and carefully crafted. This had to start with the creation of a blueprint. You can equate this to the blueprint of a building.

The blueprint does not represent the organization of the crews building the structure; it represents the architecture of the building. While the crews’ organization can change, the blueprint is much more resilient, any modifications made to it are not related to personnel or organizational changes.

In software, you can have a similar blueprint that highlights the architectural components of the system being created. To further the idea of the building metaphor, you can start from the foundation which might, for example, refer to compute, storage, network, all the way up to the last floor which might represent an application layer. The plumbing, the electrical, phone and Internet cabling, the heating and the fire alarm systems can all be equated to APIs and interfaces that execute functions necessary for software and building to operate. The following is a simplified view of a cloud-based blueprint:

References

Representational State Transfer (REST) APIs Part 4 of 4

2 Replies

The Representational State Transfer (REST) API can be a conundrum. A lot of information obfuscates what in its essence is a very straightforward concept.

The REST API is not strictly speaking an “API”, if you refer to the HTTP protocol verbs. REST, in the words of its originator Roy Fielding, is an “architectural style”. Specifically, it is a set of guidelines that hinge on the HTTP protocol specifications. See http://www.w3.org/Protocols/.

Why should you care about this mambo jumbo? Well, believe it or not,this style is the corner stone of all the Cloud (Web) services. At its core a Cloud service is stateless. All the information about state is on the client side. For example, if you take a web page, once it has been delivered to the client, there is no memory on the server side keeping track of “what to do next”. What to do next, that is all the state information, is in the page itself in terms of hyperlinks. In essence, besides its HTML content, the hyperlinks in the page are the representational state transfer.

REST guidelines instruct the developers to use HTTP verbs explicitly and in a way that it is consistent with the protocol definition. This means a one-to-one mapping between create, read, update, and delete (CRUD) operations and HTTP verbs as follows:

Create a resource with POST
Retrieve a resource with GET
Update a resource with PUT
Delete a resource with DELETE

You can find more verbs here.

Why is REST Popular?

Because HTPP is ubiquitous, as a higher protocol in the application layer of the OSI model, the HTTP (REST) verbs have become the minimalist, effective and standard way to exchange information (text, images, videos and so on) on the Internet.

The following figure shows where the HTTP protocol is located in the OSI model:

Where is the API?

Well, any company that is in the web services business (shall we say Cloud), provides a set of libraries to support the most common programming languages (Java, Python, C#, etc…). A programmer can use a familiar programming language to perform requests associated with HTTP verbs. She must know a company specific library to make API calls. The library translates the calls into the appropriate HTTP verb requests. It also fills the HTTP protocol details such as header information.

The following is a logical diagram, albeit a simplified one, of the main components involved in a RESTful exchange:

The following code examples show how to list the objects in a bucket (stored in a public cloud storage “the service”):

The following code examples show how to list the objects in a bucket (stored in a public Cloud storage “the service”):

def listObjects(bucketName, service):
  print 'List objects contained by the bucket "%s".' % bucketName
  fields_to_return = 'nextPageToken,items(bucket,name,metadata(my-key))'
  request = service.objects().list(bucket=bucketName, fields=fields_to_return)
  response = request.execute()
  print json_dumps(response, indent=2)

Storage.Buckets.List listBuckets =
  service.buckets().list(settings.getProject());
buckets = listBuckets.execute();
for (Bucket bucket : buckets.getItems()) {
  displayMessageHeader("Getting bucket " + bucket.getName() + " metadata");
  displayBucketInformation(bucket);
}

Under the hood, a GET request is issued. But you do not see it in the code snippet above.
What you see is an API call as highlighted.

Representational State Transfer (REST) APIs Part 3 of 4

Leave a reply

The Web architecture has influenced the REST genesis and the way other kinds of distributed systems are created. In its essence the Web is based on these fundamental principles (architectural style):

Resource Representation
Resource State
Resource Address

REST Context

Resource Representation

A resource is the basic building block of a distributed system (and the Web) and represents anything that a service can expose such as a document, a video or a business process. What is exposed is not the actual resource but its representation. This representation is encoded in one or more transferrable formats such as HTML, XML, JSON, plain text, JPEG and so on. A simple example is a Web page.

A service accesses a resource representation never the underlying resource. This separation allows loose coupling between a client application and the service and also allows scalability because a representation can be cached and replicated.

Each representation is a view of the same actual resource, with transfer formats negotiated at runtime through a content negotiation mechanism.

Resource State

A service progresses by transitioning from one state to another like in a state machine. The key difference is that in the service the possible states and the transitions amongst them are not known in advance. As the service gets to a new state, the next possible transitions are discovered.

For example, in an hypermedia system the states are defined by uniquely identifiable resources. The identifiers of the possible states to transition are contained in the current (state) representation as hyperlinks. Hence the name Representational State Transfer (REST).

Resource Address

A service can act on a resource (i.e., representation) through a very well defined set of verbs as provided by the HTTP protocol. For more information, see HTTP 1.1 rfc 2616. This set provides a uniform interface or a small number of verbs with well defined and widely accepted semantics to meet the requirements of a distributed system.

To act upon a resource the service must be able to identify it unequivocally. Tis is done through the Uniform Resource Identifier (URI). A URI uniquely identifies a resource and makes it addressable or capable of being manipulated using a protocol such as HTTP.

A one to many relationship exists between a resource and URIs. A URI identifies only one resource, but a resource can have more than one URI.

A URI takes the following form:

http://scheme-specific_structure

For example

http://myserver/croissants/chocolate-truffle

establishes that the URI must be interpreted by the service according to the HTTP scheme. Notice that the previous URI does not specifies the resource format.

Best Practices

It is good practice not to specify the format in the URI by adding a suffix to the resource such as .html or .xml or .jsp. It is the responsibility of the service to provide the correct format as specified by the client in the Accept attribute of the HTTP request header (content negotiation). This allows loose coupling between the client and the service.

Using HTTP Verbs

The following examples show how to use HTTP verbs to access resources exposed by a Web service.

The service used is the public available HTTP Request & Response Service.

HEAD

Request

To obtain header info, in your console enter the following command:

curl -I httpbin.org

Response

The execution of the previous command produces this output:

 

HTTP/1.1 200 OK
Connection: keep-alive
Server: gunicorn/19.7.1
Date: Wed, 25 Apr 2018 23:46:15 GMT
Content-Type: text/html; charset=utf-8
Content-Length: 13129
Access-Control-Allow-Origin: *
Access-Control-Allow-Credentials: true
X-Powered-By: Flask
X-Processed-Time: 0
Via: 1.1 vegur

GET

Request

To perform a GET request, in your console enter the following command:

curl -X GET httpbin.org

Response

The execution of the previous command produces the page content at the specified URL:

 

<html>
 <head>
   <meta http-equiv='content-type' value='text/html;charset=utf8
   <meta name='generator' value='Ronn/v0.7.3 (http://github.com/
      <title>httpbin(1): HTTP Client Testing Service</title>
......
</html>

PUT

Request

To perform a GET request, in your console enter the following command:

curl -X PUT httpbin.org

Response

The execution of the previous command produces the following response:

 
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
<title&gt;405 Method Not Allowed&lt;/title>

<h1>Method Not Allowed></h1>



The method is not allowed for the requested URL.

Service Maturity Level

A maturity model has been created to classify services as highlighted next.

Level 1 tackles the question of handling complexity by using divide and conquer, breaking a large service endpoint down into multiple resources.
Level 2 introduces a standard set of verbs so that we handle similar situations in the same way, removing unnecessary variation.
Level 3 introduces discoverability, providing a way of making a protocol more self-documenting.

For more information, see Maturity Model.

References

Representational State Transfer (REST) APIs Part 2 of 4

Leave a reply

Good Design Practices

A well designed cloud service uses HTTP verbs (methods) explicitly followed by nouns in URIs. The verbs HEAD, POST, GET, PUT, DELETE, and OPTIONS are all that is needed and are already defined by the protocol. This allows clients to be explicit about the operations they invoke. The API should not define more verbs or remote procedures, such as /addcroissant or /updatecroissant. The body of an HTTP request transfers resource state, it does not carry the name of a remote method or remote procedure to be invoked.

A RESTfull service such as AWS S3 exposes standard HTTP resources (objects). Each resource responds to one or more of the six standards verbs (methods). Every resource exposes the same interface and works the same way. For example, to get an object’s value an application issues a GET request to that object’s URI. To get just the object’s metadata the application sends an HEAD request to the same URI. In other words, to expose your service you do not have to create a new set of verbs or interject method names in the URI but you must think carefully about your resource design.

In the case of S3 you have three types of resources each having its own URI:

List of buckets (https://s3.amazonaws.com).
A particualar bucket (https://s3.amazonaws.com/{bucket name}).
A particular object (https://s3.amazonaws.com/{bucket name}/{object name}).

The following code snippet example uses curl to issue a HEAD request to the test service located at www.httpbin.org.

$ curl -I www.httpbin.org

The service returns the following information:

 
HTTP/1.1 200 OK
Connection: keep-alive
Server: gunicorn/19.7.1
Date: Fri, 27 Apr 2018 22:50:11 GMT
Content-Type: text/html; charset=utf-8
Content-Length: 13129
Access-Control-Allow-Origin: *
Access-Control-Allow-Credentials: true
X-Powered-By: Flask
X-Processed-Time: 0
Via: 1.1 vegur

Stateless Design

Cloud REST services need to scale to meet high performance demands. Clusters of servers with load-balancing and failover capabilities, proxies, and gateways allow requests to be forwarded from one server to the other to decrease the overall response time of a service call. Using intermediary servers to improve scale requires clients to send complete, independent requests which include all data needed by a request so that the components in the intermediary servers may forward, route, and load-balance without any state being held locally in between requests.

A complete, independent request doesn’t require the service to retrieve any kind of application context or state. A client application includes within the HTTP headers and body of a request all the parameters, context, and data needed by the server-side component to generate a response.

A stateless service not only performs better, it shifts most of the responsibility of maintaining state to the client application. In a REST service, the server is responsible for generating responses and for providing an interface that enables the client to maintain the application state. For example, in the request for a multipage response, the client should include the actual page number to retrieve instead of simply asking for the next page as shown in the next figure.

A stateless service generates a response that links to the next page number in the set and lets the client do what it needs to keep this value around. This service design can be divided into two groups of responsibilities that clarifies how a stateless service can be created:

Service Responsibilities

Generate responses that include links to other resources. This allows client applications to navigate between related resources. This type of response embeds links. If the request is for a parent or container resource, a typical REST response might also include links to the parent’s children or subordinate resources so that these remain connected.
Generate responses that indicate whether they are cacheable. This improves performance by reducing the number of requests and by eliminating some requests entirely. The service does this by including a Cache-Control and Last-Modified (a date value) HTTP response header.

Client Responsibilities

Use the Cache-Control response header. This determines whether to cache the resource (make a local copy). The client also reads the Last-Modified response header and sends back the date value in an If-Modified-Since header to ask the service if the resource has changed. In this conditional GET, the service’s response is a standard 304 code (Not Modified) which omits the actual resource requested if it has not changed since last time it was modified. The client can safely use the cached resource, bypassing subsequent GET requests.
Send complete requests that can be serviced independently of other requests. The client uses HTTP headers as specified by the service and send complete representations of resources in the request body. The client sends requests that make very few assumptions about prior requests, the existence of a session on the server, the server’s ability to add context to a request, or about application state that is kept in between requests.

This collaboration between client application and service is essential to for a stateless service. It improves performance by saving bandwidth and minimizing server-side application state.

Directory like URIs

The URIs determine how intuitive the REST service is and whether the service is going to be used in ways that the designers can anticipate. URIs should be intuitive to the point where they are easy to guess. Ideally a URI should be self-documenting and must requires little explanation to understand how to access resources. In other words, a URI should be straightforward, predictable, and easy to understand.

One way to achieve this level of usability is to define directory like URIs that is the URI is hierarchical, rooted in a single path. Its branches are subpaths that expose the service’s main areas. A URI is a tree with subordinate and superordinate branches connected at nodes. For example, in

http://www.sunshinebakery.com/croissant/{croissant-name}

The root /croissant (bucket) has a series of croissants (objects) such as chocolate-truffle, raspberry-jam, and so on, each of which points to a croissant type. Within this structure, it’s easy to get a croissant by typing the specific croissant name after /croissant/.

Additional URIs Guidelines

Hide the server-side scripting technology file extensions (.jsp, .php, .asp), if any, so you can port to something else without changing the URIs.
Keep everything lowercase.
Substitute spaces with hyphens or underscores (one or the other).
Avoid query strings as much as possible.
Provide a default page or resource as a response instead of using 404 Not Found code if the request URI is for a partial path.
URIs should also be static so that when the resource changes or the implementation of the service changes, the link stays the same. This allows bookmarking.
It’s also important that the relationship between resources that’s encoded in the URIs remains independent of the way the relationships are represented where they are stored.

XML or JSON Format

The representation of a resource reflects the current state of the resource and its attributes, at the time a client requests it. The representation is a snapshot in time.

Client and service exchange a resource representation in the request/response payload or in the HTTP body using XML or JSON format. It is very important to keep things simple and human-readable. The following are some guidelines to keep in mind:

The objects in the data model are usually related and the relationships between data model objects (resources) should be reflected in the way they are represented for transfer to a client application.
The client applications should have the ability to request a specific content suited for them. So the service should use the built-in HTTP Accept header, where the value of the header is a MIME type. This allows the service to be used by a variety of clients written in different languages running on different platforms and devices.

Using MIME types and the HTTP Accept header is a mechanism known as content negotiation. This lets clients choose which data format is right for them and minimizes data coupling between the service and applications.

References

Designing well-formed URIs for your REST Web API (micheltriana.com)
API Layer and its responsibilities – a REST viewpoint (byterot.blogspot.com)
RESTful Web Services Cookbook
A Beginner’s Tutorial for Understanding and Implementing ASP.NET Web API (codeproject.com)

Representational State Transfer (REST) APIs Part 1 of 4

2 Replies

At the core of a cloud service oriented architecture, the Representational State Transfer (REST) APIs play a key role by allowing applications to interact with any of the cloud service types (IaaS, PaaS, or Saas). These APIs abstract out the infrastructure and protocol details and allow any application to communicate with the selected service.

To use these APIs effectively, you must understand the principles on which they are built. To this end, when you think cloud, you must think Web and the underlying protocol used to exchange information. We are all familiar with accessing a page on the Web using a browser. Well, when you access a Web page a request is issued from your computer (client browser) to the Web site (hosting server) using the HTTP protocol.

Representational State Transfer (REST)

The majority of the cloud programming REST APIs are built on the HTTP protocol where the Web is the platform. For more information, see HTTP 1.1 rfc 2616.

More specifically, the majority of the cloud services (and related APIs) are designed using an architectural style known as Representational State Transfer (REST). This style is widely used and is a simpler alternative to SOAP and related Web Services Description Language (WSDL).

Capitalizing on the Web success and based on its semantics, REST formalizes a set of principles by which you can design cloud services to access system’s resources, including how resource states are addressed and transferred over HTTP by a wide range of clients. As first described by Roy Fielding in his seminal thesis Architectural Styles and the Design of Network-based Software Architectures, REST is a set of software architectural principles that use the Web as a platform for distributed computing. Since then, REST has emerged as the predominant Web service design model.

The Web is composed of resources. A resource is any item worth to be exposed. For example, the Sunshine Bakery Inc. may define a chocolate truffle croissant resource. Clients may access that resource with this URL:

http://www.sunshinebakery.com/croissants/croissant/chocolate-truffle

A representation of the resource is returned for example, croissant-chocolate-truffle.html. The representation places the client application in a state. If the client traverses a hyperlink in the page, the new representation places the client application into another state. As a result, the client application changes (transfers) state with each resource representation

Proper Use of HTTP Methods

A key design principle of a RESTful service is the proper use of HTTP methods that follows the protocol as defined in the RFC 2616.

For example, HTTP GET is a data-producing method that is intended to be used by a client to perform one of the following operations:

Retrieve a resource.
Obtain data from a Web service.
Execute a query with the expectation that the Web service will look for and respond with a set of matching resources.

REST guidelines instruct the developers to use HTTP methods explicitly and in a way that is consistent with the protocol definition. This means a one-to-one mapping between create, read, update, and delete (CRUD) operations and HTTP methods as follows:

Retrieve a resource with GET.
Create a resource on the service with POST.
Update a resource with PUT.
Remove a resource with DELETE.

Create a Resource (POST)

The correct way to create a resource is by using the HTTP POST method. All the parameter names and values are contained in XML tags. The payload, an XML representation of the entity to create, is sent in the body of an HTTP POST whose request URI is the intended parent of the entity as shown in the next example.

POST /croissant HTTP/1.1
Host: myserver 
Content-Type: application/xml 
<?xml version="1.0"?> 
  <croissant>
    <name>chocolate-truffle</name>
  </croissant>

The previous example shows a correct RESTful request which uses HTTP POST and includes the payload in the body of the request.

On the service, the request may be processed by adding the resource contained in the body as a subordinate of the resource identified in the request URI; in this case the new resource should be added as a child of /croissants. This containment relationship between the new entity and its parent, as specified in the POST request, is analogous to the way a file is subordinate to its parent directory. The client sets up the relationship between the entity and its parent and defines the new entity’s URI in the POST request.

For more information, see When to use POST.

Retrieve a Resource (GET)

A client application may get a representation of the resource (chocolate-truffle) using the URI, noting that at least logically the resource is located under /croissant, as shown in the next GET request.

GET /croissant/chocolate-truffle HTTP/1.1
Host: myserver
Accept: application/xml

This is an explicit use of GET which is for data retrieval only. GET is an operation that must be free of side effects, this property is also known as idempotence.

For more information, see When to use GET.

Warning

Some APIs use GET to trigger transactions on the server for example, to add records to a database. In these cases the GET request URI is not used properly as shown next:

GET /addcroissant?name=chocolate-truffle HTTP/1.1

This is an incorrect design because GET request has side effects. If successfully processed, the result of the request is to add a new croissant type to the data store. The following are the problems with this design:

Semantic problem. Cloud services are designed to respond to HTTP GET requests by retrieving resources that match the path (or the query criteria) in the request URI and return a representation in a response, not to add a record to the database. This is an incorrect use of GET that is not compliant with of HTTP/1.1 protocol, using GET.
Unintentional side effects. By triggering a change in the server-side state, could unintentionally allow Web caching tools (crawlers) and search engines to make server-side changes simply by crawling a link.

Update a Resource (PUT)

You use HTTP PUT request to update the resource, as shown in the following example:

PUT /croissant HTTP/1.1 
Host: myserver 
Content-Type: application/xml 
<?xml version="1.0"?>
<croissant>
    <name>chocolate-truffle</name>
</croissant>

The use of PUT to update the original resource provides a clean interface consistent with the definition of HTTP methods. The PUT request is proper for the following reasons:

It identifies the resource to update in the URI.
The client transfers a new representation of the resource in the body of the request.

For more information, see When to use PUT.

References

Designing well-formed URIs for your REST Web API (micheltriana.com)
API Layer and its responsibilities – a REST viewpoint (byterot.blogspot.com)
RESTful Web Services Cookbook
A Beginner’s Tutorial for Understanding and Implementing ASP.NET Web API (codeproject.com)

Cloud Readiness Design Guidelines

Leave a reply

These guidelines help creating cloud ready applications and suggest best practices. Background information and relevant links are included.
The goal is to provide information that can help the transition from a desk-top or a virtual environment to the cloud.

At first, this transition can seem daunting. But, once you have mastered the details, it becomes obvious and natural how to make the “paradigm shift”.
The good news is that the rewards are great. This is because the cloud is not a fad but a solution for real world problems. Problems such as resource availability , resources utilization and provisioning , handling of peak request traffic , failure handling, cost of over-estimation , and so on.

If we have to pinpoint the main architectural principle, we must say that the cloud is predicated on delivering IT services on demand. An extension of this is the concept of application as a service (usually, a REST Web service). The result is software architectures with qualities such as: elasticity, auto-scaling, fault tolerance and administration automation.

Virtualization Versus Cloud

Before diving into the details of the cloud environment, let’s look into the differences with virtualization. The two environments look similar but they are very different in approach and philosophy.

Virtualization handles the physical infrastructure which supports many standard applications mainly because physical servers are converted into virtual ones without difference in architecture. Applications that run in a virtual environment scale vertically meaning that to improve their performance, for example, more resources are added to the infrastructure without direct intervention on the part of an application.
The cloud handles the logical infrastructure such as resource management, dynamic scaling, and so on which allow flexibility, automation, and massive scaling on demand. Applications that run in the cloud scale horizontally meaning that to improve their performance, for example, more copies of an application are created and, if needed, more commodity servers are provisioned automatically using the cloud API. This scaling is dynamic and requires the intervention on the part of the application.

In virtualization and private cloud the physical infrastructure is a concern for an organization, while in a public cloud the concern is shifted to the cloud service provider. However, in private or public clouds, far reaching implications exist. For example, in a virtualized environment, applications rely on the redundancy of the infrastructure layer for transparent failover. In contrast, in a cloud environment, the applications themselves must recover from failures.
The architectural differences between the two computing environments are highlighted next.

Virtualization

The architecture follows a “hub-spoke” approach where Virtual Machines (VMs) report to a central controller or hub. This implies that there is a single “point of contention” which limits the scale that can be obtained. The following are the main characteristics:

Redundancy. It is obtained through clustering of hypervisors for high availability. Also multiple levels of redundancy are achieved via redundant hardware components. Fault tolerance is achieved via live migration(without intervention on the part of the application).
Scaling. This is vertical scaling where multiple backup systems in the infrastructure enable redundancy and performance improvement. These systems are expensive to build and there is a limit to the scale that can be obtained.
State. The application state can be effectively managed on a single server. The infrastructure such as load balancer can be used to manage stateful connections.

Cloud

The architecture follows a “shared-nothing” approach or “shard” approach. This implies that VMs are independent from each other and no single point of contention exists. This allows massive scale by simply adding commodity hardware. The following are the main characteristics:

Redundancy. Redundancy must be built in the application, do not expect it from the infrastructure. Fault tolerance must be a concern and cannot be delegated to the underlying infrastructure.
Scaling. This is horizontal scaling obtained by adding or subtracting VMs to affect performance. In theory, there is no limit to scalability. If one machine dies it is simply replaced with a new one. The application should make use of this capability by adding or removing more VMs as needed.
State. A cloud environment is not inherently redundant, so an application cannot rely on the infrastructure to handle state information. If a virtual machine dies, for example, an application must allow for a seamless transition.

Virtualized Environment

Shared resources
VM instances must report to a central hub to operate
Failure and performance management via vertical scaling achieved through redundancy of the infrastructure layer via multiple levels of hardware redundancy
Support for live migration to handle failure
Stateful applications which require the infrastructure, such as the load balancer, to manage stateful connections

Cloud Environment

Each VM instance is independent and self-sufficient
Failure and performance management via horizontal scaling achieved through redundancy of the application layer across multiple VMs in different regions and availability zones
Horizontal scaling at application layer to manage failures: if one application dies it is simply replaced by another
Stateless applications that are architected to manage their own state information
No ability to change CPU or storage capabilities in a provisioned VM instance
VM instance must be terminated and a new one must be created with different configuration
Instance re-imaging is not allowed– pre-defined flavors combined with self-service provisioning means an instance can be terminated and re-provisioned with the required OS image
Data is not persistent, that is if a VM dies all data stored in its storage area is lost. If data must persist, than external (to the VM) storage must be used.

Notes

Cloud VMs can be created and deleted dynamically (through UI or command line tools).

The redundancy is an attribute of a cloud application and not of the infrastructure, as in the virtualized environment.

The cloud provides a new approach on how to design scalable, high available applications and handle failures.

The architecture of cloud applications follows the Representational State Transfer (REST) guidelines.

Elasticity

Traditional virtualized infrastructure generally necessitates predicting the amount of computing resources applications will use over a period of several years. If resources are under-estimated, applications will not have the horsepower to handle unexpected traffic. If over-estimated, money is wasted on superfluous resources.

However, the on-demand and automated elasticity of the cloud enables the infrastructure to be closely aligned (as it expands and contracts) with the actual demand, thereby increasing overall utilization and reducing cost.
Elasticity is one of the fundamental properties of the cloud – the power to scale computing resources up and down easily and with minimal friction. As a software developer building applications for the cloud, one needs to internalize this concept and work it into the application architecture in order to take maximum benefit of the cloud.

Best Practices

Intelligent elastic cloud architecture allows resources to be utilized only when needed. Elasticity should be an application architectural design requirement.

Identify what components or layers in an application can be elastic
Determine what it takes to make the components elastic and the impact on the application architecture
An elastic application must be redundant, which is it must be designed for replication over any number of machines (virtual machines that is) in different availability zones and regions
An elastic application must be stateless

Elasticity can be implemented in one of the following ways:

Proactive cyclic scaling. Periodic resource scaling occurs at fixed interval (daily, weekly and so on)
Proactive event based scaling. Resources scaling is planned in relation to specific events such as new product launch, marketing campaigns and so on.
Auto-scaling based on demand. Using a monitoring service, triggers are issued to take appropriate actions to scale resources up or down based on metrics such as utilization of servers, network I/O and so on.

Icon

To implement elasticity it is essential to automate the deployment process and streamline the configuration and build process. This assures that a system can scale without human intervention. For more information, see the Scalability and Administering Cloud Resources sections.

Notes

Elasticity refers to the cloud’s ability to scale. The following are examples of elastic applications:

Web Site

A service provider runs a website on the cloud. At beginning, the website runs on a single virtual machine. The site suddenly becomes popular, and more virtual machines are needed to handle the increased load. An elastic system immediately detects this condition and provisions additional virtual machines to handle incoming traffic scaling the service seamlessly.

Payment Gateway

The previous web site allows access to a payment gateway service that suddenly is overloaded by customer requests. The elastic payment gateway service is cloned as many times as needed to handle the spike in the customer requests. Elastic applications can allocate and de-allocate resources (VMs) on demand for specific application components. Moreover, an application must be stateless to allow replication and handling of conditions such as peak traffic.

Scaling

The cloud infrastructure provides “unlimited” horizontal scaling. However, to take advantage of this feature, application architectures must also be scalable.

Best Practices

Identify monolithic components and bottlenecks
Refactor the application to take advantage of the infrastructure scalability
Assure that the application architecture is based on loosely coupled components where components interact asynchronously and see each other as black boxes
Design every component as follows:
- Exposes a service interface
- Is responsible for its own scalability
- Interacts with other components asynchronously
- Is stateless and stores session state information externally (in a database, if needed)

Notes

The more loosely coupled the application components are the greater and better the application scales. If components do not have tight dependencies, if one fails or is unresponsive the others continue to work.

Loosely coupled applications can be implemented using cloud messaging queue services. If a queue/buffer is used to connect any two components, it can support concurrency, high availability and load spikes.
In a web application, for example, this implies isolating the app server from the web server and from the database server.

Asynchronous applications and scaling horizontally are key cloud properties. They allow adding more instances of the same component. They also allow the design of innovative hybrid models where a few components continue to run on-premise while others can use the cloud for additional compute power and bandwidth. In this way, you can overflow excess traffic to the cloud through smart load balancing strategy.

Auto-scaling allows automatically launching or terminating compute instances based on user-defined policies, health status checks, and schedules. Compute resources are servers in the cloud. For applications configured to run on a cloud infrastructure, scaling is an important part of resource management and cost control.

Failure Handling

An application must be able to handle hardware and software failures. Incorporate this thinking in the application architecture to make it fault-tolerant and optimized for the cloud. The following are some common failures that applications must be able to handle:

Hardware Failure

What happens if a VM fails?
How to recognize the failure and recover from it?
What are the single points of failure?
If there are master and worker servers in the system, what happens if the master fails?

Software Failure

What happens if the dependent service changes the interface?
What happens if the downstream service times out or issues an exception?
What happens if the cache grows beyond the memory limit of an instance?

Best Practices

Have a coherent backup and restore strategy and automate it.
Build process threads that resume on reboot.
Allow the system state to be restored by reloading messages from the queues.
Have your app deployment process automated.
Avoid in memory sessions or stateful user context; move related information to data stores.
Assure application high availability by utilizing multiple availability zones.
Fail over gracefully.

Notes

An application should be impervious to reboots that is it should be brought up and resume the previous state without any problem.
For example, if the instance on which a controller thread was running dies, it can be brought up and resume the previous state as if nothing had happened. This can be accomplished by the automated application deployment process.

If a VM fails, application traffic will be rerouted to a different machine perhaps in a different region. When auto scaling is enabled, new machines are automatically provisioned if needed. This relies on an automated deployment process.

It is the responsibility of the developer to assure that an application can be distributed.

High Availability

Regions are logically similar to data centers. By deploying an application to multiple regions, its high availability is assured. Regions can support multiple availability zones which are physically separated from each other and can also help achieve high availability for an application within a region.

Graceful Failover

Graceful failover can be achieved through elastic IP addresses. Elastic IP addresses allow handling of instance or availability zone failures by programmatically remapping public IP addresses to any instance associated with an account. In this way, the traffic of a failed application can be gracefully rerouted.

Data Location

It is good practice to keep the data as close as possible to the application to reduce access latency. In the cloud, this practice is even more important because of the additional internet latency.

Best Practices

Dynamic Data

Data generated in the cloud: The application that consumes the data should also be deployed in the cloud so that it can take advantage of in-cloud free data transfer and lower latency.

Data outside the cloud: If a large quantity of data resides outside of the cloud, it might be cheaper and faster to transfer the data to the cloud first and then perform the computation.

Static Data

If the data is static and does not change often (for example, images, video, audio, PDFs, JS, CSS files), it is advisable to use a Content Delivery Network (CDN) so that the static data is cached at an edge location closer to the end-user (requester), thereby lowering the access latency.

Notes

The data location can reduce the cost of the gigabytes of data transfered. The following are some examples of dynamic data location strategies:

Data warehouse. It is advisable to move the dataset to the cloud and then perform parallel queries against the dataset.
Web app. If the web application stores and retrieves data from relational databases, it is advisable to move the database as well as the app server into the cloud all at once.
E-commerce app. In the case of an e-commerce web application that generates logs and clickstream data, it is advisable to run the log analyzer and reporting engines in the cloud.

Parallel Processing

Whether requesting, storing or processing data in the cloud. Whenever possible, parallelization and related automation are encouraged. The cloud supports parallel processing in a way that virtualized systems cannot. This is because it can achieve the required computing power by dynamically commissioning (or de-commissioning) VMs using commodity hardware.

Best Practices

Accessing Data

The cloud supports massively parallel operations, when retrieving and accessing data. For example, the operations required to perform analytics on unformatted big data where concurrent processes are used to store or fetch data rather than performing sequential operations (which would be impossible).

Processing Tasks

When processing or executing requests in the cloud, it is even more important to take advantage of parallelization. The following are some examples:

Web Application. A general best practice is to distribute the incoming requests across multiple asynchronous servers using a load balancer.

Batch Processing. A master VM can spawn multiple worker VMs that process tasks in parallel (as in the distributed Hadoop framework).

Notes

Wherever possible, the processes of a cloud application should be made thread-safe through a shared-nothing philosophy and leveraging multi-threading.
The cloud operates at its best when an application can combine elasticity and parallelization. For example, an application can do the following:

Provision, in a few minutes and via simple API calls, a cluster of VM instances.
Execute parallel tasks to perform a specific job.
Store the results.
Terminate all the VM instances.

Administering Cloud Resources

When moving to the cloud, a system administrator may not have the ability to specify resources at the level of physical details, as in a virtual environment. For this reason, it is important to understand the concept of abstract resources to be able to handle the actual physical capabilities of the cloud environment and manage them.

Best Practices

An important aspect of using a cloud environment is the ability to use the cloud APIs, the UI or command line tools to automate the deployment process.
An automated and repeatable process will help in reducing errors and facilitate an efficient and scalable update. In fact, automation is essential for scalability to work. This is the area where the cooperation between developers and administrators is crucial if the cloud must operate reliably and effectively.
To automate the deployment process, follow these guidelines:

Create a library of recipes. These are small and frequently used scripts for installation and configuration.
Manage the configuration and deployment process by using agents bundled with a VM image.
Bootstrap the instances. This allows an instance to obtain the necessary resources such as code, script and configuration based on its role and attaches itself to a cluster to perform its function.

Notes

In the last decade a typical business application has evolved from desk-top centric, to client-server, to web services, and on to service oriented architecture (SOA). In this evolution, abstraction of computing resources has become prominent to reduce costs and improve reliability of IT operations.

Abstraction is at the core of the cloud computing paradigm. Within the cloud, organizations can consume shared computing and storage resources rather than building, operating and maintaining infrastructures.

In the traditional enterprise company, application developers may not work closely with the network administrators and network administrators may not have a clue about the application. As a result, several possible optimizations in the network layer and application architecture layer are overlooked. With the cloud, the two roles have merged into one to some extent. When architecting future applications, companies need to encourage more cross-pollination of knowledge between the two roles and understand that they are merging.

In a cloud environment, a system administrator no longer provisions servers, installs software, or wires network devices. Because the underlying infrastructure is programmable, the cloud encourages automation. In this context, the administrator manages the underlying cloud resources while the developer automates server provisioning, software installation, and network “wiring”.

Security

Legitimate concerns about security exist in the cloud shared resources (multitenant) environment. Security must be implemented at every layer of the cloud application architecture.

Best Practices

Protect Data in Transit (“Encrypt Everything”)

When data is in transit, between a browser and a web server for example, configure Secure Sockets Layer(SSL) on your server instance.
Create a Virtual Private Cloud (VPC) to use logically isolated resources within the service provider cloud. Connect those resources directly to your own datacenter using industry standard encrypted IPsec Virtual Private Network (VPN) connections

Protect Data at Rest (“Encrypt Everything”)

Encrypt sensitive data (individual files) prior uploading it to the cloud.
Encryption depends on the operating system installed on the server instance. A variety of encrypting tools and techniques exist. Select the ones that best satisfy your requirements.
Protect your data not only from eavesdropping but also from disaster. Take periodic snapshots of your data to ensure it is highly durable and available. You can use the cloud service provider “endless” storage capabilities where the snapshots are incremental.

Secure the Application

Security Groups

A server instance is protected by security groups whose rules specify which incoming network traffic can be delivered to the instance. TCP and UDP ports can be specified as long as ICMP types and codes and source addresses. Security groups provide basic firewall-like protection for running instances.

Software-Based Firewalls (aka. Host-Based Firewalls)

Another way to restrict traffic to a server instance is via software-based firewalls. Windows instances can use the built-in firewall. Linux instances can use netfilter and iptables.

Notes

Physical Security

This is typically handled by the cloud service provider.

Network and Application Security

This is the responsibility of the developer that uses the cloud service and the application designer
Tools created by cloud services providers can help to implement basic security
Best practices as they apply to the business must be followed

Glossary

Cloud Computing

Cloud computing is a model for enabling convenient, on-demand network access to a shared pool of configurable computing resources (e.g., networks, servers, storage, applications, and services) that can be rapidly provisioned and released with minimal management effort or service provider interaction. The cloud model of computing promotes availability (NIST).

Elasticity

In cloud computing, elasticity is defined as the degree to which a system is able to adapt to workload changes by provisioning and de-provisioning resources in an autonomic manner, such that at each point in time the available resources match the current demand as closely as possible ^.

Horizontal Scaling

Horizontal scaling, or increasing the number of servers in the cluster, reduces the responsibilities of each server. The capacity of each server does not change, but its load is decreased. Reasons to scale horizontally include increasing I/O concurrency, reducing the load on existing servers, and increasing disk capacity.

Hybrid Cloud

Hybrid Clouds combine both public and private cloud models. With a Hybrid Cloud, service providers can utilize third party cloud providers in a full or partial manner thus increasing the flexibility of computing. The Hybrid cloud environment is capable of providing on-demand, externally provisioned scale. The ability to augment a private cloud with the public cloud can be used to manage any unexpected surges in workload.

Live Migration

Live migration is the relocation of a virtual machine from one physical host to another while continuously powered-up. When properly carried out, this process takes place without any noticeable effect from the point of view of the end user. Live migration allows an administrator to take a virtual machine offline for maintenance or upgrading without subjecting the system’s users to downtime.
Live migration can also be used for load balancing, in which work is shared among computers in order to optimize the utilization of available CPU resources.

REST

The majority cloud services (and related APIs) are designed using an architectural style known as

Representational State Transfer (REST).This style is widely used and is a simpler alternative to SOAP and related Web Services Description Language (WSDL).
Capitalizing on the Web success and based on its semantics, REST formalizes a set of principles by which you can design cloud services to access system’s resources, including how resource states are addressed and transferred over HTTP by a wide range of clients. As first described by Roy Fielding in his seminal thesis Architectural Styles and the Design of Network-based Software Architectures, REST is a set of software architectural principles that use the Web as a platform for distributed computing . Since then, REST has emerged as the predominant Web service design model.

Scalability

It is the ability of a system, network, or process to handle a growing amount of work in a capable manner or its ability to be enlarged to accommodate that growth. For example, it can refer to the capability of a system to increase its total output under an increased load when resources (typically hardware) are added.

Private Cloud

Private clouds are built exclusively for a single enterprise. They aim to address concerns on data security and offer greater control, which is typically lacking in a public cloud. There are two variations to a private cloud:

On-premise Private Cloud. On-premise private clouds, also known as internal clouds are hosted within an organization’s own data center. This model provides a more standardized process and protection, but is limited in aspects of size and scalability. IT departments would also need to incur the capital and operational costs for the physical resources. This is best suited for applications which require complete control and configurability of the infrastructure and security.
Externally hosted Private Cloud. This type of private cloud is hosted externally with a cloud provider, where the provider facilitates an exclusive cloud environment with full guarantee of privacy. This is best suited for enterprises that don’t prefer a public cloud due to sharing of physical resources.

Public Cloud

Public clouds are owned and operated by third parties; they deliver superior economies of scale to customers, as the infrastructure costs are spread among a mix of users, giving each individual client an attractive low-cost, “Pay-as-you-go” model. All customers share the same infrastructure pool with limited configuration, security protections, and availability variances. These are managed and supported by the cloud provider. One of the advantages of a Public cloud is that they may be larger than an enterprises cloud, thus providing the ability to scale seamlessly, on demand.

Virtual Machine

A virtual machine (VM) is a software implementation of a computing environment in which an operating system or program can be installed and run.
The virtual machine typically emulates a physical computing environment, but requests for CPU, memory, hard disk, network and other hardware resources are managed by a virtualization layer which translates these requests to the underlying physical hardware.
VMs are created within a virtualization layer, such as a hypervisor or a virtualization platform that runs on top of a client or server operating system. This operating system is known as the host OS. The virtualization layer can be used to create many individual, isolated VM environments.

Vertical Scaling

Vertical scaling gives greater capacity (CPUs, memory and so on) to a server but does not decrease its overall load. Reasons to scale vertically include increasing IOPS, increasing CPU/RAM capacity, and increasing disk capacity.

Virtualization

Virtualization refers to the creation of a virtual resource such as a server, desktop, operating system, file, storage or network. The main goal of virtualization is to manage workloads by radically transforming traditional computing to make it more scalable. Virtualization has been a part of the IT landscape for decades now, and today it can be applied to a wide range of system layers, including operating system-level virtualization, hardware-level virtualization and server virtualization.

References

Virtualization versus Cloud
1. Architectural Styles and the Design of Network-based Software Architectures
2. Cloud and Virtualization
Elasticity
Scalability
Failure Handling
Data Location
1. AWS Import/Export
2. Sneakernet
Parallel Processing
Administering Cloud Resources
Security

Cloud Introduction

Leave a reply

Overview

The Cloud is a computing model for enabling ubiquitous, convenient, on-demand network access to a shared pool of configurable computing resources (e.g., networks, servers, storage, applications, and services) that can be rapidly provisioned and released with minimal management effort or service provider interaction. For more information, see The NIST Definition of Cloud Computing .

This is a technological breakthrough compared to the traditional approach where resources had to be allocated in advance with the danger of overestimating (or underestimating) the needs.

But, most importantly, in the cloud the allocation is done automatically and in real-time. This is the elasticity attribute of the cloud. The cloud main architectural principle is predicated on delivering IT services on demand. The result is software architectures with qualities such as: elasticity, auto-scaling, fault tolerance and administration automation.

An extension of this is the concept of application as a service usually, a REST web service.For more information about designing for the cloud, see Cloud Ready Design Guidelines .

From a hardware point of view, three aspects are new in cloud computing:

The “infinite” computing resources available on demand, thereby eliminating the need for users to plan far ahead for provisioning
The elimination of an up-front commitment by the users, thereby allowing companies to start small and increase hardware resources only when there is an increase in their needs
The ability to pay for use of computing resources on a short-term basis as needed (e.g., processors by the hour and storage by the day) and release them as needed, thereby rewarding conservation by letting machines and storage go when they are no longer useful.

You may want to take a look at the following video to understand the difference between cloud and traditional virtualization: Cloud and Virtualization.

Cloud Deployment and Service Models

Deployment models define different types of ownership and distribution of the resources used to deliver cloud services to different customers.

Deployment Models

Cloud environments may be deployed over a private infrastructure, public infrastructure, or a combination of both.

The most common deployment models as defined by the National Institute of Standards and Technology (NIST) include the following:

Private cloud. The cloud infrastructure is operated solely for a single organization (client). It may be managed by the organization itself or a third-party provider, and may be on-premise or off-premise. However, it must be solely dedicated for the use of one entity.
Community cloud. The cloud infrastructure is shared by several organizations and supports a specific community with shared requirements or concerns (for example, business model, security requirements, policy, or compliance considerations). It may be managed by the organizations or a third party, and may be on-premise or off-premise.
Public cloud. The cloud infrastructure is made available to the general public or a large industry group and is owned by a cloud provider (an organization selling cloud services). Public cloud infrastructure exists on the premises of the cloud provider.
Hybrid cloud. The cloud infrastructure is a composition of two or more clouds (private, community, or public) that remain unique entities but are bound together by technology to enable portability. Hybrid clouds are often used for redundancy or load-balancing purposes. For example, applications within a private cloud could be configured to utilize computing resources from a public cloud as needed during peak capacity times.

Service Models

Service models identify different control options for the cloud client and cloud provider. For example, SaaS clients simply use the applications and services provided by the provider, where IaaS clients maintain control of their own environment hosted on the provider’s underlying infrastructure. The following are the most commonly used service models:

Software as a Service (SaaS). It enables the end user to access applications that run in the cloud. The applications are accessible from various client devices through a thin interface such as a web browser. Some examples are:
Platform as a Service (PaaS). It enables the deployment of applications in the cloud. These applications are created using programming languages and tools supported by the cloud provider. Some examples are:
1. Google App Engine
2. AWS Elastic Beanstalk
Infrastructure as a Service (IaaS). It enables the provisioning of compute processing, storage, networks and other computing resources to deploy and run applications. You cannot control the underlying physical infrastructure though.Some examples are:

The following picture depicts the service models and the way they stack up:

You can find the above picture and more information at NIST Cloud Computing Reference Architecture.The next picture shows the control and responsibilities for cloud clients and providers across the service models:

Cloud Logical Architecture

The cloud architecture is structured in layers. Each layer abstracts the one below it and exposes interfaces that layers above can build upon. The layers are loosely coupled and provide horizontal scalability (they can expand) if needed. As you can see in the next picture, the layers map to the service models described earlier.

As shown in the previous picture, the cloud architecture contains several layers, as described next.

Hosting Platform. Provides the physical, virtual and software components. These components include servers, operating system, network, storage devices and power control and virtualization software. All these resources are abstracted as virtual resources to the layer above.The virtual machine (VM) is at the core of the cloud virtualization. It represents a software implementation of a computing environment in which an operating system and other apps can run. The virtual machine typically emulates a physical computing environment, but requests for CPU, memory, hard disk, network and other hardware resources are managed by a virtualization layer which translates these requests to the underlying physical hardware.
VMs are created within a virtualization layer, such as a hypervisor that runs on top of a client or server operating system. This operating system is known as the host OS. The virtualization layer can be used to create many individual, isolated VM environments.
Infrastructure Services. The important function of this layer is to abstract the hosting platform as a set of virtual resources and to manage them based on scalability and availability. The layer provides three types of abstract resources: compute, storage and network. It also exposes a set of APIs to access and manage these resources. This enables a user to gain access to the physical resources without knowing the details of the underlying hardware and software and to control them through configuration. Services provided by this layer are known as Infrastructure as a Service (IaaS).
Platform Services. Provides a set of services to help integrating on-premise software with services hosted in the cloud. Services provided by this layer are known as Platform as a Service (PaaS).
Applications. Contains applications built for cloud computing. They expose web interfaces and services and enable multitenant hosting. Services provided by this layer are known as Software as a Service (SaaS).

The vertical bars in the picture represent components that apply to all layers with different degrees of scope and depth. Mainly they support administrative functions, handling of security and cloud programmability (the later supporting the most common programming languages).

References

Cloud Computing Services Taxonomy

2 Replies

In this topic you will learn about cloud computing services taxonomy. For each category of services, links and quick summaries are provided. This should give you a road map that might help to untangle a web (pun intended) of words and acronyms. So, brace yourself for this wide dive in a fascinating topic.

Category	Description
Compute Services	Provide dynamically scalable compute capacity
Storage Services	Allow storage and retrieval of any data, at any time from anywhere
Database Services	Allow to configure and operate relational or non-relational databases.
Application Services	Provide services such as application runtimes and frameworks, queuing, email, notification and media services.
Content Delivery Services	Serve content to end users with high availability and performance.
Analytics Services	Allow analyzing massive data sets stored either in cloud storages or cloud databases.
Deployment and Management Services	Allow to deploy and manage applications in the cloud.
Idendity and Access Management Services	Allow managing authentication and authorization of users in order to provide secure access to cloud resources.

Compute Services

The compute services provide dynamically scalable compute capacity which allow the following:

Creation of virtual machines from standard images, provided by the compute service provider, such as Ubuntu image, Windows image and so on. Custom images can also be created. A machine image is a template for an operating system, application server and applications.
Service access via a Web interface for provisioning, managing and monitoring tasks.
Interaction with the service via various programming language APIs.

The following are some of the most common compute services and their main characteristics.

Service Name	Description
Amazon Elastic Compute Cloud (EC2)	This is a web service that provides resizable compute capacity in the cloud allows to perform the following: Create a virtual machine instance and select your Amazon Machine Image (AMI). Specify the instance size: micro, small, medium, large and so on. Establish the number of instances to launch based on the AMI and zone availability. Define the metadata tags to simplify the administration of the of EC2 instances. Select a key pairs to securely connect to an instance. An EC2 instance has one public Domain Name System (DNS) and Internet Protocol (IP) address and one private DNS and IP. The public DNS can be used to connect securely to an instance via Secure Shell (SSH).
Google Compute Engine	This is a web service that enables users to create and manage compute instances. It allows the following: Create a virtual machine instance and select a machine image for the instance. Select a zone in which the instance must be activated. Provide instance name, instance tags and metadata. Every instance has a disk resource and depending on the instance the disk can be: A scratch disk which is deleted when the machine instance terminates. A persistent disk which persists beyond the life of an instance. Network options allow to control instance traffic. By default, traffic between instances in the same network is enabled. You can enable other connections, using additional firewall rules.
Windows Azure Virtual Machines	This is a web service that enables users to create and manage compute instances. It allows the following: Create a virtual machine instance and select machine image and instance type. Provide user name and password or upload a certificate for securely connecting to the instance. Any changes made to a virtual machine are persistently stored. New virtual machines can be created from previously stored machine images.

Service Name

Description

Amazon Elastic Compute Cloud (EC2)

This is a web service that provides resizable compute capacity in the cloud allows to perform the following:

Create a virtual machine instance and select your Amazon Machine Image (AMI).
Specify the instance size: micro, small, medium, large and so on.
Establish the number of instances to launch based on the AMI and zone availability.
Define the metadata tags to simplify the administration of the of EC2 instances.
Select a key pairs to securely connect to an instance.

An EC2 instance has one public Domain Name System (DNS) and Internet Protocol (IP) address and one private DNS and IP. The public DNS can be used to connect securely to an instance via Secure Shell (SSH).

Google Compute Engine

This is a web service that enables users to create and manage compute instances. It allows the following:

Create a virtual machine instance and select a machine image for the instance.
Select a zone in which the instance must be activated.
Provide instance name, instance tags and metadata.

Every instance has a disk resource and depending on the instance the disk can be:

A scratch disk which is deleted when the machine instance terminates.
A persistent disk which persists beyond the life of an instance.

Network options allow to control instance traffic. By default, traffic between instances in the same network is enabled. You can enable other connections, using additional firewall rules.

Windows Azure Virtual Machines

This is a web service that enables users to create and manage compute instances. It allows the following:

Create a virtual machine instance and select machine image and instance type.
Provide user name and password or upload a certificate for securely connecting to the instance.

Any changes made to a virtual machine are persistently stored. New virtual machines can be created from previously stored machine images.

Storage Services

The storage services allow storage and retrieval of any data, at any time from anywhere. The majority of the services organize the data in buckets (containers) which store objects (individual pieces of data).

The following are some of the most common storage services and their main characteristics.

Service Name	Description
Amazon Simple Storage Service (S3)	This web service provides a cloud based infrastructure for storing and retrieving any amount of data. The following are its main characteristics: Highly reliable, scalable, fast and fully redundant affordable storage. Data stored on S3 is organized in buckets. You must create a bucket before storing any data. Ability to upload any kind of file. Support for redundancy, encryption options and access permissions.
Google Cloud Storage	This is a web service for storing and retrieving any amount of data. The following are its characteristics: The service uses Google’s proprietary network and datacenter technology. Google spent several years building proprietary infrastructure and technology to power Google’s sites, When you use the service, the same network goes to work for your data. The service replicates data to multiple data centers and serves end-user’s requests from the nearest data center that holds a copy of the data. You have a choice of regions (currently U.S. and Europe) to allow you to keep your data close to where it is most needed. Data is also replicated to different disaster zones to ensure high availability. When you upload an object and mark it as cacheable (by setting the standard HTTP Cache-Control header), The service automatically figures out how best to serve it using Google’s broad network infrastructure, including caching it closer to the end-user if possible.
Windows Azure Storage	This web service provides various storage capabilities such as blob storage, table and queue services. The blobs have the following properties: They are organized into containers. There are two kinds of blobs: block and page blobs. A block blob can be divided into some number of blocks. If failure occurs while transferring a blob, retransmission can resume with the most recent block. Page blobs are divided into some number of pages, which are designed for random access.

Service Name

Description

Amazon Simple Storage Service (S3)

This web service provides a cloud based infrastructure for storing and retrieving any amount of data. The following are its main characteristics:

Highly reliable, scalable, fast and fully redundant affordable storage.
Data stored on S3 is organized in buckets. You must create a bucket before storing any data.
Ability to upload any kind of file.
Support for redundancy, encryption options and access permissions.

Google Cloud Storage

This is a web service for storing and retrieving any amount of data. The following are its characteristics:

The service uses Google’s proprietary network and datacenter technology. Google spent several years building proprietary infrastructure and technology to power Google’s sites, When you use the service, the same network goes to work for your data.
The service replicates data to multiple data centers and serves end-user’s requests from the nearest data center that holds a copy of the data. You have a choice of regions (currently U.S. and Europe) to allow you to keep your data close to where it is most needed. Data is also replicated to different disaster zones to ensure high availability.
When you upload an object and mark it as cacheable (by setting the standard HTTP Cache-Control header), The service automatically figures out how best to serve it using Google’s broad network infrastructure, including caching it closer to the end-user if possible.

Windows Azure Storage

This web service provides various storage capabilities such as blob storage, table and queue services. The blobs have the following properties:

They are organized into containers.
There are two kinds of blobs: block and page blobs.
A block blob can be divided into some number of blocks.
If failure occurs while transferring a blob, retransmission can resume with the most recent block.
Page blobs are divided into some number of pages, which are designed for random access.

Database Services

The database services allow to operate relational and non-relational databases in the cloud. An important advantage is that they relieve an application developer from time consuming administration tasks. The following are some of the database services provided:

Relational databases. They include MySQL, Oracle, SQL Server and so on.
Non-relational databases. They include mostly proprietary solutions. They are fully managed to deliver seamless throughput and scalability.

The following are some of the most common database services and their main characteristics.

Service Name	Description
Amazon Relational Data Store (RDS)	Relational database web service. It enables the user to easily configure, operate and scale a relational database in the cloud. The related console allows the following: Select the type of database to create such as MySQL, Oracle, or SQL Server. Define database size, allocated storage, database identifier. Define user name and password. The database instance has an end point that the user can use to securely connect to the instance.
Amazon DynamoDB	Non-relational database service. It includes tables, items and attributes. The following are its main characteristics: A table is a collection of items. Each item is a collection of attributes. To store data you must create one or more tables and specify how much throughput must be provisioned for reading and writing operations. The service is fully managed and automatically distributes the data and the traffic over a number of servers to meet the throughput requirements. All the stored data is automatically replicated across multiple zones to allow for durability.
Google Cloud SQL	Relational database service which allows the user to host MySQL database in the cloud. The following are its main characteristics: Synchronous and asynchronous geographic replication. Ability to import and export databases. Selection of a region, database tier, billing plan and replication modality. Scheduling daily backups and restoring backups.
Google Cloud Datastore	Fully managed non-relational database service. The following are its main characteristics: ACID transactions and high availability of read and write operations. Data model consists of entities. Each entity has one or more properties. Properties (key-value pairs) can be of one supported data types. Each property has a kind and a key. The key uniquely identifies the entity, while the kind is used to categorize the entity for query purposes.
Windows Azure SQL Database	Relational database service which is based on the SQL server. The following are its main characteristics: The SQL database is a multi-tenant service. Each customer has a logical SQL server assigned.
Windows Azure Table Service	Non-relational database service which consists of tables having multiple entities. The following are its characteristics: The tables are divided in a number of partitions. Each partition can be stored on a different machine. A partition holds a specified number of entities each containing several properties. Each property can be one of the several supported data types. Tables do not have a fixed schema, so different entities in table can have different properties.

Application Services

The application services provide services such as application runtimes and frameworks, queuing, email, notification and media services.

The following are some of the most common application services and their main characteristics.

Service Name	Description
Application Runtimes and Frameworks services allow developers to build and host apps in the cloud. The runtimes provide the following: Support for programming languages such as Java, Python, Ruby and so on. Automatically allocate resources. Handle scaling without the need to run and maintain servers.
Google App Engine	This platform as a service (PaaS) includes an application runtime and a web framework. Its main characteristics include: Runtimes. App Engine provides runtime environments for Java, Python, PHP, Go programming languages. Sandbox. Applications run in a secure sandbox environment isolated from other applications. Limited access to the underlying OS is allowed. Web Frameworks. App Engine provides a simple Python web application framework called webapp2. It also supports frameworks written in Python that use WSGI, which include Django, CherryPy, Pylons, web.py and web2py. Datastore. A no-SQL data storage service is provided. Memcache. High performance in-memory key-value cache service is provided. Tasks. App Engine provides task queues to allow work in the background. It also provides a cron service for scheduling.
Windows Azure Web Sites	This platform as a service (PaaS) allows hosting of web applications in the cloud. Its main characteristics include: Shared and standard options. In the shared option, a web site runs on virtual machines that can contain multiples sites by multiple users. In the standard option, a web site runs on virtual machines that belong to a single user. Applications written in ASP.NET, PHP, Node.js and Python are supported. Multiple copies of an application can run on different virtual machines and requests are automatically load-balanced among them.
Queuing Services allow the decoupling of application components by enabling them to communicate through messages queues. The following are the main queues advantages: They allow for asynchronous processing. Provide overflow buffers to handle temporary volume spikes or to handle the mismatch between message generation and consumption. Messages can be queued and read from queues simultaneously. The message latency can go from a couple of days to a couple of weeks.
Amazon Simple Queue Service (SQS)	Amazon Simple Queue Service (SQS) is a fast, reliable, scalable, fully managed message queuing service. SQS makes it simple and cost-effective to decouple the components of a cloud application. You can use SQS to transmit any volume of data, at any level of throughput, without losing messages or requiring other services to be always available. With SQS, you can offload the administrative burden of operating and scaling a highly available messaging cluster, while paying a low price for only what you use.To assure high availability for message delivery, SQS performs a trade-off on FIFO capability and does not guarantee that messages are delivered on first in first out (FIFO) order.
Google Task Queue Service	Tasks queues are an efficient and powerful tool for background processing; they allow your application to define tasks, add them to a queue, and then use the queue to process them in aggregate. You name queues and configure their properties in a configuration file named `queue.xml`.Push queues function only within the App Engine environment. These queues are the best choice for applications whose tasks work only with App Engine tools and services. With push queues, you simply configure a queue and add tasks to it. App Engine handles the rest. Push queues are easier to implement, but are restricted to use within App Engine. For more information about push queues and examples of how to use them, see Using Push Queues.
Windows Azure Queue Service	Windows Azure Queue allows decoupling of different parts of a cloud application, enabling cloud applications to be easily built with different technologies and easily scale with traffic needs. Windows Azure Queues The figure above illustrates a simple but common scenario for cloud applications. There are a set of web servers hosting the frontend logic of handling web requests. There are a set of backend processing servers implementing the business logic of the application. The web server frontend nodes communicate with the backend processing nodes via a set of queues. Persistent state of the application can be stored in Windows Azure Blob storage and Windows Azure Table storage.
Email Services allow applications hosted in the cloud to send emails.
Amazon Simple Email Service	Amazon Simple Email Service (Amazon SES) is a cost-effective outbound-only email-sending service built on the reliable and scalable infrastructure that Amazon.com has developed to serve its own customer base. With Amazon SES, you can send transactional email, marketing messages, or any other type of high-quality content and you only pay for what you use.Along with high deliverability, Amazon SES provides easy, real-time access to your sending statistics and built-in notifications for bounces and complaints to help you fine-tune your email-sending strategy.SES service can be accessed and used from the console, the Simple Mail Transfer Protocol (SMTP) interface, or the SES API.
Google Email Service	This service is part of the App Engine platform, which allows applications to send email messages on behalf of the app’s administrators, and on behalf of users with Google Accounts. Apps can receive email at various addresses. Apps send messages using the Mail service and receive messages in the form of HTTP requests initiated by App Engine and posted to the app. Apps can send messages using the Mail service and receive messages in the form of HTTP requests initiated by the App Engine and posted to the app.
Notification Services allow applications to push messages to Internet connected devices such as smartphones, tablets and so on.
test	test
Media Services provide various media service types used by applications to transform or transcode images, videos and so on.
test	test

Content Delivery Services

The content delivery services include Content Delivery Networks (CDNs). A CDN is a distributed system of servers located across multiple geographic locations to serve content to users with high availability and performance. CDNs are useful to serve static content and have a number of edge locations deployed in multiple locations. CDNs cache popular content on the edge servers which helps in reducing bandwidth costs and improving response time.

The following are some of the most common content delivery services and their main characteristics.

Service Name	Description
Amazon CloudFront	Amazon CloudFront is a content delivery web service. It integrates with other Amazon Web Services to give developers and businesses an easy way to distribute content to end users with low latency, high data transfer speeds, and no commitments.
Windows Azure Content Delivery Network	The Microsoft Azure Content Delivery Network (CDN) offers developers a global solution for delivering high-bandwidth content that’s hosted in Azure. The CDN caches publicly available objects at strategically placed locations to provide maximum bandwidth for delivering content to users.

Analytics Services

The analytics services allow to analyze massive amount of data stored either in cloud storages or in cloud databases using programming models such as MapReduce. Applications can perform data intensive tasks such as data mining, log file analysis, machine learning, web indexing and so on.

The following are some of the most common analytics services and their main characteristics.

Service Name	Description
Amazon Elastic MapReduce	Amazon Elastic MapReduce (Amazon EMR) is a web service that makes it easy to quickly and cost-effectively process vast amounts of data. Amazon EMR uses Hadoop, an open source framework, to distribute your data and processing across a resizable cluster of Amazon EC2 instances. Amazon EMR is used in a variety of applications, including log analysis, web indexing, data warehousing, machine learning, financial analysis, scientific simulation, and bioinformatics. Customers launch millions of Amazon EMR clusters every year.
Google MapReduce Service	Google MapReduce service is an open-source library that is built on top of App Engine services, including Datastore and Task Queues. You must download the MapReduce library and include it with your application. The library provides: A programming model for large-scale distributed data processing Automatic parallelization and distribution within your existing codebase Access to Google-scale data storage I/O scheduling Fault-tolerance, handling of exceptions User tunable settings to optimize for speed/cost Tools for monitoring status There are no usage charges associated with the MapReduce library. As with any App Engine application, you will be charged for any App Engine resources that the library or your MapReduce code consumes (beyond the free quotas) while running your job. These can include instance hours, Datastore and Google Cloud Storage usage, network, and other storage.
Google BigQuery	Querying massive datasets can be time consuming and expensive without the right hardware and infrastructure. Google BigQuery solves this problem by enabling super-fast, SQL-like queries against append-only tables, using the processing power of Google’s infrastructure. Simply move your data into BigQuery and let us handle the hard work. You can control access to both the project and your data based on your business needs, such as giving others the ability to view or query your data. You can access BigQuery by using a browser tool or a command-line tool, or by making calls to the BigQuery REST API using a variety of client libraries such asJava, PHP or Python. There are also a variety of third-party tools that you can use to interact with BigQuery, such as visualizing the data or loading the data. Get started now with creating an app, running a web query or using the command-line tool, or read on for more information about BigQuery fundamentals and how you can work with the product.
Windows Azure HDInsight	HDInsight is a Hadoop-based service from Microsoft that brings a 100 percent Apache Hadoop solution to the cloud. A modern, cloud-based data platform that manages data of any type, whether structured or unstructured, and of any size, HDInsight makes it possible for you to gain the full value of big data. With HDInsight you can seamlessly process data of all types through Microsoft’s modern data platform, which provides simplicity, ease of management, and an open Enterprise-ready Hadoop service all running in the cloud. You can analyze your Hadoop data with PowerPivot, Power View and other Microsoft BI tools, thanks to integration with Microsoft data platform.

Deployment and Management Services

The deployment and management services allow to manage and deploy application in the cloud. They allow to perform tasks such as capacity provisioning, load balancing, auto-scaling and application health monitoring.

The following are the most common analytics services and their main characteristics.

Service Name	Description
Amazon Elastic Beanstalk	Amazon Elastic Beanstalk is an easy way for you to quickly deploy and manage applications in the cloud. You simply upload your application, and Elastic Beanstalk automatically handles the deployment details of capacity provisioning, load balancing, auto-scaling, and application health monitoring. At the same time, with Elastic Beanstalk, you retain full control over the resources powering your application and can access the underlying resources at any time. Elastic Beanstalk leverages services such as Amazon Elastic Cloud Compute (Amazon EC2), Amazon Simple Storage Service (Amazon S3), Amazon Simple Notification Service (Amazon SNS), Elastic Load Balancing, and Auto Scaling to deliver the same highly reliable, scalable, and cost-effective infrastructure that hundreds of thousands of businesses depend on today.
Amazon CloudFormation	Amazon CloudFormation gives developers and systems administrators an easy way to create and manage a collection of related AWS resources, provisioning and updating them in an orderly and predictable fashion. You can use AWS CloudFormation’s sample templates or create your own templates to describe the AWS resources, and any associated dependencies or runtime parameters, required to run your application. You don’t need to figure out the order for provisioning AWS services or the subtleties of making those dependencies work. CloudFormation takes care of this for you. After the AWS resources are deployed, you can modify and update them in a controlled and predictable way, in effect applying version control to your AWS infrastructure the same way you do with your software. You can deploy and update a template and its associated collection of resources (called a stack) by using the AWS Management Console, AWS Command Line Interface, or APIs. CloudFormation is available at no additional charge, and you pay only for the AWS resources needed to run your applications.

Service Name

Description

Amazon Elastic Beanstalk

Amazon Elastic Beanstalk is an easy way for you to quickly deploy and manage applications in the cloud. You simply upload your application, and Elastic Beanstalk automatically handles the deployment details of capacity provisioning, load balancing, auto-scaling, and application health monitoring. At the same time, with Elastic Beanstalk, you retain full control over the resources powering your application and can access the underlying resources at any time. Elastic Beanstalk leverages services such as Amazon Elastic Cloud Compute (Amazon EC2), Amazon Simple Storage Service (Amazon S3), Amazon Simple Notification Service (Amazon SNS), Elastic Load Balancing, and Auto Scaling to deliver the same highly reliable, scalable, and cost-effective infrastructure that hundreds of thousands of businesses depend on today.

Amazon CloudFormation

Amazon CloudFormation gives developers and systems administrators an easy way to create and manage a collection of related AWS resources, provisioning and updating them in an orderly and predictable fashion.

You can use AWS CloudFormation’s sample templates or create your own templates to describe the AWS resources, and any associated dependencies or runtime parameters, required to run your application. You don’t need to figure out the order for provisioning AWS services or the subtleties of making those dependencies work. CloudFormation takes care of this for you. After the AWS resources are deployed, you can modify and update them in a controlled and predictable way, in effect applying version control to your AWS infrastructure the same way you do with your software.

You can deploy and update a template and its associated collection of resources (called a stack) by using the AWS Management Console, AWS Command Line Interface, or APIs. CloudFormation is available at no additional charge, and you pay only for the AWS resources needed to run your applications.

Identity and Access Management Services

The identity and access management services provide the following:

The following are some of the most common identity and access management services and their main characteristics.

Service Name	Description
Amazon Identity and Access Management	AWS Identity and Access Management (IAM) enables you to securely control access to AWS services and resources for your users. Using IAM, you can create and manage AWS users and groups and use permissions to allow and deny their access to AWS resources. To get started using IAM, click on the Create New Account; or if you have already registered with AWS, sign into the AWS Management Console and get started with these IAM Best Practices. IAM is free so start using it today!
Windows Azure Active Directory	Azure Active Directory is a comprehensive identity and access management cloud solution that provides a robust set of capabilities to manage users and groups and help secure access to applications including Microsoft online services like Office 365 and a world of non-Microsoft SaaS applications. Azure Active Directory is offered in two tiers: Free and Premium.

Service Name

Description

Amazon Identity and Access Management

AWS Identity and Access Management (IAM) enables you to securely control access to AWS services and resources for your users. Using IAM, you can create and manage AWS users and groups and use permissions to allow and deny their access to AWS resources.

To get started using IAM, click on the Create New Account; or if you have already registered with AWS, sign into the AWS Management Console and get started with these IAM Best Practices.

IAM is free so start using it today!

Windows Azure Active Directory

Azure Active Directory is a comprehensive identity and access management cloud solution that provides a robust set of capabilities to manage users and groups and help secure access to applications including Microsoft online services like Office 365 and a world of non-Microsoft SaaS applications. Azure Active Directory is offered in two tiers: Free and Premium.

References

Resource Representation

Resource State

Resource Address

Best Practices

Using HTTP Verbs

HEAD

Request

Response

GET

Request

Response

PUT

Request

Response

Service Maturity Level

References

Good Design Practices

Stateless Design

Service Responsibilities

Client Responsibilities

Directory like URIs

Additional URIs Guidelines

XML or JSON Format

References

Representational State Transfer (REST)

Proper Use of HTTP Methods

Create a Resource (POST)

Retrieve a Resource (GET)

Update a Resource (PUT)

References

Virtualization Versus Cloud

Virtualization

Cloud

Virtualized Environment

Cloud Environment

Notes

Elasticity

Best Practices

Notes

Web Site

Payment Gateway

Scaling

Best Practices

Notes

Failure Handling

Hardware Failure

Software Failure

Best Practices

Notes

High Availability

Graceful Failover

Data Location

Best Practices

Dynamic Data

Static Data

Notes

Parallel Processing

Best Practices

Accessing Data

Processing Tasks

Notes

Administering Cloud Resources

Best Practices

Notes

Security

Best Practices

Protect Data in Transit (“Encrypt Everything”)

Protect Data at Rest (“Encrypt Everything”)

Secure the Application

Security Groups

Software-Based Firewalls (aka. Host-Based Firewalls)

Notes

Physical Security

Network and Application Security

Glossary

Cloud Computing

Elasticity

Horizontal Scaling

Hybrid Cloud