Case Study: HRZN iGaming Platform

In this post, we feature a Q&A with Ievgenii Shepeliuk at New Age Solutions, a division of Axios Holding that builds a B2B iGaming platform. Ievgenii started at New Age Solutions almost 4 years ago as a software developer, in recent years has been shifting more towards DevOps and operations, and is currently the acting CTO for New Age. Founded four years ago, the New Age platform has been in production for three years and serving businesses with their platform. 

Technology Strategy and Challenge

Last year we looked at the industry and community momentum around Kubernetes and our own growth and decided to migrate our platform to Kubernetes from Docker Swarm. Our platform is an event driven microservice application with over 100 microservices. As part of this migration, we also had to re-evaluate areas of our stack to work in a Kubernetes environment. The API gateway was one of those areas as we needed a solution that integrated better with Kubernetes and can handle our scale. We have about five million business transactions a day and each transaction equals one to two hits to the API gateway. 

[featured_boxes class=”quote”]

“We chose Gloo as our API gateway for our platform migration to Kubernetes for its robust features, Kubernetes-native architecture, and technical vision with the integration of WebAssembly. The documentation and active community make it easy to get started and provide a lot of help and support for end users like us.”

[/featured_boxes]

Describe the Solution and Technology Stack

We started the migration to Kubernetes in June 2019 and went to production in December with Kubernetes using Kong, our previous API gateway. In the new year, we started an evaluation for Kubernetes native API gateways that led us to Gloo.  

We are now in production with our new Kubernetes based platform with the following technologies:

• Development –  We use JVM and Scala, NodeJs, Python
• Infrastructure – We are running on AWS EC2 instances and kops to get the Kubernetes clusters up and running. 
• API Gateway –  We are using Gloo open source from Solo.io as our API gateway with a custom authorization server set up. 
• Streaming Platform – Our event driven microservices are extensively using Confluent Platform for storing and processing millions events per day
• Monitoring – Ours is a pretty standard Prometheus and Grafana setup to gather metrics and display as dashboards.
• ChatOps – We use Slack extensively at our company and we implemented ChatOps by having alerts sent directly into different channels for problems in our infrastructure or system. 

Right now, we have about 20% of our services in Kubernetes across seven different clusters for development, testing, staging and two production clusters. This is in parallel to our legacy Docker Swarm cluster and we have some hardcore routing set up for the services to communicate between the Swarm and Kubernetes cluster as we continue to migrate the rest of our services to Kubernetes. 

Why Gloo

In our new API gateway evaluation we looked at Gloo, Ambassador and Traefik and the team decided on Gloo for the following reasons:

• Kubernetes Native – Gloo just looks like Kubernetes with its architecture using Kubernetes CRDs. This allows us to take a declarative approach in implementing traffic routes.
• Routing Table Feature –  This feature was released during our adoption period and it is really great. Instead of doing static configurations, you can configure the selector on the virtual service once and then dynamically add/remove routes by creating route tables that match that selector.  
• Open Source – Gloo and that provides a good set of features to use for free in the open source version even with an enterprise version. 
• Community Support – The Solo.io team is very responsive in the chat, fixing bugs, open to suggestions, and the developer community in Slack is very active and helpful.
• Documentation – The documentation is very robust, clear, and easy to understand – so that is very helpful.
• WebAssembly Hub – We are really interested in the work on WebAssembly Hub. I believe this is the future of Kubernetes development and are looking forward to digging into WebAssembly in a couple of months. 

Describe the Outcome and What’s Next

This year, our primary focus is to complete the migration to Kubernetes and Gloo off our Docker Swarm environment. And next year we plan to increase the traffic to our platform by 5-6 times. Additionally, this year we are interested in what we can do with WebAssembly and service mesh. Specifically if we need a service mesh and then which solution to use since we don’t use a service mesh today. We have done some research and investigation into Istio, but will do more. And as I mentioned before, I am excited to have the team spend more time on WebAssembly and using WebAssembly Hub to build custom extensions. 

[featured_boxes class=”featured-box”]

Learn More

• Learn more about Gloo Open Source and Enterprise
• Join the discussion in the community
• Sign up for an upcoming event

[/featured_boxes]