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!