Application Architecture for Clouds – How are they different?

Whether it is public clouds, or private clouds, or internal clouds, or,…, One thing is very clear. Simple migration of current applications to cloud doesn’t work effectively. So, the question is what would be considered a good ‘application architecture’ for the cloud?  It may not be one, but there are some key design principles.   Before we look at those, let us look at the characteristics of cloud. These drive the application architecture for clouds, for the most part.

Any cloud operating environment (COE) would have the following minimal set of attributes.

  1. Multi-tenancy and shared infrastructure – more applications, users, transactions / compute host
  2. Elasticity & horizontal Scalability – Resource scaling up or down, depending on demand and usage. This helps capacity and demand planning.
  3. Pay as you go – Don’t need to procure entire capacity or pay for worst case demand planning… Pay by subscription or based on usage
  4. Automation and flexible management - Self service, flexible and dynamic assignment of workloads to optimal resource utilization

There may be multiple architectural approaches to leverage and “play well” in these COEs. Irrespective of the approach, the key design principles would be :

  1. Be a good tenant on a shared infrastructure – Applications have to be cognizant that they live in a shared environment. Ex: finer granularity (locks, etc.) optimized use of resources, proper authentication & isolation.

  2. Built for scalability – This is probably the hardest for application developers. It cannot be done in isolation. Applications would have to talk with infrastructure (COE) and vice versa, to be elastic. For the infrastructure to provide the elasticity, applications have to provide hooks for monitoring utilization by the infrastructure, and the management and administration of these applications.  This has far reaching implications. When you decide to use “Google Apps” or Microsoft Azure, you would be locked into a set of patterns for accessing data, code for scaling, etc.
  3. Parallelism - this might be obvious, but also one of the hard ones for application developers.  Most applications have constraints with either serial execution, single points of contention like session/application state, memory, file and dataset locks.. All these hamper parallelism.
  4. Configurability v/s Coding : The good apps on Cloud would be highly configurable… a lot of the behavior (including function and workflow) is driven by meta-data. Optimization based on “Locality” and Semantics are two other key concepts that should be configurable v/s hard-wired in applications.
  5. HW independence/Abstraction – so apps can run on the ‘best’ and optimal hardware from performance, scale and TCO perspective. Virtualization is a great model. This could be the basis for simpler federation between different cloud environments.
  6. Distributed and Composite architectures – Capabilities exposed as services. An app is a composition of bunch of services/apps (not objects and libraries like we are used to) that in turn adhere to the same set of design principles.

So, how do enterprises leverage the power of the Cloud?  Enterprises don’t have the luxury of re-writing all their applications to play well in the cloud. And, not all existing applications are architected with the above mentioned design principles.   Does this mean only new “green field” developments are well suited for the “Cloud”?  If enterprises have deployed SOA and the web2.0 architectures , do they have a head start with the cloud migration?  Are there other design principles that you see?


What do you think?