Serverless: how contract-testing can reduce coupling

When creating serverless architectures, or any large-scale cloud architecture for that matter, it is inevitable that common components and shared infrastructure begin to emerge.

For example, creating a shared logging utility and log aggregation service in the platform can greatly benefit your observability if all teams adopt the standard. It's tempting to create many of these shared libraries and enforce standards amongst teams, however in some cases these standards are better enforced via an external service - for example, publishing a metric for understanding usage and adoption.

Yan Cui has a great read on this topic, which plots some of the tradeoffs of using a shared library vs a running service. This is how it looks in the context of a function (think lamda/FaaS):

The question as to how contract testing impacts the coupling posture of a service came up earlier this year on Twitter and more recently on our Slack channel. It turns out that having contracts between services improve this situation significantly:

Of course, contract testing doesn't come for free, but if you find yourself in a situation where you are debating whether or not to build a service to implement some shared responsibility, you might find that applying contract testing removes a pain point that previously prevented you from doing it!