Who should use Cloud?

This question comes to everyone these days when big companies like Microsoft, Amazon, Google and others are spending a lot on cloud infrastructure. So the thoughts start coming in our mind: should we use cloud computing? Will it benefit our company over traditional way of developing and hosting??

Let’s start dissecting the cloud:-

What is cloud?

Cloud computing is a style of computing in which dynamically scalable and often virtualized resources are provided as a service over the Internet.

Cloud services can be classified into three categories: Infrastructure-as-a-Service (IaaS), Platform-as-a-Service (PaaS) and Software-as-a-Service (SaaS). In this article we will talk about Infrastructure services.

Though many companies are jumping into cloud service provider bandwagon but Amazon has been one of the oldest in the business and provides services which support innumerable functionalities and are easy to use.

Infrastructure Services by Amazon provides virtual server instances with unique IP addresses and blocks of storage on demand. Customers use application program interface (API) to start, stop, access and configure their virtual servers and storage.

Overview of Amazon Infrastructure Services

It provides the following services:-

Simple Storage Service (S3): This service provides secure online storage space for any kind of data. There is no limit how much data you can store in S3. You can also control the bandwidth to use for transfer of data. The important point is that you do not need to pay upfront for large storage space. As your data grows you pay more.

S3 is scalable and distributed and stores your data reliably across multiple data centers of Amazon.

Amazon Elastic Compute Cloud (EC2):

This service allows you to run multiple virtual machines (Linux or Windows) on demand. The service allows you to create resizable pool of servers for handling computing tasks. You can increase or decrease the number of servers as per demand. The cost will be calculated based upon the usage of the servers on hourly basis. The APIs to start, stop and configure the virtual machines are very simple and you can easily control them.

EC2 helps startups companies and online entrepreneurs to build applications that can scale from 0 to 5 million hits in just few weeks without worrying how to manage the scalability and reliability of the application. As the load increases you can add more servers and delete when not required. Suppose you are hosting an event and that is expected large number of hits; so you can add more servers and release when event is over.

Amazon Simple Queue Service (SQS):

SQS delivers messages between computers/ systems allowing distributed applications to communicate reliably. SQS is implemented as a distributed application in Amazon and your messages are stored redundantly across multiple servers and data centers.

Amazon SimpleDB

Amazon SimpleDB stores the small pieces of information in a database structure that is easy to manage, modify and search. It indexes every piece of information you store so all your queries run quickly.

All the services provided by Amazon are easy to use and have benefits for all categories of organizations (small, large etc.).

Startup companies can go to market fast by deploying their applications on the Cloud (EC2). Imagine you can have your Web Server ready in 10-15 minutes without spending time to think on which machine to buy, placing an order and then worrying about having it installed and hiring a person to look after it.

Well, the services are cheap and are absolutely in reach of the startups.

For Large companies whose applications are already used by millions of users and whose users are continuously growing; it provides an enormously large storage capacity. They needn’t to fall into buying and installing data server troubles. They can host the applications on the cloud and get benefits of scalability and reliability EC2 provides. EC2 lets you to host your applications in Europe and US; so you can replicate your data in different geographical zones and deal with the risk of failure in one zone. It prevents the company from worst web challenges like power failures, cable cuts, earthquakes etc.

A cloud service has three distinct characteristics that differentiate it from traditional hosting.

• It is sold on demand, typically by the minute or the hour.
• It is elastic; a user can have as much or as little of a service as they want at any given time.
• Significant innovations in virtualization and distributed computing, as well as improved access to high-speed Internet and a weak economy, have accelerated interest in cloud computing.

The "Elastic" nature of the service allows developers to instantly scale to meet spikes in traffic or demand. When computing requirements unexpectedly change (up or down), Amazon EC2 can instantly respond, meaning that developers have the ability to control how many resources are in use at any given point in time.

Ashwani Kumar
Solutions Architect
Globallogic Inc.

SOAP VS REST Web Services

SOAP or REST WebServices

When we start designing the Architecture of any Web Application, architects generally think what to choose? REST or SOAP

In this blog I am going to describe few design principles based upon which you can choose either SOAP or REST

History of WebServices

Webservices were built in the last 10-15 years in layers, where each layer resolves some of the technical issues faced by architects. It started when people think that we can use internet to transfer the data internally or globally. The process started with the use of HTTP protocol. However this protocol is restricted in some ways and thus big software companies spending their time in building a new protocol SOAP (Simple Object Access Protocol) which extends the HTTP capabilities to allow objects to be called remotely over HTTP. This protocol was a big success and lot of internet applications started using this. However as applications required more and more capabilities from the protocol one more layer was added in 2005 WS*. As the research in this subject goes on, we might see few more layers on this in coming years. If, SOAP webservices are built from the last so many years and have lot of capabilities then why some of the architects not prefer these? The answer is: to create a simple SOAP webservice we need to understand various protocols and architecture styles and this caused some of the developers to ignore the new technology/ standards and continue to use what they know.

The other issue is the wrong usage of Http verb in SOAP. The webservice Soap requests use the HTTP POST verb to transport request to the end points for the operations. Now if the method is just retrieving the records, then this should be GET. SOAP resolves this issue by having the standards naming conventions for the retrieval method by naming them as GetCustomers (prefeixing the methods with Get) but this is in the hands of developers.

Now REST (Representational State Transfer) Services: some researchers tell that REST should be the only design applied to the HTTP based services.

The greatest asset of REST based service is its pure elegance and its simplicity. REST is based upon the Resource Oriented Architecture. REST services do not require you to design your own service contracts, because you can rely on HTTP verbs to describe intent. This radically simplifies your service’s design. HTTP defines the verbs GET, PUT, POST, and DELETE. By using these built- in verbs, REST services provide access to resources via a Uniform Resource Indicator (URI) and an HTTP verb.

Now the question is which technology to choose. Well both has some advantages and some disadvantages. In most of the cases I would prefer REST because these are simple and what I believe is that “Simplicity is the key to success for big applications”. Does that mean it is end for SOAP, Not really. There are some cases where you might need to use SOAP because REST is somewhat limited, like you don’t have duplex message exchange pattern in REST.

Here are few of the things not supported by REST but available in SOAP.

REST only supports text based encoding whereas SOAP supports other encodings binary

REST doesnot support duplex message exchange pattern which is available in WS*

Only transport security is available in REST whereas WS* supports additional like WS-Security, WS-SecureConversation etc.

I am concluding on the blog by saying: This is very important for architects to choose the right approach for building services but always focus to keep things simple but secure so that community can consume your services easily. In my coming blogs I will focus on Ado.Net Data Services (Astoria), one of the very good project by Microsoft which allow us to create REST services. (generally we found Microsoft introducing complexity with every new release but this time things are changed and Microsoft is looking for simplicity and understanding the needs of the industry well.)