Anywhere, anytime, any device
Wordament's cloud architecture
By: Sidney Higa and Walter Poupore
C# | Cross Platform | Azure
When Jason Cahill and John Thorton began coding the game, it was vastly different in architecture. At that point, they expected only a few friends and family to try it. Wordament quickly took off and grew in complexity. What you see now is a product of time and many changes, and it's now a model for handling a huge number of concurrent users. Wordament is built entirely on Microsoft Azure Cloud Services with no virtual machines.
Wordament is built using only Cloud Services, a fact that Jason and John are quite enthusiastic about for a few reasons.
Azure Cloud Services gives them an infrastructure that is updated automatically — no manual upgrading of the system needed. “We don’t want to do the job of IT management, patching machine images!” says Jason, referring to the management that’s necessary with virtual machines.
Another feature that makes the Cloud Services model so attractive is the Virtual IP (VIP) swap. The VIP swap allows them to stage a new version of their service every single day as they rebuild and redeploy the site.
The result is a minimum loss of service because the IP address simply gets redirected from the old version to the new.
Cloud Services segregates each major piece of architecture cleanly from the others. Each service has its own set of responsibilities and behaviors. This division of labor simplifies understanding, coding, and troubleshooting. 
Listen to Jason and John tell the story of how they created two of the most popular games today.
<iframe src="https://channel9.msdn.com/Blogs/One-Dev-Minute/One-Dev-Story-The-developers-behind-Wordament-and-Snap-Attack/player?h=540&w=960&format=html5" allowFullScreen="true" frameBorder="0" scrolling="no"></iframe>We don’t want to do the job of IT management, patching machine images!
Download the full architecture diagramWordament is built of several components, some are apps (the clients) and the rest are cloud services. The backend is built with several discrete functional units: the Visitor Center, the Game Room, the Aggregator, and the Leaderboard Orchestrator, which use of authentication services, Azure storage, and an Azure SQL database.
The clients are the apps that game players download to their devices. Wordament is a cross-platform game that can be played on Windows Phone 7 and 8, Windows 8 and 8.1, iOS, Android, and Kindle. Each app is developed for the particular device, but the Wordament apps on each platform all look and behave in the same way. Each client has a thin hardware abstraction layer (HAL). It contains the code necessary to display and process the Wordament UI controls, along with the code that initiates contact and interacts with the Azure cloud services, such as the Visitor Center and a Game Room.
Game Room (GR)
The GR is specific to the puzzle player's language. so European languages are housed in European data centers, for example.
The client pings the GR, and the GR responds by sending it the next game. The interaction between the GR and the client consists of only 3 APIs.
- Send Game: The GR sends the current puzzle to the client.
- Post Score: The client app sends the game results to the GR.
- Send Results: The GR sends the leaderboard to the client, along with the next puzzle.
In the VC, you'll find the leaderboard results and a directory of gamer IDs. You can also find friends on the system through the leaderboard. When the player starts Wordament, a short sequence occurs:
- The client app contacts either Facebook or Xbox to authenticate the player with a username and password.
- On authentication, Xbox or Facebook returns a security token to the client app.
- The client app sends the VC the security token to confirm the user.
- The VC contacts Facebook or Xbox to verify the token.
- Once confirmed, the Visitor Center sends the client app a new URL that goes to the Game Room where the user will be playing.
When a game ends, each client sends the player’s score to the GR. The GR has an Azure load balancer in front of it that distributes the results to one of its three web roles. Because the results are randomly distributed, they must be gathered into one central spot—the aggregator.
After a game is over, all the scores for thousands of players are collected together in order to rank everyone. This is done using an Azure cache which acts only as a temporary repository for all the scores. Only after all the scores are collected in one place can the ranking start. The entire set of collated scores is picked up by the GR web roles. Each GR web role sorts the scores into ranked results and creates a master stack.
Since all web roles have all the same data, all the stacks should be identical. If the stacks differ from one role to the next, then the system can flag the web role in question and redo the ranking. "It’s faster and easier to start a new web role rather than trying to ‘fix’ it." according to Jason and John. Finally, the uniform results can be sent back to the client apps.
Technology Primer
Azure has four compute models, each optimized for different uses:
- Azure Web Sites executes server-side code such as PHP, ASP.NET, Python, Java, and node.js (along with SQL for databases). You only worry about the website code—not the system that it runs on.
- Virtual Machines (VMs) include nearly everything that a hardware-based system contains—an operating system and virtual disk space, in addition to the virtualized processing power. Like a real machine, you are responsible for installing software and keeping the system patched.
- Mobile Services is a turnkey backend for any connected client app. It provides server-side storage and user authentication, and handles push notifications. A single mobile service is often used to coordinate app activities across client platforms.
- Cloud Services are made of roles, each of which is adapted to specific kinds of tasks. A web role is built to communicate on the web using IIS to serve websites or web services. A worker role only runs the methods of the application—it's a VM dedicated to computing without the overhead of IIS.
After the ranking and returning chore, the LBO starts its work. The LBO works in close partnership with the two database stores that conceptually flank it to create the “Best of” lists: best of right now, best of the hour, best of the day, best of the week.
After the results are collected, they are written to blob storage. Then the LBO gets the results from the storage. It then processes the data to create in-memory tables that are inserted into an instance of Azure SQL Database. Once the data is inserted into the database, a large number of queries in the form of stored procedures can be run against the data. To preserve the integrity of the data, stored procedures are the only way used to determine stats. As the Wordament guys say, they generate “a small number of tables, but a large number of stored procedures.”
The Headquarters service is used to run tests against the various other parts of Wordament. For example, it runs the synthetic transactions that makes sure the game rooms are working. It also checks the integrity of the database operations. If a worker role running an operation creates a result that is different from others, the worker is terminated and a new one started. The headquarters handles those administrative and quality assurance duties.
Deployment
Although not a part of the game process, the deployment mechanism contributes to the success of Wordament. Using automation, the system is rebuilt and redeployed every day, and that keeps all of the bits fresh and healthy, and it also means that fixes and upgrades can be rolled out regularly. As shown, this is accomplished using a single server that runs a script at the prescribed hour. The script invokes the Azure Management APIs to accomplish its tasks. The large management API is another advantage of using the Azure platform. Nearly every task can be automated.
That concludes a tour of the game’s architecture—which is not exclusive to games! The structure is the product of time and refinement, and the lessons are applicable to many kinds of apps being built on Azure.
Highlights:
Build on a Platform-as-a-Service architecture enables you to rebuild the whole system on a daily basis.
Leverage third-party authentication providers to save time for yourself and your customers.
Aggregate data distributed to many worker or web roles with a cache.
Separate data services from outward facing services to provide an added layer between malicious entities and your data.
Use a headquarters service to perform checks and maintenance duties.
Reduce management overhead using Azure Cloud Services.
Part II—Wordament: Developing a cross-platform app
In the next part of this three-part series, we’ll look at how the Wordament team develops client apps for many platforms—Windows, iOS, and Android—with next to no complications.