So PDC ‘09 is under way – at least for those of us lucky enough to attend the pre-conference sessions yesterday (Monday) I attended the Architecting and Developing For Windows Azure workshop. This was a great session given by Chris Auld and it was probably one of the best sessions on Windows Azure I’ve attended in recent months. It covered all the main facets of Windows Azure (Elasticity, Scalability, Deployment, Storage etc) but did this in the context of a real world customer TicketMaster, a New Zealand ticketing agent for major event.
This was an ideal application for Azure requiring rapid ability to scale massively for sell-out major events and then scale back down as needed.
Data Storage – Where and What To Put
It was interesting to see the approach Chris took to data partitioning in both Azure Storage and SQL Storage and the comparative costing approaches associated with each. In some cases the transaction charges associated with storing in Azure storage might push you to using SQL Azure instead, as long as you stay within the 1GB and 10GB respective database limits.
In addition there was an assertion that storing data in both Azure and SQL storage could provide greater scalability and performance for a variety of scenarios. I guess if your pockets are deep enough the benefit is there……
Managing Data For Efficiency & Cost
The talk reinforced to me how much manual data manipulation and “data grooming” is required on an ongoing basis to keep SQL Azure and Azure storage both efficient AND cost-effective. Few application development areas currently have the same direct connection between application, architecture and cost of running a solution. Even the fieldname lengths in Azure storage can impact storage cost. This will be a whole different direction for some people when designing and building applications..
Costing Your Solution
One of the areas that I’ve always felt is key to many of the decisions around moving to the Cloud, is being able to compare on-premise costs with those of the Cloud. Unless you have good internal data, how do you really know how much your application costs to develop and look after per database and per server? If you don’t know this, how do you know whether Azure is good value? What costs would you factor per application and which ones per datacenter? Again chris had some good solutions here with Excel models and calculators that attempted to illustrate the cost elements.
I think modelling on-going costs in application solutions is going to be a key area for the future. It is an area most technical staff will need to get a lot better at.
Migrate Existing or Green Field Development?
The session also left me even more convinced, that in many cases there is a different approach required when building new applications for the cloud compared to migrating existing applications. With existing applications, the historical legacy caused by years of varying evolution and pragmatic compromises, may make it impossible to achieve a “pure” cloud architecture that can achieve in turn the most cost saving. Quite simply, unravelling some of that legacy, would cost too much in development time which would negate the Azure savings in operational costs.
With a new application it is obviously much easy to achieve a more cost effective, efficient design, from the ground up. Even here however the application should be designed in such a way that it uses flexible, pluggable architectures. It is entirely possible that an application may need to be redeveloped purely because the Azure pricing model has changed rather than because new functionality is needed. This is a radical change in business drivers, that may take a while to work its way through. Solution architecture in future may be driven as much by hard financial issues as technical elegance and scalability.
Cloud Friendly Solution Characteristics
What is certainly true is that the best prepared solutions for migrating to Azure will have some of the following characteristics:
- Be highly idempotent,
- Have Service Orientated Architectures with a focus on pluggable and provider design patterns.
- Designed for high load and parallel running scenarios.
- Be easily separable in terms of the data flows between each layer.
- Stores and uses only the data required for current system operation. Other data is aggressively archived to on-premise locations.
- Use generic configurations and not rely on custom hardware implementations.
It is going to be interesting to see what the PDC’09 keynote announcements will provide to assist with this.