Created by: Ron Karroll and David Horstman

Last updated: March 29, 2022

When I first started at Clipboard Health a few months ago, I was eager to hit the ground running. I asked our Head of Engineering Mike Cook to recommend a good infrastructure task to get my feet wet. I expected he’d suggest something on the scale of updating the linter. As my colleagues noted later, our company has high expectations even for its new hires, and when you ask to be “put to work”, you’d better be ready to tackle a real challenge.

The problem posed to me was to develop a system for rapidly scaffolding and deploying new microservices to help our business scale. Our customer base and engineering team both are and were growing rapidly, and our legacy monolithic application was starting to show some cracks.

The fact that we couldn’t independently scale different parts of our application meant we had to choose between placing a high load on our most in-demand services like payment processing or spinning up more instances of our entire application, all just to keep up with the demand for one service. Since the amount of effort required to onboard a new engineer grows with the size of our codebase, this was also beginning to strain our finite training resources.

With the goal of alleviating those concerns in mind, I set out to design a tool to make it so easy to build new features in separate microservices that no engineer would be so much as tempted to add to the complexity of the existing monolith.

Objectives

We had already started migrating to a microservices architecture before I joined the company, but the process was slow. It would typically take several days for an engineer to create a new repository, initialize it with application code, set up a deployment pipeline, and finally make whatever new idea they were testing available to our product team.

Mike believed that the speed of this process was the main obstacle standing in the way of broad microservice adoption. We set reducing this “time-to-launch” from ~3 days to less than 20 minutes as our first objective.

Our other main objective was to uphold high standards while giving everyone access to industry-standard libraries and frameworks. We decided to pamper our engineers by including all the best tooling in every new microservice we create:

• Typescript accelerates development by enabling editor suggestions and catching type errors at compile-time
• NestJS encourages modularity and provides unparalleled stability and consistency at runtime
• Prisma exposes a declarative interface for defining database schemas and a strongly-typed bridge between SQL and Typescript
• eslint/prettier/cspell ensure all code is linted, formatted, and spell-checked using a consistent ruleset across our organization
• Terraform allows us to define and provision new server resources without leaving the repository
• GitHub actions automates our entire CI/CD pipeline from commit to deployment, removing the need for any manual intervention beyond opening pull requests

Having determined our speed goals and ideal architecture, all that remained was to build the tool!

Introducing First Stage