Azure to the rescue
Developers following the build of the new Tesco Grocery API, (an R&D project that allows third-party access to our grocery service through their own applications) may well have questioned a consequence of enormous download counts for our iPhone Clubcard app.
The question: If we had similar downloads for the forthcoming Tesco iPhone Grocery app, how will the API cope if it is still in R&D?
The blunt answer is that it won’t. My tests have shown that currently the API service can survive processing around 400 simultaneous HTTP requests on its server – any more and performance begins to suffer – not very useful if several thousand customers all start trying to synchronise their favourite products (a key feature of the grocery app) at the same moment in time.
What to do? Productionise the API, of course! Well that work has already started but it’s going to take a while to complete, and we want to launch sooner rather than later.
The good news is the API has been created as an ASP.Net application – perfect for being hosted within the new production Windows Azure cloud computing platform. An early version was running in an equally early version of Azure during 2009, so the design takes account of operation within the cloud. It’s also been upgraded recently to work in .Net Framework v4.0 and ongoing developments use the Visual Studio 2010 dev environment, so it’s 95% cloud-ready right now.
Importantly, the API does not itself store any personal information since it acts as a proxy between client applications and the new ‘Project Martini’ grocery service running on the live Tesco.com web servers. That’s important as it would be difficult to describe where the Azure SQL databases actually reside to the Data Protection Registrar, so thank goodness it doesn’t need any such registration.
Tomorrow it’s a case of adjusting the API source code to work fully within Azure’s development fabric, then upload it to the Azure cloud for some stiff weekend performance testing. Indeed I need to turn up the stress on the API until it starts suffering in terms of performance, then I’ll be able to calculate how many CPUs and other Azure resources are needed to scale the service upwards to cope with possibly thousands of simultaneous users.
Cloud computing is a great way of ‘taking the strain’ with services – particularly with peaks that will no doubt be experienced after an app launch – I’ll let you know how the Azure-hosted Grocery API behaves over the coming days – and post launch.