Microsoft to open-source cloud framework behind Halo 4 services
- 13 December, 2014 09:03
Microsoft plans to open-source the framework that helps developers of cloud services like those behind the popular Halo 4 game.
Building cloud services for millions of users means connecting and coordinating thousands of servers, and handling tasks and information across all of them. Project Orleans is a framework built by the eXtreme Computing Group at Microsoft Research using .NET, designed so developers who aren't distributed systems experts can build cloud services that scale to cope with high demand and still keep high performance.
The Orleans framework was used to build several services on Azure, including services that are part of Halo 4, and Microsoft had an enthusiastic response when it released a public preview of the technology in April this year. Now Sergey Bykov of the eXtreme Computing Group says (http://orleans.codeplex.com/) they will open-source the project.
The code will be released under an MIT license and will be published on the GitHub site in early 2015 (instead of Microsoft's own CodePlex open source site); they say that they plan to accept contributions to the code from users.
Orleans is designed for building cloud services like social graphs (the list of friends on Facebook or the people you follow on Twitter), real-time analytics and interactive entertainment, and to work with large numbers of devices like smartphones or Internet of Things sensors. Halo 4 uses the framework for the presence service (which keeps track of all the game sessions, all the players and the status of each game) and the statistic service (which tracks details like when and where a shot was fired in a game and with which weapons, as well as the achievements and other personal information about players).
That information, displayed in the Halo Waypoint interface, is very important to players, according to Hoop Somuah of the Halo Cloud Services Team at 343 Industries, who explained how Halo uses Orleans at Microsoft's Build conference (https://channel9.msdn.com/Events/Build/2014/3-641).
"They need to know what the hot playlist is today, they need to know what the challenges are, they need to know where their friends have been, what their friends have been playing," Somuah said.
"Have their friends gotten more medals then them? They need to know all this and they need to react it and interact with their friends in real time. We need to deliver hundreds of thousands of updates per second to millions of players, and we have to get the right information to the right device at the right time," he said.
He called Orleans "a cloud native programming model that makes it possible to build services from the ground up, with the cloud in mind."
Orleans differs from other popular cloud app development platforms like Google App Engine because it's asynchronous; but it's also single threaded, so developers don't need to think about concurrency, locks or race conditions -- concepts that make concurrent programming complex to handle.
"With concurrency, it's hard not just to write the code but to conceptualize and think about what you need to do," Somuah said.
Orleans uses the idea of "grains" and "silos"; there are grains for each player in Halo 4 and there's a grain for every game of Halo 4 that's ever been played. Silos are the execution containers that hold the grains; there's one on each node and the Orleans system handles creating more silos if they're needed to handle more players and replacing any that fail under the load. Developers tell the grains what to do, but the Orleans systems take care of creating grains, reactivating them in a different silo if there's a problem, and garbage collecting them when they're no longer in use.
This makes it much easier for the developer, Somuah explained. "You don't care which machine in the data center a grain is running on or if it fails, you just work with the grains. You don't think about how many nodes you have in the system or worry about an IP address."
He compared it to not having to care about which stick of memory inside a computer a variable was stored on when writing code.
"You don't worry about that sort of thing when you're developing locally; why would you care about it when you're developing for the cloud?"