Pokemon Go: A Viral Event
Last count Pokemon Go had rough 20–25 million active users (GameSpot — 2016.07.23). By this time, I’m sure you’ve heard about the outages and the multiple malicious distributed denial-of-service attacks (DDOS). DDOS attacks are based on 1,000s or 1,000,000s of remote controlled machines meant to overwhelm a service like Pokemon Go. Viral events are substantially difficult problems to solve, in the case of a DDOS how do you differential between 1,000,000 bots throwing multiples of 10Gbps traffic at your servers, over the 1,000,000 clients who are interesting in using and paying for your services?
If you have never played, the basic premise is a GPS based game which rewards you for exploring your surroundings, capturing objects with in-game value and challenging other players. The founder of Ninatic, John Hanke, mentioned he love to explore the areas around him as a child and wanted to bring that sense of adventure to a much larger community of people.
I have always found viral events astonishing. In past roles we dealt with these often, from my experience the system architecture, technologies chosen and team structure have everything to do with success in handling a viral event. One of the most memorable events was during one of the 2010 FIFA World Cup matches Diego Forlán scored a goal, which triggered a 35 million user base to instant message each other that he scored. Truly a single event viral spike; how do you even plan for that?!
Pokemon Go has a great deal of similarity in Ninatic’s sibling game Ingress.Their apis are roughly developed around protocol buffer payloads and RESTful api calls. So the engineering teams at Ninatic have already seen their application, in a variation, perform in production. They were practiced and knew which parts of the platform would need help first, allowing them to prioritize the sections of the application to address and scale. Additionally, the community has already dissected and reverse engineered the code base, launching a secondary market around hacks, bots and introspective services to game the game. Truly it’s an interesting ecosystem, a topic Ninatic is likely keenly aware of. They have the opportunity to leverage this community for success or failure.
Many of the fundamental design principles which are applied to viral platforms and architectures, also apply to my clients. Often these clients are dealing with spike demand, consistent trending traffic and load based on single or rare event demand. From these past experiences, I’m able to work with clients to help them design systems, architect platforms and structure teams for the same successes we see in other viral platforms.
Within my group, Helion Professional Services, we work with clients each day who demonstrate the need to solve these same challenges. We seek to build trust, creditability and value with clients to we might empower them for success. HPE has an entire suite of services and products which align HPE to be a partner is helping a client realize their vision of success. How can we help you be successful with your next viral event?
About the Author:
Kevin Stoll is the Cloud Solution Architect with HPE and an expert in all things Cloud Foundry. His role is to empower organizations by leveraging reusable Cloud and Automation solutions and/or architect custom solutions to best meet organizational needs. Kevin has had the luxury of assisting many other big enterprises successfully implement new tools such as HPE Helion Stackato and HPE Helion Eucalyptus.