Sunday, December 27, 2009 |
|
|
One way to approach the different architectural implications is to look at the various vendor offering and see how they match to the various application types.
You can divide the cloud vendors into four categories, although one vendor might have offerings in more than one category:
Platform as a Service providers
Software as a Service providers
Application as a Service providers
Cloud Appliance Vendors
The Platform as a Service providers attempt to provide a cloud operating system for users to build an application on. An operating system serves two basic functions: it abstracts the underlying hardware and manages the platform resources for each process or user. Google App Engine, Amazon EC2, Microsoft Azure, and Force.com are examples of platform providers.
The most restrictive platform is the Google App Engine because you program to the Google API which makes it difficult to port to another platform. One the other hand, precisely because you program to a specific API, Google can scale your application and provide recovery for a failed application.
At the other extreme is Amazon. Amazon gives you a virtual machine which with you can program directly against the native OS installed on the virtual machine. This freedom comes with a price. Since the Amazon virtual machine has no knowledge about the application you are running, it cannot provide recovery or scaling for you. You are responsible for doing that. You can use third party software, but that is just a means of fulfilling your responsibility.
Microsoft tries to achieve a balance between these two approaches. By using .NET you have a greater degree of portability than the Google API. You could move your application to an Amazon VM or even your own servers. By using metadata to describe your application to the cloud fabric, the Azure infrastructure can provide recovery and scalability.
The first architectural dimension (ignoring for a moment the relative econonmics which will be explored in another post) then is how much responsibility you want to take for scaling and recovery vs. the degrees of programming freedom you want to have. Of course the choice between the Google API and Microsoft Azure might come down to the skill set of your developers, but in my opinion, for any significant application, the architectural implications of the platform choice should be the more important factor.
|
|
|
|
|
Thursday, December 24, 2009 |
|
|
|
|
Archive |
April, 2013 (1) |
March, 2013 (1) |
July, 2012 (1) |
June, 2012 (1) |
May, 2012 (3) |
March, 2012 (2) |
February, 2012 (1) |
January, 2012 (1) |
October, 2011 (1) |
May, 2011 (1) |
January, 2011 (1) |
December, 2010 (1) |
November, 2010 (1) |
September, 2010 (2) |
August, 2010 (1) |
July, 2010 (1) |
March, 2010 (1) |
December, 2009 (2) |
November, 2009 (3) |
October, 2009 (2) |
August, 2009 (2) |
July, 2009 (1) |
June, 2009 (2) |
May, 2009 (3) |
January, 2009 (3) |
October, 2008 (1) |
September, 2008 (2) |
August, 2008 (1) |
June, 2008 (1) |
April, 2008 (1) |
March, 2008 (3) |
February, 2008 (2) |
January, 2008 (1) |
November, 2007 (1) |
October, 2007 (1) |
August, 2007 (1) |
May, 2007 (1) |
October, 2006 (1) |
September, 2006 (2) |
August, 2006 (1) |
July, 2006 (1) |
June, 2006 (8) |
February, 2006 (1) |
November, 2005 (1) |
October, 2005 (1) |
August, 2005 (1) |
March, 2005 (2) |
December, 2004 (2) |
November, 2004 (1) |
August, 2004 (1) |
June, 2004 (2) |
March, 2004 (1) |
February, 2004 (1) |
|
|
|
|
Themes |
Pick a theme:
|
|
|
|