Any new technology adoption happens because of one of the three reasons:
Capability: It allows us to do something which was not feasible earlier
Convenience: It simplifies
Cost: It significantly reduces cost of doing something
What is our expectation from cloud computing? As I had stated earlier, it is all about cost saving … (1) through elastic capacity and (2) through economy of scale. So, for any CIO who is interested in moving to cloud, it is very important to understand what the cost elements are for different cloud solutions. I am going to look at 3 platforms: Amazon EC2, Google App Engine and Microsoft Azure. They are sufficiently different from each other and each of these companies is following a different cloud strategy – so we need to understand their pricing model.
(A word of caution: this analysis is as per the published data on 20th January, 2010 and texts in green italics are my interpretation)
Quick Read: Market forces seem to have ensured that all the prices are similar – for quick rule of thumb calculation to look at viability, use the following numbers irrespective of the provider. You will not go too much off the mark.
Base machine = $0.1 per hour (for 1.5 GHz Intel Processor)
Storage = $0.15 per GB per month
I/O = $0.01 for 1,000 write and $0.001 for 1,000 read
Bandwidth = $0.1 per GB for incoming traffic and $0.15 per GB for outgoing traffic
However, if you have time, you can go through the detail analysis given below.
Amazon:
Overview: You can create one or more instances of a virtual machine for processing and for storage
You pay based on time the instances are running and not on how much they are used – if an instance is idle, you still pay for it
There are three physically different locations where the facility is available (called availability zones) – US(N. Virginia, N. California) and EU(Ireland)
When you either shutdown the machine instance or it crashes for whatever reason you lose all your data
It is possible to have a reserve instance (for 1 year or 3 years) for an initial payment and discounted rate of usage – however, I do not think it provides any guarantee against data loss because of machine crash
Data storage can be both relational and non-relational
Machine Instance: Virtual machine can be of different capacity – Standard(Small, Large, Extra Large), High-Memory(Double Extra Large, Quadruple Extra Large), High-CPU(Medium, Extra Large)
Charge for Machine Usage: You are charged for the time you keep the instance of the machine running – the time is calculated in hours, any fraction of hour is taken as full hour
Hourly charge vary from $0.085 (Small – Linux – N. Virginia) to $3.16 (Quadruple Extra Large – Windows – N. California)
Both Linux and Windows machine instances are supported – Windows machines are about 40% more expensive – other software charges are extra
There are separate charges for mapping IP addresses, for monitoring & auto scaling ($0.015 per instance per hour) and load balancing
A message queue is available (Simple Queue Service – SQS) but again it has a separate charge – $0.1 to $0.17 per GB depending on the total monthly volume
Data Persistence: To persistent data storage you can one of the 3 alternatives – Simple DB, Simple Storage Service (S3) or Relational Database Service (RDS)
Simple DB and S3 storage mechanism is not RDBMS – that is you do not have tables therefore you cannot retrieve records through using JOIN
RDS is an instance of MySQL – so you can use it like a normal RDBMS
Charges for Simple DB: you pay separately for CPU, disk space and data transfer – though up to a limit they are free (25 CPU hours, 1GB data transfer, 1GB of storage)
CPU usage calculation is normalized to 1.7 GHz Xeon (2007) processor and works out to $0.14 to $0.154 per hour depending on location
Data transfer In is free till June 2010 and charge for transfer Out is between $0.1 to $0.17 per GB depending on the total monthly volume
Actual storage is charger at $0.25 to $0.275 per GB per month – it includes 45 bytes of overhead for each item uploaded
Charges for S3: You are charged for disk space, data transfer and number of request made instead of CPU usage – data transfer charges are the same
Storage charge varies from $.055 to $0.165 per GB per month making it slightly cheaper than Simple DB but at a higher level of usage (more than 1000 TB)
I/O requests are charged separately – you pay between $0.01 to $0.011 per 1,000 write requests and $0.01 to $0.011 per 10,000 read requests – deletes are free
Charge for RDS: You pay for storage, I/O request, data transfer and machine instance (Small, Large, Extra Large, Double Extra Large, Quadruple Extra Large) based on usage
You pay for RDS instance – charges vary from $0.11 to $3.10 per hour depending on the instance size
The storage charge is not pay as you use – you have to decide in advance (5 GB to 1 TB) and the charges are $0.10 per GB per month
The is no charge for backup up to the amount of storage you have chosen but you have to pay $0.15 per GB per month for extra backup
You pay separately for I/O at $0.10 per 1 million I/O requests
Google:
Overview: Application written in Python or Java can directly be deployed – the implementation is a subset
No need to instantiate any virtual machine
You are charged on the actual normalized CPU cycles used
Storage is only non-relational
Charge is calculated on these parameters – bandwidth, CPU, storage, emails send
You have free quota for each of these parameters – it is enough for development, testing and small deployment
There are limits imposed for peak usage on many different parameters – with daily limits & limits on usage in a burst
You will need to rewrite your application to work on Google App Engine – see this
Charge for CPU usage: It is calculated in CPU seconds equivalent to 1.2 GHz Intel x86 processor
You pay $0.10 per hour of CPU usage for processing requests
You pay $0.10 per GB for incoming traffic – rates for Asia are different $0.30 per GB
You pay $0.15 per GB for outgoing traffic – rates for Asia are different $0.45 per GB
Looking at the complexity of pricing I see great prospect for anybody who specializes in optimizing application for cloud – unlike traditional applications – any improvement in cloud application and directly be measured in $$$ saved.
About Udayan Banerjee Udayan Banerjee is CTO at NIIT Technologies Ltd, an IT industry veteran with more than 30 years' experience. He blogs at http://setandbma.wordpress.com.
The blog focuses on emerging technologies like cloud computing, mobile computing, social media aka web 2.0 etc. It also contains stuff about agile methodology and trends in architecture. It is a world view seen through the lens of a software service provider based out of Bangalore and serving clients across the world.
The focus is mostly on...
SYS-CON's International Cloud Computing Conference & Expo, held each year in California, New York and Prague is the leading event covering the fast-emerging Cloud Computing market for Enterprise IT professionals. Co-located with the International Virtualization Conference & Expo, the combined event will surely deliver the #1 i-Technology educational and networking opportunity of the year for those seeking to establish a market lead anywhere in the multiple layers of the Cloud Computing ecosystem.
Senior Technologists including CIOs, CTOs, VPs of technology, IT directors and managers, network and storage managers, network engineers, enterprise architects, communications and networking specialists, directors of infrastructure Business Executives including CEOs, CMOs, CIOs, presidents, VPs, directors, business development; product and purchasing managers.
Cloud Computing Journal aims to help open the eyes of Enterprise IT professionals to the economics and strategies that utility/cloud computing provides. Cloud computing - the provision of scalable IT resources as a service, using Internet technologies - potentially impacts every aspect of how IT deploys and operates software.
Government IT Conference & Expo 2009 Allstar Conference Faculty Lineup Will Include...
In other words, VMware’s server density is higher. Boles suggests this means that customers should be “assessing virtualisation on a ‘cost per application’ basis. VM density has a sign
Traditionally, the way people have implemented high availability is by using a high-availability management package like Linux-HA[1], then configure it in detail for each application, file system moun