This story was originally posted on the ustwo blog.
Technical Architectural Evolution on The Body Coach
This is the first in our three-part blog series, describing the tech side of how ustwo went about helping The Body Coach to expand and develop their business to become digital-first with an award-winning app. Find the other parts here: Part 2, Part 3.
The Body Coach is a holistic health and fitness company that’s been on an incredible journey over much of the last decade. They started in the UK, but Joe Wicks and The Body Coach have quickly grown to be known around the world.
Prior to working with ustwo, The Body Coach delivered tailored fitness plans via a PDF in an email and leveraged YouTube to its fullest. While they had been very successful, there was only so far they could take the business with this setup. Many ideas they had were simply not possible to realise. In late 2019 they approached ustwo asking for help in understanding how to take their service to the next level and bring them into a modern, realtime, digital-first experience and ultimately deliver on their ambition. By March we had a direction set and kicked-off the build with a subsequent launch in December 2020.
Working with The Body Coach has been an amazing experience in developing a greenfield technical ecosystem for the next evolution of their existing proposition. In this post, we’ll dive into some of the key moments in the evolution of our technical architecture. Much of this will be focused on the interconnections of the various systems. Look for more posts in the future that will dive deeper into specific topics.
Ecosystem overview
In terms of the new digital ecosystem, the experience consists of three distinct frontends:
The primary customer experience is delivered through a native iOS and iPadOS app built with Apple’s latest technologies such as SwiftUI. Customers can create accounts, subscribe, tailor their health plans, engage with workouts both on-demand and live, cook through a variety of recipes, plan out their weeks, review their progress and more all within this app.
There is also a new website for the main dot-com experience built using GatsbyJS and TypeScript. Using a static-site generator meant we could easily focus on a content-first experience, deliver exceptional performance for the user, and do this all with ease for the developer.
Lastly, there is a TypeScript ReactJS website for Body Coach employees to log-in and manage the service. We used IBM’s open-source Carbon Design System to be able to rapidly build out this website and allow us to focus on the actual business logic that’s unique to The Body Coach.
To support all these various experiences, a new backend was built and hosted within Amazon Web Services (AWS) and managed by Terraform. We also connected with a wide variety of other third-party services to support the ecosystem, from Contentful and Brightcove to Google Analytics and Zendesk just to name a few. While iOS and iPadOS would be the first platform, we also knew that The Body Coach had ambitions to be on many other platforms in the future. Every technical decision made from day one needed to include this as a possibility to ensure we weren’t closing any doors along the way.
Overview of the core digital ecosystem
We utilised a number of other tools and services to support our development. For example we leveraged GitHub not only for source control and ticketing, but also for our Continuous Integration / Continuous Deployment (CI/CD) pipelines using GitHub Actions. Centralised app string management was done in Loco. A final key example of our toolchain was our use of GitHub’s Markdown Architectural Decision Record tool and process for aligning on and documenting core technical decisions.
Use of AWS
We knew that we’d need to store a range of backend data in the cloud and have a secure way of accessing it. We made a choice early on that we’d try to build up a serverless or functional architecture (more on that in a moment), which for us meant it made sense to lean on well-integrated pre-existing AWS services:
- Lambda Functions + Lambda Layers to move data from A to B, transform it, perform some side-effects or trigger other processes (all built with TypeScript),
- AppSync as our GraphQL API layer, for our client applications (the native mobile consumer apps and web-based Admin Portal) to flexibly request data,
- Cognito for user management for both client applications, and
- RDS Aurora as our primary database cluster, where automatic failover and auto-scaling based on demand is simple to configure.
These services seek to abstract away a lot of operational overhead and allow a sort of Lego-like composition of services.
High-level overview of AWS architecture. Note that this is an extreme simplification. We have hundreds of resources and are using dozens of distinct AWS managed services, most of which are not pictured here.
Why not roll our own API or set up a monolith application or use a container-based architecture? All the usual reasons: Avoiding the overhead of managing server ‘right-sizing’, security (manual updates, instance firewalls), service availability, some of the aspects of log management, and doing all this over time with fluctuations in demand. That last point was particularly critical for The Body Coach where massive spikes in traffic would be a frequent occurrence based on time-of-day, whether there was a live workout going on, everyone checking-in at the end of their cycle at the same time, etc. But we needed that scale and flexibility without the cost of running large clusters or having the cluster slow to deal with that sudden (and sometimes unexpected!) demand.
The Serverless Framework is a pretty common tool for packaging and deploying serverless function code to a cloud platform like AWS. It takes care of many of the tricky parts of configuration, leaving you to configure your system in a more abstract way using a YML file.
However, we opted instead to manage our infrastructure using Terraform as we believed that we would quickly outgrow the Serverless Framework.
- We didn’t want to shoehorn our whole architecture into the Serverless Framework YML files. The Serverless Framework can’t support our entire ecosystem and our experience at scale. The framework also has a very brittle implementation that regularly requires rework as your project grows.
- We didn’t want to manage multiple Infrastructure as Code (IaC) tools. This makes for a complicated integration and significantly adds overhead to the developer’s cognitive load.
- We didn’t want to leave resources outside of an IaC tool’s control. This would create a lack of visibility, make it less repeatable, and give us less ability to recover from disaster.
- We didn’t want to have to work around the inherent limitations of the Serverless Framework such as the limit to the number of resources.
We like that Terraform is a more general purpose tool that offers flexibility as we grow our architecture.We like that with Terraform we’d get to control the infrastructure abstractions ourselves by using modules.
As you might imagine, this meant our own team needed to spend time in Terraform to replicate some of the mechanisms that Serverless Framework lets you shortcut. In reality this wasn’t such a mammoth task. In fact, for us this only involved writing a short build script and two small custom Terraform modules — one for managing Lambdas and Lambda Layers and one for connecting Lambdas as AppSync resolvers.
In part 2: We describe the tech side of how ustwo went about helping The Body Coach to expand and develop their business to become digital-first with an award-winning app.
Do you want to be part of ustwo’s tech team? They currently hiring for several job positions, check them out and apply directly here!
0 Comments