When your organization or team has arrived at some best practices and wants to formalize them such that all future services will adopt these best practices going forward there is a need for a project “archetype”.
This is so common, in fact, that the creators of apache’s maven have created a tool for this: the maven archetype.
Using this tool one can generate boilerplate code, include approved dependencies, and standardize approaches to questions such as cloud providers, data sources, design patterns, environment variables, observability tooling, and so forth.
I did this recently on a project I worked on just before our team started creating the microservices that would live in our cloud provider. I required my teammates to generate their microservice code from this project and whatever needs were not met, we baked back in to the archetype provided it was not a one-off request.
The rest of this post will focus exclusively on some of the Spring Boot/Java patterns that we arrived at.
First off was our cloud provider’s data sources. We use a mix of SQL/NoSQL technologies, asynchronous queues, and observability tools. When migrating to AWS this meant DocumentDB (for MongoDB), RDS (for MySQL), SQS (for asynchronous messaging), ECS (for container orchestration), CloudWatch (for logging), X-Ray (for distributed tracing), and Prometheus (for metrics).
Standardizing our approach to all of these had to be defined in our archetype before we could generate the project.
I think this is a great jump off point that will lead to more writing as it touches on a number of projects I’ve been working on lately.
Until next time!
Leave a Reply