Microservice pattern: why do you need it and how to implement it in development processes

Many developers use patterns and templates in some form or another, usually copying code from old projects to save times. From our experience, we can pinpoint several disadvantages right off the bat:

1. You might pick not a good microservice to copy; elements may be missing, settings could be incorrect, etc.

2. If developers do not have a reference, the risk of additional errors increases. This means that someone will have to spend extra time fixing them.

3. There is always a risk of missing important elements, an absent pipeline, using an old version of the library, specifying incorrect authorization, or logging settings.

In general, if an operation is being repeated time after time, it is already worth automating it. But saving time is not the main advantage of implementing a template.

What a microservice template can give you

A microservice template is one of the building blocks of a software product, a design element that can be reused from project to project.

With it, you provide teams with a common technological base – everyone works by the same pattern which, by default, includes all the elements needed in the project (we will tell you more about the composition of the template below). Developers do not have to keep copying the code or check it over and over.

And from the business’s point of view, this is an opportunity to manage your resources better so that the development pipeline moves faster and more smoothly:

• Using templates gives developers consistent quality with less resource input. It is sufficient to spend some time selecting the necessary elements once, and right after that all developers will have ready-made tools to-hand.
• The less time spent on unnecessary actions, the more the time-to-market is lessened. Releases are delivered more frequently, and the product is developed muchfaster.
• The template helps you meet the Production-Ready standards. This includes not only the architectural elements that should be contained in every product, but also other important things like tools for working with metrics, Feature Flags, and basic tests.
• The option to extend the best experience to all teams at once helps improve the quality of their work. You get rid of the influence of "subjective" factors, e.g. one developer codes this way, while another does so that way, with a third one only having recently joined the company and has not yet figured out which libraries to use etc. Templates remove confusion and simplify the review.
• You get the ability to quickly and centrally update a set of libraries, configure pipelines, roll policies to repositories, etc. The colleagues researched the new technology, spoke about it at the meet-up, everyone appreciated it – and, in the shortest possible time, it quickly appears in everyone's working tools.
• Development of microservice architecture: the easier it is to create microservices, the more developers use them. Teams no longer spends extra resources on building a microservice skeleton, and whether one microservice should be made or the logic broken into five is practically irrelevant. Therefore, the pattern is the development driver of a real microservice architecture.

What is fixed in the template

Image

1. The folder structure and the basic classes needed for any microservice
2. Settings for Rest API, databases, authorization, and message brokers
3. Correct versions of the base libraries
4. Our internal developments and settings

• The libraries of our own development
• Assembly and delivery pipelines (CI/CD)
• Something we call “observability”: logging, tracing, and health check monitoring

5. In addition to the code itself, we standardize the entire ecosystem for our future microservice: we configure the Git repository policies, and Jenkins/Gitlab pipelines.

How our microservice template looks for .Net

Our basic microservice is an extension of Microsoft Visual Studio and combines five components:

• The Web API Project is a back-service that responds to HTTP requests.
• The database project is the database of the micro service.
• The HTTP Service client project allows you to call methods in the backup service
• The MassTransit consumers project enables the receipt of messages from RabbitMQ.
• Job Project is used to perform any actions on a schedule.

Modules can be added to the project altogether simultaneously or separately. The choice is made on the basis of a simple UI, where it is enough to tick the necessary components:

The finished template is placed in the Visual Studio marketplace or other repository, which allows its contents to be updated automatically.

Results

We have already tried out this practice on one of our projects, and realized that this method of using templates is both convenient and scalable. The effect is obvious: instead of copying and checking code from old projects for several hours, developers get a ready-to-use solution in just a few minutes. You can immediately get down to business: write business logic, build integrations, etc.

What's next? – We will spread this experience to other teams. We want to preserve the integrity of the template as much as possible while at the same time making it universal for use in different projects. We will create templates for all platforms. This way we ensure a unified level of quality and a single set of best practices, regardless of the conditions in each particular case.