Accelerating Software Development with Chassis Pattern
By
Ailton SilvaView All Posts
Passionate about technology, music and playing guitar. A big fan of New Balance sneakers.
Top Stories
1 - API first - Process for internal services2 - Accelerating Software Development with Chassis Pattern
Overview
In a dynamic environment, with many teams working on hundreds of projects, we must ensure that the services comply with all non-functional requirements for them to be considered ready for production. This base work is usually composed of several repetitive tasks and can take up a significant amount of our team's time.
To address this, we created a framework at FARFETCH that follows the Microservices Chassis Pattern. Our mission was to ensure faster adoption of cross-cutting concerns by providing all infrastructure requirements out of the box, increasing our productivity and effectiveness in our development ecosystem.
In this article, I will walk you through why and how we adopted the Chassis Pattern. And we will finish with some of its engineering tradeoffs and tips for how you might incorporate it into your projects.
Benefits
The main benefits of using a Chassis Pattern include the following:
1) Increased team productivity.
The pattern decreases the time it takes to create and configure a new service with the production-ready requirements. This includes things like authentication, authorization, observability metrics, tracing, logging, health checks, error handling, security features, audit logs and more.
Before we adopted Chassis, implementing all these features took about 15 days (~120 working hours). Now, it just takes a few minutes to install packages, and we have all these features.
2) Increased efficiency when rolling out new cross-cutting features to engineering teams, such as new metrics, security patches, resilience features and more.
3) Improved developer experience through a simplified API.
Over the application lifetime, it can better absorb breaking changes in its underlying libraries, making the team's job easier.
4) Access to an established standard and improved adoption of good practices within the service.
This also has the added benefit of decreasing the team learning curve when changing context between projects.
5) Ensured stability and execution of all unit, integration and performance tests related to Chassis' cross-cutting features.
This way teams don't have to worry about covering these scenarios again. Consequently, service pipelines don't need to run these tests, thus reducing pipeline build/deploy times.
6) The availability of extensions for mocking components such as message brokers, authentication and authorization.
This decreases the effort of creating automated tests for the teams.
How does it work?
Prior to the implementation of Chassis , when a new service was created, each team had to implement and configure the application in order to guarantee the non-functional requirements before going live.
Below, in Figure 1, we illustrate a common project structure before applying the Chassis framework.
Figure 1
You will notice many repetitive requirements. Our solution, as illustrated in Figure 2, creates a layer that groups all these requirements at a single point for wide reuse across our services. It eliminates redundant work from our development teams, giving them more time to focus on implementing business-related features and therefore improving their time-to-market.
Figure 2
Additionally, we created a set of modular extensions to simplify the configuration and the communication between the service and external dependencies such as data stores, messaging, caching, http services, and file/blob storage. These extensions work like plugins. We also made it possible to install only the necessary components, making the framework lightweight and very extensible.
Also, these extensions provide out-of-the-box metrics, tracing, optimizations and resilience settings through a configuration file.
We found it very simple to use in practice, as teams just need to install, set connection settings and implement their business logic.
In Figure 3 below, we identify some of the key features included in the framework.
Figure 3
Templates
With our Chassis Framework in place, we created a template to enable teams to create a new service through a web interface or a command line. By selecting parameters in the template, teams could identify the technologies they need to use in their service (e.g., Databases, Messaging, Caching, HTTP Services). The template also includes pipeline scripts, dockerfiles, and additionally unit, integration and performance testing boilerplates.
With the use of templates and the Chassis Framework, we can now create a new fully compliant project just by filling out a simple form or executing a command line, taking an average of one minute or less.
Downsides
Our primary downside was requiring a team to maintain the framework and to give support to the developer teams. While it is not an insignificant cost, it is offset by the reduced cost of duplications at scale.
Also, our Chassis implementation is not language agnostic. Therefore it needs to have a different implementation for each language adopted in the company. Another alternative would be to use the Sidecar Pattern, which is language agnostic and commonly used in a Kubernetes environment.
Conclusion
In a world with constant changes, avoiding waste and having a way to easily provide high-quality solutions presents very interesting challenges.
By providing the Chassis Framework at FARFETCH, we have empowered teams to focus on implementing solutions, executing our business vision, and decreasing our time-to-market within a sustainable ecosystem.
Do your priorities include eliminating waste, standardising implementations, and increasing team productivity? Then the Chassis Pattern could be a useful and scalable solution for your development team.
