Amazon Web Services (AWS)
Unlike Google, Amazon follows a service-oriented architecture to solve your cloud computing requirements. Amazon offers a suite of diverse, fine-grained services that you can mix and match and use as per your requirements. Show below is a rough sketch of how an AWS App works. Amazon offers services like EC2 for CPU cycles, S3 for storage, Cloudfront for Content Distribution etc. To see the full list of services offered by Amazon, look here: http://aws.amazon.com/
Strictly speaking, there is no such thing as an AWS app. Any application that uses one or more services from the AWS Suite, can be called an AWS App (Compare this to the strict definition of what a GAE app is. It needs to implement specific interfaces, be packaged as a war, must have an app-engine specific deployment descriptor called appengine-web.xml etc). In essence, your AWS app could be as simple as a command line utility that uses the Amazon Simple Storage Service(S3) to backup your old photos and videos. It could also be an enterprise-scale deployment of several EC2 servers using Elastic Load Balancing for balancing load, storing data in Amazon Elastic Block Store (EBS) and delivering media via Amazon Cloudfront. Think of an AWS App as a mashup. You pick the services you want to use and forget about the rest.
Amazon offers you a great deal of flexibility on how you can build on their infrastructure. For example, you can get an Amazon EC2 instance and run Tomcat on it. The Amazon EC2 instance, which is a virtual instance, will look and behave just like a regular dedicated Linux server you would get from Rackspace or Godaddy. You get root access and you can do practically anything you would be able to do with your own box. The only difference being, if you want to scale up or scale down your instance, you can do it immediately. If your website is slashdotted, you can get 100 instances up and running in minutes.
Amazon does not force you to use any of their services. So while the Tomcat on your EC2 instance can use Amazon's Simple DB for persistence, nothing stops you from configuring MySQL on your instance and using it as your database. However, and this is the most important thing, YOU will need to figure out how to scale up and scale down your MySQL based on your demand, you will need to configure replication etc. Amazon cannot magically do that for you.
Where AWS shines
Amazon provides you the building blocks to build any complex cloud deployment you can think of. It gives you the flexibility of choosing those features you need and ignoring the rest. With AWS you are in complete control of your deployment topology. AWS is also pay-per-use, which means you only pay as much as you use.
In the next blog entry, I will demystify some marketing jargon, discuss the pros and cons of each platform and give you some recommendations on how to choose the right platform for your needs.
"AWS is also pay-per-use, which means you only pay as much as you use."
ReplyDeleteThis is not true in the same sense as it is on Google App Engine. With GAE, if your app is installed and available, you pay nothing if it's idle and doesn't receive any web requests. GAE will suspend your servlet container after a short period of idleness.
With AWS you need to boot up a server instance, Linux, for example, and have it run tomcat. As long as your instance is booted, you'll be paying for it. The last time I figured it out, it was about $70 US a month to have a small instance running.
The other disadvantage of AWS is that you need to be a system administrator. Some may prefer getting their hands dirty with that, while some may not.
Agreed. What I meant by pay-per-use was: "How much you pay depends on how much you use". Yes, there are some fixed costs with AWS services like EC2.
ReplyDelete