JNT Visual - Fotolia
How Kubernetes has simplified Bet365’s software deployments
Online betting company has begun using Kubernetes to make it easier for its IT infrastructure and product teams to share complex configurations
Gambling website Bet365 has gone live with a Kubernetes cluster to enable its product teams to deliver new software more quickly.
The online betting site has tested how to containerise a video-serving feature on its website. Kubernetes is providing both the IT infrastructure and the software product development teams with a common language and framework to specify, configure and deploy containers.
Describing the company’s software release cycle, Alan Reed, head of sports development at Bet365, says: “We come from a traditional Window background and have an intense release schedule. Our in-house release team wanted to improve the speed of release, but we found we could do one to two releases a day.”
As the business grew, the product team needed to find a way to speed up the software release cycle.
Jim Nightingale, principal infrastructure architect at Bet365, says the company’s IT infrastructure team was tackling a very similar problem. The team had previously used a service-oriented architecture to support the product teams, but found it was struggling to configure and deploy servers at the rate needed to push out new software-powered products.
Nightingale says: “As Bet365’s architecture has become more complex, we have noticed a growing grey area around responsibility for configuring the platform. There are elements of configuration and tuning that are deployed across the stack, which would traditionally be the remit of the infrastructure team, but need to be undertaken by product teams.
“The result is two teams touching the configuration items and this added complexity increases the potential for error.”
Using Kubernetes, Bet365 now has a platform that product teams can deploy in a scalable manner, says Nightingale. It offers the company a common framework for describing complex server configurations that the IT infrastructure and product teams can share. “We have a common language that both parts of the business can use. It is a common language and so avoids confusion.”
The company is making use of containers, which can be deployed in an automated fashion using Kubernetes.
“Containerisation enables us to decouple this complexity and clearly delineate responsibility between platform and deployment,” says Nightingale.
The size is right
From a software development perspective, Reed also wanted to take advantage of containers, which could then be orchestrated using the Kubernetes platform. “Kubernetes can orchestrate very complex [infrastructure] requirements,” he says. “You can also move around multiple IT environments very quickly.”
Once Bet365’s product team decided to use containers, the next question for Reed was how to size them appropriately. The product teams prefer small, so-called delta releases, rather than major updates. “We are a huge believer in high-volume delta releases,” he says. “You lose a lot of flexibility if you are doing large software releases.”
Reed says it was not feasible to use containers to separate deployment code from code that needs to go through quality assurance. In his experience, such separation would not be able to deliver the agility that Bet365 needed.
Another theory he considered was separating the website into containers. “We previously thought we would have one container for the website and one for the mobile site,” he says. “But a container doesn’t have to mean a monolith. It doesn’t have to contain the entire footprint of your IT environment.”
For Reed, a container should be self-aware, highly deployable and have metrics to guarantee success. “We took a diametrically opposed view,” he says.
For its Kubernetes test case, Bet365 looked at how it could introduce live video streaming on its Italian horse-racing site, says Reed. “Italian horse racing is the perfect test case. We needed a candidate that was malleable enough, atomic enough and portable enough to demonstrate that we could make Kubernetes work.”
The team’s goal was to build something from the ground up that was self-contained. “Italian horse racing is a very good example of how we can split a feature from our website – as a micro product which is separate from the main site,” says Reed.
Read more about Kubernetes
- In this guest post, Rob Greenwood, CTO at Manchester-based cloud and DevOps consultancy Steamhaus, sets out why the emergence of Amazon’s managed Kubernetes service is such good news.
- Kubernetes support for Windows nodes was declared stable in Kubernetes 1.14, but extensive fine print remains.
Among the risks in using Kubernetes is the fact that the platform is evolving very quickly, which means it is far too easy to get carried away with using the latest and greatest new feature, says Nightingale.
“There is a huge ecosystem around Kubernetes,” he says. “We got lost in the art of the possible and tried to create an incredible platform. We were coming out with a monster, but understood we needed to deliver something that was straightforward.”
The team cut back on the use of new Kubernetes features, he adds. “We wanted to keep it simple and make sure it was manageable, so we could support it ourselves.”
Nightingale says the move to Kubernetes also involved a move off Windows and onto Linux-based IT infrastructure. “We have been moving to a Linux workflow and feel more comfortable with the platform,” he says.
Reed adds: “In many ways, this is a natural next step for us. Our move to Linux and recent successes with Golang, the language of Kubernetes and containers, have delivered the right environment to make containerisation possible for Bet365.”
