Learn how Bing Maps and Windows Azure were used to provide mapping for the London 2012 Olympic games website enabling millions of visitors to explore the games.
- Virtual Technical Solutions Professional- Hopefully that’s the last cloud you’ll see in a slide deck today, but I doubt it
Lets start by defining what we mean by the cloud, here is my definition…That’s right, I’m not actually going to try and TELL you how wonderful the cloud is and that we should all move there tomorrowI’m aiming to lead you through the real world example of the mapping solution for London 2012, and SHOW you why I think the cloud is so important to the future of web mapping
The web mapping for the London 2012 games was very much a solution delivered by a teamTwo Microsoft Bing Maps Partners, lead by Earthware, doing the development and supportTwo Microsoft platforms providing the services and infrastructure
With that kind of estimated usage, and the need to get 35 servers up and running in 3 weeks, there was no way a traditional hosting solution could have delivered, and the deadline wasn’t going to moveWith that few development days an existing rich and flexible mapping platform was essential
There are four key areas I wanted to show you how azures cloud based services and Bing Maps helped our two partners met or exceed these challenges
Database tools were needed both to allow quick administration and fast, scalable searchingSQL server an ASP.net dynamic data allowed us to create full administration tools in hours not daysSql server used for storing and updating spatial data for torch routesBut SQL server would have taken a long time to setup and administer to deliver the same search performance as LUCENE as its especially designed for searching allowing us to duplicate and sync the data across infinite servers to deal with extreme loadBoth SQL server and Virtual Servers to host Lucene were available on demandLucene services monitored by and azure based service with custom rules to auto scale
Tiles were used to show the street level torch routes (all ? Miles of them) and were often re-generated more than once a day as the start day approachedTiles were used rather then polylines to be able to display complex image effects like drop shadows and glow so the user could see the section of the route they had selected, and also to allow instant re-used in the mobile apps created by another companyAs you may know storing millions of map tiles in a traditional file system quickly becomes unmanageable and more importantly slow to retrieve, a cloud storage system like Azure’s blob storage is perfect for tile storage INSERT STATS about how many we didUsing the existing Bing Platform solved many of the initial requirements without any extra development work
Using windows Azures multiple server and network reliability and Bing Maps performance and uptime guarantees our partners were able to deliver on their promise to ensure there maps were always available around the globe. In over 6 months of maps live on the London2012 website the team didn’t receive one single support callBing Maps uses all the power of Azure to deliver scalability, reliability and availability around the world as standard
Using Bings more ‘muted’ map style allowed the games data to be the real star of the mapsOS map styles built into Bing Maps allowed users to choose their perfect styleBecause of Azure massive cloud architecture and support systems, issues like protection from Denial of Service attacks, security patches and secure access, which were core requirements from LOCOG, were available seemlessly from day one with no overhead on the partners
- 35 servers estimated to handle suggested daily map loads- 8 services actually used at the peak times (less than 2 weeks total)- 2 servers used (for failover) 99% of the timeWould have at least cost £75 per server per month x 35 servers = £2625 per monthActual cost at peak was £1oo for 2 weeks (2 servers) + 750 for 2 weeks at 15 servers = £45082% cost reduction at peak on initial estimate, mostly due to partners ability to optimize code and shorter peak periods than guestimated and because LOCOG only paid for the server they were using, not what was available for peak demand