Moving away from Monolithic Deployments
This week, I listened to an episode of the Starling Bank Developer Podcast in which Starling engineers discussed the deployment of the bank's applications. Starling was transitioning from a distributed monolith design to deploying the bank as a collection of functional groups at the time (April 2020).
In the distributed monolith model, each version is deployed as one single entity. At the time, the bank was made up of 30 services which for each release were all bundled together and released as one. This model was chosen when the bank was young for its simplicity- every contributor can look at the application as a whole, and fairly easily ensure that each part of the application will integrate correctly with every other part for any given release.
Deploying as a set of individual engineering groups means that the application is split up into functional groups, which can each be upgraded onto new versions independently from the others.
Functional groups should be chosen carefully since the integrations between groups are put at risk when groups versions are upgraded at different times. At Starling, examples of groups included "Core Banking", "Customer Service", and "Public API". Groups were going to interact using API gateways to 'hide' implementations from the software accessing the data. Integrating software in this way forms simple contracts between systems, which can be tested using a contract testing tool such as pact.io.
In other words, at a release time for a given functional area developers can have confidence that their components are compatible with every other component they need to interact with because there are tested contracts in place.
Maintaining each functional area's confidence in releasing working versions is one challenge Starling's leadership identified in making this change to their deployment. Choosing functional groups carefully, and implementing testable contracts are two ways of maintaining this confidence.
A second challenge Starling's leadership identified was ensuring that the culture of teamwork they formed under the monolith model is preserved. Separate release cycles in each group could limit interaction and collaboration between groups. I can't think of any obvious solutions to this, other than traditional teambuilding techniques such as job rotation or internal hackathons.
In summary, the transition from the monolith model to deploying as individual engineering groups is a common event in companies as they grow from small development teams providing few services, to larger development teams providing many services. The main risk in this transition is the robustness of the integrations between groups respective pieces of code, and contract testing could be an efficient way to do that.