Last week we were very fortunate to welcome Duncan McDonald and Katie Stockton Roberts from the development team for BBC Bitesize. They spoke to us about how the technical architecture of Bitesize has changed over the years, from a hulking PHP monolith to a selection of independent microservices that combine to build the web and mobile applications.
Unfortunately we weren’t able to record the presentation but I’ve attached a copy of the slides below and, after the jump, provide an overview of what was talked about and how it might fit in to the University of Edinburgh.
Download slides (requires University login)
NB: This presentation includes videos and is over 400MB. Don’t download on mobile data.
This talk was organised by the Software Development Community and, if you’re not connected to us already, there are a myriad of ways to get in touch to find out about future events. If you’re a member of staff at the University then you can join the mailing list, or the Slack channel, and anyone can find us on Twitter and Facebook.
We’re particularly interested in hearing ideas for new events, talks and workshops. If there’s something you’d like to know more about, then we’d be keen to help you organise that. And if you have a contact that you think would provide an interesting talk to the community then we’d be keen to hear about them. We also have some budget to help with expenses like transport and catering. To get in touch, please email the organising committee.
When this journey of transformation started, BBC Bitesize was a monolithic PHP web application, pulling data from multiple services (like their internal content management system). As Bitesize developed, microservices were added to handle more complex data. Each microservice was designed to do one thing, and do it very well (for example, “Equation Chef” simply and consistently rendered LaTeX as PNGs).
Around this time, the BBC also decided to invest in having a Bitesize app for users to study on-the-go. They had a few options of how to architect it. One was to frame the website inside the mobile app, providing exactly the same experience in both. However, the web interface used lots of HTTP requests, which wouldn’t be kind to users’ data and might put them off.
They could also have built a separate monolith for the mobile app. It would mean the two products could be developed independently, but would have duplicated effort and led to twice the amount of technical debt.
Instead, they chose to employ more microservices which both the web and mobile apps could use. This would mean that improvements and fixes could be shared across both products, but they could have independent front-ends more suited to their platform.
Within the BBC microservices were popping up in different teams providing services like authentication and user activity tracking. The new approach meant that these could easily be added to Bitesize, and the Bitesize development team didn’t have to spend time building their own versions.
The BBC Bitesize app was therefore powered by a large collection of microservices, written in various languages, managed by a selection of teams inside BBC Education and out. Each microservice is clearly defined, with an effective contract of what functionality it provides, and developers are therefore free to focus only on the ones that they support rather than having to know the whole ecosystem.
The network for microservices also allows for quite granular graceful degradation: if a service that provides personalisation breaks or becomes unavailable then Bitesize can still show most of its content; it just temporarily hides the personalised sections.
However, microservices have also introduced a complex dependency network where upgrading one application might require several microservices to be changed first. It’s also led to some level of duplication and can make support work difficult (because of the amount of variety in what’s supported).
Overall though, they’re very happy with the change.
Moving to the cloud
During this time, the BBC have moved much of their infrastructure to the cloud and microservices have led the way. Cloud-hosting has improved reliability and provided options for automatic scaling (so the Strictly Come Dancing website can handle Saturday-night load). When bugs like Heartbleed need to be fixed, cloud hosting providers handle it and the BBC teams don’t need to worry.
Some BBC microservices have also made use of AWS Lambda, which runs servers on-demand so you only pay for what you use. This has proved valuable (and cost-effective) for services which have high server load but are run infrequently.
In general, moving to the cloud has provided greater capacity and reduced costs. Whilst the hosting costs may seem high, the money saved in setting up and maintaining physical servers has offset this.
The BBC Bitesize team continue to progress with their architecture changes. Now the mobile app is stable, they’re looking at how the web app can be improved. They plan to move it from PHP to Node.js, introduce closer monitoring and move it to the cloud.
To do this, they’re making use of the strangler pattern to slowly replace functionality of the web app with new or existing microservices and gradually strangle the PHP component until it is completely replaced.
Once this is complete, the team envisage being able to more easily improve the functionality and performance of the web and mobile applications at the same time. They’ll be able to focus on moving Bitesize forward rather than agonising over technical debt.
How does this compare to the University?
The idea of APIs and microservices is nothing new to the University of Edinburgh, though we have nothing on the scale of the BBC. Development services have been taking a lead not just in implementing new APIs and microservices but in defining standards and architecture that will make them easier to develop and support.
We don’t have much (any?) infrastructure in the cloud, though we have mostly moved from physical to virtual machines and have made some progress in containerisation to make applications and services more portable and cloud-ready.
And we certainly have some monoliths. Several core University systems are hulking black boxes that do an awful lot. EUCLID, for example, handles everything from admissions to graduations in one platform. Our one timetabling service provides scheduling, enrolment and export.
Our heavy use of vendor products makes strangulation more difficult, but there are certainly things we can do. Build new services to be small and efficient; reduce side-effects and unnecessary dependencies; and share services to reduce duplication and improve consistency.
Thanks again to Duncan and Katie for a fantastic talk. We hope you enjoyed it if you came along and that we’ll see you soon at a future event.