In the first part, we’ve taken you through benchmarking and choosing and the right frameworks by using PoCs, now we’ll take a deep-dive into our app.
Multi-product, multi-brand app
The big challenge was how to deliver several products for multiple brands from the same codebase, with no overhead or performance penalties when developing new features. Similarly challenging is that everything needs to be easily maintained.
Power Betfair, we use a microservices-like architecture. Since most of our
services aren’t customer facing, the backend part of our website has to
aggregate data from multiple sources, compute it and then serve to the client.
Just a few
days before the World Cup started, we sequentially released a major rework of
all our Gaming sites covering both redesigning all the products and a complete
under the hood revamp. Rebuilding our technology stack was a massive effort
across multiple teams and departments, ranging from Product, Design and
Marketing to Tech, Content, SEO and the list goes on.
lengthy article we’ll talk about our journey through choosing the right
technology, learning from different mistakes and ultimately achieving what we
set out to do.
The Betfair Exchange is a truly 24/7 product as part of a global business, both in terms of the customers that bet on it and where the events they are betting on take place. Uptime and stability of the Exchange technology stack are of paramount importance to the business and its customers. Even a few minutes downtime could mean a huge loss in revenue and customer impact, as an important horse race runs without any in play bets being placed or a customer misses a crucial trade out opportunity as part of their carefully tuned betting strategy. Therefore, keeping the Exchange platform running and having an early indication of any problems are always at the forefront of our minds on the Exchange development team.
At Paddy Power Betfair (PPB) we build software not only for us and our direct customers but also for several partners. We’re responsible for empowering them to run their betting businesses without having to build and run a whole infrastructure from scratch.
Some of the web applications we build for our external partners run within our infrastructure but are meant to be used by both, us and them.
The Technology Strategy team in PPB was formed in November 2017 and has since worked on a strategic vision for technologies on the horizon, or “2021 vision”. Our team’s contention is simple: the history of emerging technology, particularly that which is characterised as disruptive, means it always warrants a keen eye.
Often waiting for maturity is a more cost-effective approach to using something which another entity will do the groundwork on. The danger, however, lies in how pronounced a disruptive effect someone else could have with that technology in the meantime.
Last summer, we opened vacancies for summer internships at our Porto office, Portugal. Our goal was to introduce students to technologies and development methodologies that we have here at PaddyPowerBetfair and present them the opportunity of working side-by-side with our team on a project that would not be forgotten in a matter of days.
This post focuses on the internship experience of Margarida, from the Faculty of Engineering of the University of Porto, and Pedro, from Polytechnic of Porto School of Engineering, who worked as a team member from June to September 2018.
Hello, this is the first in a series of blog entries we intend to write about all things Site Reliability Engineering at Paddy Power Betfair. As this is our first ever blog post (so please be kind!), we thought we’d write about a straightforward project we ran recently, our low frequency reporting platform. We’ll discuss what we built, why we built it and some of the outcomes we saw. This project is quite simplistic, and likely not 100% transferable to your estate, however, hopefully our thoughts on the project may be useful, even if the detailed “how we did it” would not be :). The framework was delivered over a few sprints, the services running on it are continually being developed.
What is a Low Frequency Reporting Platform?
During our day to day work, we have discovered the need to collect and process lots of small datasets at a relatively low frequency such as daily or hourly collections. These include reports such as hardware health, app performance or information from ServiceNow. The typical way this is tackled in our environment would be to create a service or App – internally known as a TLA (we name them generally with a three letter acronym). All TLA’s are deployed with an A or B appended to their hostname. An update and re-deployment of a TLA using “A” will become “B” after re-deployment is complete. The next deployment will then become A, then B, etc… Rather than develop individual TLA’s for each little project, we decided to create a framework to host “small” services.