RightScale lets you easily deploy an application to a cloud provider like AWS or Rackspace. We do this by abstracting your server infrastructure design to a layer above that cloud provider. Consequently, I often have conversations about whether an existing application is a suitable candidate for the cloud. The less common question, but of great significance, is whether an application can really exploit the capabilities of the cloud.
I recently developed a little framework which helps to explain some of the dimensions which effect how well an application can go beyond a forklifted application towards one which is architected for the cloud.
What’s a cloud-oriented app?
It’s fairly well understood amongst web-based businesses who use the cloud, that you have to design for failure. You have to assume any element of your infrastructure or application stack could fail. Perhaps Netflix made this most famous with their chaos monkeys who deliberately destroy service elements, so Netflix could test what happened and make sure the system was resilient. At reInvent last year, it was thematic in key presentations from AWS. This is no secret.
Applications which are designed with a service-oriented architecture should gracefully degrade if a service on which it depends are no longer available. A simple example is if an application presents a menu choice, and that menu is derived from a database, but that database is not there any longer – it’s failed for whatever reason – the application needs to keep working anyhow.
In traditional enterprise data centres, the design assumption applications can make is that the hardware environment will be available 99.5% of the time or more. Core systems will expect 99.9%, and so on. The application at the top assumes all its layers underneath are working, and generally does not fail gracefully.
Cloud applications dismiss that availability assumption, and not because the cloud is necessarily less reliable, but because it makes for a more resilient and scalable application in any case, and because the cloud is a distributed system.
Cloud apps can scale horizontally (more servers), instead of vertically (CPU). Doing this requires the constituent parts are able to scale that way.
What are some non-cloudy ways?
So, some applications expect to find on a local file system, or store sessions in a low-throughput database. If the app is doing that, it’s not very cloud-oriented. That’s the “data location: actual server” column of this diagram.
I itemised a few technical elements which can be done in a cloudy way, or not:
- user data,
- session management,
- infrastructure config and
- application configuration.
Some web-based applications like Drupal, phpBB and Concrete CMS store their application configuration and user data in ways is not compatible with horizontal scalability. They need some adaption to use GlusterFS, for example, as a distributed file system, and do not have public reference architectures for putting them into a horizontally-scaling environment.
I’ve mapped out those elements against the continuum from least to the most cloud-oriented method (the solutions I’ve listed are not exhaustive).
For horizontal scaling, ideally the application needs to be installed unattended in a scripted fashion. (So, you can’t do the next/next wizard of phpBB, for example). This in turn means the configuration of the application needs to be defined and stored in a database or file which is accessible to the installer script, and then you have questions around version control and persistence of that configuration information.
People and process change management also needs to be considered: if the user edits a configuration on a local file, but doesn’t push that configuration back to the SVN, it will not persist when the server is rebuilt next time.
Some apps go easily to the cloud
Some applications will adapt well to a horizontally-scaling cloud environment, others will not.
Those which do not scale horizontally may still be suitable for deployment to cloud, but in a forklifted fashion. You’d retire the existing server and move the application to an equivalent cloud server, which is most likely cheaper. The application may not like to be turned off at night to save you money. If it can, though, then your financial savings increase markedly. Turning off servers is one key to unlocking cloud economics. Scaling horizontally is another key.
In either case, it’s a lot more intellectually fulfilling and interesting that staying with the status quo.
