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.

Tesco.com Grocery Accelerator for IE8 now live

If you have Microsoft's latest web browser, Internet Explorer 8, try out our new Tesco.com Grocery Accelerator.

http://tesco.cloudapp.net/ie8.aspx

Then, whenever you read a web page anywhere on the web that mentions food and drink, click the blue 'accelerator' icon that appears next to the word(s) you highlight on the page. When the accelerators menu appears, hover your mouse over 'Hover to search Tesco.com grocery' in your list of accelerators. A small window will appear which, after a few seconds, will list up to five Tesco.com products matching the highlighted text.

If you click the 'Hover..' message (rather than just hover over it), a new page opens with some extended search results.

The accelerator is actually an XML document which has commands to tell IE8 what do. You can see the XML itself (in any browser that renders XML) if you navigate straight to http://tesco.cloudapp.net/addTescoIE8Accelerator.xml

The accelerator XML points to page ie8.aspx (running at our space in the Microsoft Azure 'cloud') whose behaviour depends on parameters supplied in the page request, namely  'searchfor=' and 'preview=n'.

So, searching for highlighted text 'chocolate' becomes:

http://tesco.cloudapp.net/ie8.aspx?searchfor=chocolate  in preview mode, and

http://tesco.cloudapp.net/ie8.aspx?searchfor=chocolate&preview=n  in full-page mode.

The page ie8.aspx is, of course, using the Tesco.com grocery API to perform the search. The page does not have the actual credentials of the customer, so it calls the API with an account pointing to our Brent Cross store in north London, which has an average-sized product range.

Soon I intend to both improve performance and also update the service so that the customer can login to the service quickly, search their own store, and add the search results straight to their shopping basket - ideal if, for example,  they are on a recipe site and want to obtain the ingredients.

Azure moves time to UTC, and Tesco's place in the Azure cloud

I predicted in an earlier post that the Windows Azure platform team were going to have to have a serious think about what they do about time in the Azure cloud.

Well I've just come back from holiday to find in my inbox a message from the team saying that Azure is going to move from local time (Pacific, which happens to be the time zone where Microsoft HQ in Redmond is located) to Coordinated Universal Time (UTC) - that's Greenwich Mean Time (GMT ) to us in the UK.

In their message, the Azure team say:

Currently, the time zone within Windows Azure is Pacific Standard Time (PST). Soon, we will be migrating to Coordinated Universal Time (UTC). This is potentially a breaking change for applications which rely on local time.

When will we make the change?
We will start rolling out this change starting Sunday, March 8 at 10:00 AM GMT.

Why are we doing this?
Windows Azure is a global service. To ensure that applications behave the same way regardless of their physical location, it’s important that Windows Azure have a consistent time zone across all geographies. UTC is a natural choice given our global customer base, and UTC is not subject to potentially disruptive changes in Daylight Savings Time.

What’s the potential impact to you?
If your application running in Windows Azure relies on local time, you will be impacted by the migration to UTC. Here are a few examples of potential issues:

• Gaps may occur in event logs if local timestamps are used.
• User interfaces that depend on local timestamps may show different results.
• Local timestamps stored by your application may be interpreted differently after the changeover.

Many applications have already been designed to rely only on UTC time. These applications should be unaffected.

The good news is that those of us thinking of the global nature of Azure will have been using the System.DateTime.UTCNow property to obtain time rather than using System.DateTime.Now if only because Pacific time was probably inappropriate to our applicatons unless coding for users located on the USA's Pacific coast.

The bad news is that of course we need to use time that is local to our user market, which means that we need to convert UTC to local time and then deal with summer/winter time within each application.

I'm still holding out for a setting in Web.Config that performs the equivalent of setting the local time zone on a Windows server and let it handle time moves just as happens today. Doing this at application level for Azure would mean that it would be flexible and easy to bring different time-zone versions of the same application to different countries.

Finally I'm happy to say that I've secured Tesco a place in the Azure cloud domain at http://tesco.cloudapp.net - I'll put something appropriate up there shortly (once my holiday completes tomorrow night!). The Tesco.com Grocery API will go up there shortly and I'll make sure that colleagues throughout Tesco wishing to try some 'R&D in the cloud' can get access - just contact me from your Tesco account to mine if you would like to do so.

What Time is it in the Windows Azure 'cloud'?

I had very interesting meeting yesterday with Neil Hutson and James Conard from Microsoft Corp who are members of a team responsible for the forthcoming Windows Azure 'cloud' platform.

Microsoft recently announced Azure at the PDC in Los Angeles. It's essentially a Microsoft owned and run hosting solution. If, like us, your systems run on Microsoft.Net and SQL Server then it is possible that those systems could be run in Azure.

I hasten to add that we have no plans to host Tesco.com anywhere other than our own hosted spaces. This solution wins for us on many fronts including security & legal (where data is hosted and how it is protected), availability (given that we are a 24/7 operation) and performance (not too many hops from the customer's computer to our web servers).

However it's my job to look at new technologies even if it is to prove that we do now is best, and so Azure has arrived as a project to see if it could a possible future hosting solution from a technical viewpoint.

Neil and James explored with me the facilities that will be available on Azure. Since the service is at an early stage of development there were many questions, the most important of which was the various elements of service level agreements that would need to be place.

There was also the subject of performance and efficient coding for optimal use of Azure without too much CPU or memory requirements (as this would affect cost directly).

One interesting question I posed them, however, was one that they have had to go away and answer: What time is it in Azure?

In other words, if I create an ASP.Net application with a web page that prints out the system date/time, and upload it from London what will it say?

Response.WriteLine("The time in Azure is: " + System.DateTime.Now.ToString());


What will it say to users in the UK (Summer/Winter time)? In the USA (Summer/Winter time + 4 time zones)? In India (constant time all year)?

Time is critically important to Tesco.com as it is involved in nearly every aspect of our service from scheduling vehicles to texting customers. It's no good a customer choosing a 10am to 12 slot when the time is an hour different, for example.

Now the easiest way out for Microsoft is to simply offer up UTC/GMT time for everyone, and it's up to the application to work out what local time it is. However that's a bit unfair - after all our Windows Servers all set the Summer/Winter time seamlessly and we don't have to worry about it. In addition, Tesco has its own time server ('tesco time!') which is used by all servers across the company to set their time by - a service which Azure would not have/want access to!

I suspect that Azure applications are going to have to have an extra parameter in Web.Config that allow developers to set the local country or region. That way Azure can supply the correct local time to the application through System.DateTime.Now and Transact-SQL's GETDATE() function, and switch it between summer and winter time at the appropriate moment.

It's important the Azure team get time right, so next time you discuss Azure with Microsoft, ask them what time it is!