Casino In The Clouds


Published on

From the Gaming Scalability event, June 2009 in London (

This talk is an experience report from a recent online gaming project involving an extensive use of cloud and grid technologies. Gojko presents the benefits that his team got from a cloud deployment, such as low up-front costs and easy infrastructure provisioning and challenges and surprises including storage and monitoring issues. He then presents architectural impacts of using computing grids to power online casino games and talks about benefits, issues and challenges of gigaspace computing grids in a cloud deployment.

Gojko Adzic is a software craftsman with a passion for new technologies, programming and writing. He got involved with the online casino industry in 2002 and has since worked for leading UK online betting systems and some of the world's largest poker networks.

  • Be the first to comment

  • Be the first to like this

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Casino In The Clouds

  1. 1. Casino in the clouds Gojko Adzic Advanced Games Lab @gojkoadzic
  2. 2. The world's first social casino gaming network s
  3. 3. Why clouds?  Eliminate waste  Very high target volume  Scale up and down and save on infrastructure  Provide better service faster and cheaper
  4. 4. Are we spending our time doing stuff that really matters?
  5. 5. Eliminate waste
  6. 6. Very high target volume
  7. 7. Flexibility to scale up or down
  8. 8. Cloud economics: we develop and deploy faster and cheaper – so we have a competitive edge
  9. 9. Challenges and surprises  Monitoring  Load balancing  Shared storage  Pre-packaged systems  Security
  10. 10. Monitoring – no more flashing lights!
  11. 11. Load balancing – not your usual Cisco story
  12. 12. Network storage: only one at a time
  13. 13. Pre-packaged systems: always read the label
  14. 14. Security: How much can we trust them to do a good job?
  15. 15. To make the most out of clouds, the system needs to be designed for that!  Scale to lots of small boxes  Scale up and down  Expect boxes to go away and come online
  16. 16. No more simple fail-over
  17. 17. Solution: use grids We saved a ton of money and time by not building it ourselves  Data redundancy  Scaling to lots of small machines  Partitioning and task routing  Asynchronous persistence
  18. 18. Why we chose GigaSpaces?  Pay-per-use on the cloud  Fully transactional  Cloud support  Automated deployment tools  SLA for the grid
  19. 19. We still ended up rolling some features on our own  Asynchronous persistence  Simpler, faster  Deployment scripts  Reuse cloud machines, don't reconfigure the rest  Cut redeployment time from 2 hrs to 10 mins
  20. 20. Surprises  SLA cannot dynamically grow  Start with more partitions than you need then relocate  Only partial hot-deployment  Apparently improved in v7  Classloading  Wasted lots of time solving this  Also improved in v7  On a more positive note – fantastic support
  21. 21. Why not use this for production as well to scale it on demand?  Security  Regulatory requirements
  22. 22. Learn how to be friends ...
  23. 23. It doesn't have to be “yes” or “no”  It gives us a serious competitive edge  System broken down so that we can use it for the largest part  No unencrypted sensitive information there  Transaction processing not there  But the bulk of bandwidth is − Messages − Content − Web front-end
  24. 24. What we learned  Levels the playing field for startups  To make the most out of it, the whole system needs to be designed for clouds up front  Get a Grid  Solves lots of problems but creates some new ones
  25. 25. What I'd like to see in the future  Open Source grids  SLAs for the cloud  Solutions for regulatory/security issues