Alan Reed, Head of Sports Development, Hillside Technology, part of bet365, explains the tools and skills needed by his firm, including programming language Golang
Originally published on computing.co.uk
New problems demand new tools.
The challenges we face in 2018 are inherently complex. Delivering an always on platform that supports real-time applications for 100,000s of concurrent users at peak, has meant consistently breaking new ground in both the way we work and the technologies we use.
The result, bet365’s betting platform is powered by an intricate web of systems that must work in harmony. What’s more, each individual system is a marriage of technologies that have to integrate effortlessly.
As technical complexity has increased, so have the challenges of integration and maintenance. You need more people to consult on and support the code base, which results in knowledge becoming fragmented.
We have platform specialists with a deep understanding of our legacy stack. Technologists who specialise in each of the technologies we use and subject matter experts who are authorities in the different elements of our offering.
With so much diversity and specialism, trying to write good code becomes much more difficult.
More people are needed for every project. Each with their own specialist skills, who then must communicate with others who have a different mindset and most likely speak a different technical language.
When developing a new system, there’s a high degree of complexity in just trying to unpick the problem at hand.
The Impact of Complexity on Development
Generally, we have a traditional Software Development Life Cycle. We take the specification, write code against it, test for performance and then implement.
Despite the increased complexity, developing new systems has been largely unaffected. The real issue is integration and maintenance. We found that maintenance cycles were becoming much longer than the development cycle. Support queues were increasing. There was no such thing as a minor change.
Many of the challenges we faced were inherent in the way we write code. We have to write a lot to make it both performant and resilient. Resilience is where the volume really increases. You’ve got to be prepared for the unknown of the live environment. The ‘What If’ scenarios.
Enter Golang
Our Golang (Go) adventure began like many others. A couple of people within the organisation gently nudging us towards a new technology.
We were aware it was trending, but we’ve learned to wait a little. We want to make sure the new tech isn’t a passing fad and the platform is stable. Go was attractive because many of the challenges we were facing involved highly available, concurrent and performant systems. Problems for which it was building a good reputation for solving.
Once we’d started to play around with it, we found it to be incredibly performant. You don’t have to write as much code to solve a problem. Not only that but it also integrated very well with the other technologies we use. It’s like a glue that binds everything together.
One of the challenges you face in software development is there’s often multiple ways of writing the code to achieve the same result. Because of this, you can be up and running quite quickly but then you spend time optimising, to ensure it performs well.
Optimisation is one of the hidden costs of development. Everything we do is real-time, so our systems have to be optimised to avoid latency.
Golang was different. No matter which way we wrote the code it was performing well. We had less code, less changes and yet the run time was generally faster.
The Impact of Golang on Development
One of Go’s strengths is its simplicity. Because it’s a relatively small language, you can spin up systems relatively quickly. Rather than procrastinating over the syntax, you can spend your time writing.
This has meant we can specify, develop and test very quickly. We can iterate at pace, tweaking and ironing out problems as we go.
We’ve also found it’s enjoyed rapid adoption amongst our developers. Because it has a low barrier to entry, people feel comfortable with it very quickly. There’s a willingness to share.
And because several teams were going through the same journey at the same time, there’s a greater spirit of collaboration. Knowledge isn’t held in one place. Everyone is taking the journey together.
In just a few weeks, people were very conversant in it and were able to speak with people who had been using it for some time.
It also works across Linux and Windows, which makes it a great leveller. As we take on more Linux systems, it provides a stepping stone. It is a great join between people and technologies.
For the first time in quite a while, one team can talk and the other understands.