Technical Sprawl & Standardisation
Overview
The adoption of microservice architecture resolves the most pressing challenges presented by monolithic application architecture. Microservices aren’t plagued by the same scalability challenges, the lack of efficiency, or the difficulties in adopting new technologies: they are optimised for scalability, optimised for efficiency, optimised for developer velocity. However we quickly run into issues with technical sprawl. Technical sprawl is unavoidable in microservice architecture but I will cover some common pitfalls and what we can do to rectify them.
Firstly, developers tend to have their own set of tools, libraries and ultimately language. If we add on different ways of building and deploying, different ways of monitoring and alerting, favoured external libraries (NPM compounds this issue) and custom scripts we soon have a multitude of ways to do one thing. The only way to cut down on technical sprawl is through standardisation at every level of the microservice ecosystem.
Another kind of technical sprawl is associated to language choice. Luckily we have chosen to write our microservices in Typescript, but if this were not the case and we had multiple languages we only add to the first pitfall of developer workflow on top of this issue we would very quickly spiral out of control.
The last type of technical sprawl is technical debt. Technical debt usually comes from implementing something sub optimal code to release faster. Given that we are able to churn out features at a fast pace, technical debt will build up in the background.
Availability: The Goal of Standardisation
Within microservice ecosystems, service-level agreements (SLAs) regarding the availability of a service are the most commonly used methods of measuring a service’s success: if a service is highly available then we can say with reasonable confidence that the service is highly available. Please see calculating availability to understand the nines notation.
Availability is not in itself a principle of microservice standardisation, but the goal.
Standardisation needs to be embraced and implemented. It needs to be seen as a guide for production-ready development and deployment.
Developer velocity and productivity grind to a halt whenever an outage brings a service down, and if they do not follow the same paradigm we decrease availability whilst deciphering code.
So far we have standardised our monorepo approach, provided internal serverless templates for both JS and TS and written our coding standards for the wider team to use. These are of course ever evolving pieces of work that require input from all team members.