November 2022

Creating a new cloud platform for the University of Exeter

The University of Exeter, Loomery’s longest-standing client, has recently embarked on an ambitious digital transformation, rethinking all of the digital services students interact with.

The cornerstone of this work is a new mobile app for students to access everything they need in one place. You can read more about how a cross-functional Loomery team built the app here.

Beyond the app, the University’s recently appointed Chief Digital Officer, Ash Roots, has a vision of creating a platform of shared services to accelerate digital innovation at the University.

I led the development of this cloud-hosted platform in Summer/Autumn 2022, pairing with another Loomery engineer and working closely with an architect from the University. The new student app is the first consumer of our services.

For those interested in the techie detail, I wanted to write about the architectural and engineering decisions we made breaking ground on the University’s new platform of shared services.

Adopting an event-driven, microservices architecture for resilience, agility and flexibility

We decided on an event-driven microservices architecture.

As the engineers amongst you will know, microservices are a well known architectural pattern for developing loosely coupled services as opposed to an ever-bloated monolithic application. They make things flexible, particularly as you grow and scale.

Being ‘event-driven’ is a way to further decouple things. Instead of Service A specifically triggering Service B via a REST call, it can communicate with it via an indirect mechanism. This allows Service A to continue about its work and let Service B operate independently. It often increases the speed at which Service A can handle a user request.

There is also a level of independence between the services, providing resilience. If Service B fails then it doesn’t impact Service A directly. In the case of failure it is a more contained failure which can be retried independently.

Two of our first features - a study space booker and a student calendar - were linked, as the bookings should be visible in the calendar - but are not so tightly coupled that it made sense to build a single service.

Taking an event-driven approach also made things flexible and quick to adapt. As new services become available which emit recognisable events, we can ingest those with very little change required. For instance, when we expanded our calendar to include student union events and social events, it was rapid to implement, as we’d built the service and frontend to accommodate an event template.

Building on AWS services for speed of deployment, scaling ability and cost efficiency

The microservices were built using AWS Lambda, API Gateway with Cognito for client authentication, DynamoDB for persistent data storage. We deployed them using Amazon’s CDK (Cloud Development Kit).

We picked these specific AWS services as they are all “serverless”. If you are not using them then they scale down to nothing, with zero or little cost. When they are in use, they scale to the current load. With 30,000 students plus almost 7000 staff at the University, demand can be exceptionally high during term time and almost non-existent during the summer break.

Taking a test-driven approach for quality assurance now and in the future

We took a test-driven approach to building the services based on the requirements. Developing in this way helps you to focus on what you are actually building, breaking it down one test at a time to build the features you require. Longer term this has the advantage of ensuring the code is well covered by tests and we can reliably make changes to it with less fear of breaking existing functionality - particularly helpful as junior engineers were brought on to grow the team.

Once at a reasonable level of progress, we integrated with the front end application as early as possible to iron out any differences between spec and the ultimate reality.

Following a RESTful standard for now, with real-time GraphAPI to come

Our initial API was RESTful. REST stands for “REpresentable State Transfer”, which is an API widely used across the internet. However, it is very transactional in its nature and often requires updating to expose additional fields and features.

That’s quite different to a Graph API, which exposes the ability to request specific fields from a set of nodes, or “a graph”. You could, for example, request information about a University building, all of its rooms and bookings in one go, and subscribe to be notified of changes to that dataset with Graph.

For future iterations we are going to be using AWS AppSync to provide a Graph API with subscriptions made available to clients so they receive real-time updates when something relevant changes.

For developers, this means you don’t need to worry about when to refresh data from the backend. For users of the digital product it results in a slicker experience as things update as they happen, and not just when a user action forces the app to refresh.

Powering digital services across the University far into the future

We’re proud to have delivered a new cloud-hosted backend for the University that can be reused and extended. The result of the last few months’ work is a platform of adaptable and scalable services, initially consumed by our new app app, which can power many more digital products and services in the future. We’re excited to see what the University of Exeter’s digital teams can achieve.

Score your team against the 8Cs

Sign up below to receive a worksheet to score your team against the 8Cs, and a guide to some smart next steps based on where you score lowest.

For information on how we use your contact data, please read our Privacy Notice.

Thank you! Your submission has been received!
Oops! Something went wrong while submitting the form.
Discover more insights
'