The Challenge
The customer has an online gaming platform which boasts a huge selection of slots, jackpots and table games provided and hosted by various leading gaming providers. Gamer’s account information and ‘wallet’ are managed securely by a separate provider so it needs a system in the middle that acts as a proxy to communicate between the gaming providers and the secure account information.
For the customer, the key challenges have been agility and scalability.
Scalability has been a challenge, especially given the nature of the business with peaks and troughs of traffic and on-premise infrastructure. During peak-times, the customer sees millions of transactions in short time periods tapering off to the thousands.
Agility has also proved to be a major issue. The customer’s architecture is based on a Microservice approach but antipatterns have provided none of the pros and many of the cons. This architecture has added to the scaling issues and made innovation on the platform slow and cumbersome.
The Solution
The customer was confident that the issues it was facing could be resolved with a serverless, event-based architecture. It believed the proxy code that communicated with the component systems could run purely on demand and be mostly stateless. The key benefits in pursuing a serverless architecture were:
- Flexible Scaling –The application can be scaled automatically
- Automated High Availability – Serverless provides built-in availability and fault tolerance without the need to architect for these capabilities since the services running the application provide them by default.
- No Server Management – No need to provision or maintain any servers. There is no software or runtime to install, maintain, or administer
- Pay For Value – Paying for consistent throughput or execution duration rather than by server unit is a compelling use case for a pay per play application.
From an architectural standpoint this was the customer’s first venture into serverless technologies, and as 90% of the internal platform followed the same structure it was almost a technology PoC to understand if in the long term this could be used across all the platforms.
Opting for Amazon Web Services (AWS), having had some experience previously, the customer’s architects drew up a high-level design and then approached AWS and Cloudreach to validate their Architecture and build a Proof of Concept to demonstrate this could work for the Games Platform. Cloudreach completed a PoC for the Gaming Platform, that was originally years in the making, within five weeks. Following this, the customer’s internal teams spent five weeks understanding the PoC and delivering their interpretation which was scheduled to go live Feb/Mar 2019. Using API Gateway, Lambda and DynamoDB the codebase has been reduced from 120k lines of code to 15k.
The Outcome
The Cloudreach team validated the serverless architecture concept provided by the customer and proved it could work in practice by building a fully functioning prototype that the client can now adapt and move into production. Once implemented, the solution will allow the client to move away from its existing server-based system to a more scalable, easy to maintain system that reduces latency, cost, and complexity. Cloudreach was also able to advise on how to calculate the running costs with the variables that would influence costs. This proved that the per-transaction costs will be very low running this solution in AWS.
The customer now has a solution that its engineers can confidently bring to market. The serverless technology will be rolled out to other games enabling the customer to manage fluctuating traffic levels ensuring a great gaming experience whilst containing operating costs.
About Betfred
This customer is one of the largest bookmakers in the UK, with over 10,000 employees. The company has over 1,650 licensed betting offices (LBOs) and also operates through online, mobile and on-course channels. It is one of the fastest growing eGaming businesses in the UK.
