If you work at a large organization, your developers are probably working in four or five different core languages to build the microservices architecture for your product. The team may also be using a variety of frameworks for different use cases. Although such a system is essential to bring the product together, you probably want some form of standardization to keep the complexity in check.
For example, no matter what language you are writing the code in, you might need a Terraform file to generate an S3 bucket or a database for you. Or, you want Kubernetes YAML files to be generated for you, regardless of the framework. In a situation like this today, you are bound to duplicate that code or template between all the different languages. Doing that in a basic setup would mean having to add a Kubernetes YAML file as part of your template in each language. So, you would need to include it in your single JavaScript template as well as your Golang file, for example.
You are not likely to duplicate code in your regular projects, so why would you want to do it for your templates? Templates should be treated as first-class citizens. Some of our clients are adopting an innovative approach to structuring their templates. To avoid the trap of duplication, they are choosing to develop secondary templates in isolation, in addition to the core ones. In this article, we show you how to use Cortex’s Scaffolder to steer clear of duplicating template code by building secondary templates on top of certain base ones.
What are templates?
Although each microservice in your architecture has a unique functionality that it brings to your software, there are a few tasks that are common to several, if not all services. These include, among others, duties such as registration, monitoring, load balancing, and managing limits.
A template is a basic code structure that can be used to replicate some functionalities across microservices such that the same code need not be written multiple times for each service. You can use templates to build basic services instantly before tweaking them according to the purpose they are supposed to serve in the software.
Teams building a polyglot architecture must be careful and build templates specific to each programming language they are using. While sticking to one or two languages may not be feasible for larger projects, keeping the number at a minimum will implement standardization across services and facilitate mobility between them.
How can templates be of use?
Using templates can significantly boost the efficiency of your service creation process. They are relatively easy to set up with Cookiecutter and Cortex’s Scaffolder feature. Before breaking down the step-by-step process of creating microservices with the Scaffolder, let us look at the numerous benefits of using templates when you are building your microservices architecture:
Rapid Creation
Creating a new microservice is an involved process, seeing as you need to account for multiple aspects in the process, such as testing mechanisms and authentication systems. When you intend to build hundreds of such services, all of which have some common requirements, repeating this setup procedure is a waste of time and resources. This is not a major concern in a monolithic environment, for instance, where you need to only set it up one time.
However, the operational needs and mechanisms of a microservices architecture are complex. When done manually, especially, you run the risk of leaving out some details or changing them unintentionally. This scope for errors leads to a level of inconsistency that is detrimental to any objectives of standardized practices across the team or the company.
It is best to avoid these seemingly small risks that have the potential to stall and hamper your project. To this end, templates eliminate the need for repeating the process of manually writing every service from scratch. Written once, you can replicate the same structure for as many services as you wish.
Standardization
Standardization is necessary for a microservices architecture. In addition to the ease with which the team can make sense of each microservice when their common functionalities are in alignment, the services are also more likely to integrate appropriately with each other. By leaving little room for arbitrary decisions and getting rid of them at the beginning of the service creation process, templates work to ensure increased compatibility between services.
Consistency at the more fundamental levels across the services allows you to bring them together and build a working network that forms the basis of your software. The larger network, too, is rid of any unnecessary complexity. Using templates in the beginning stage serves as a starting point from which each service can then be expanded to include the specific functionalities that it aims to contribute to the software.
Efficient Teams
Companies that distribute the work for a particular project across several cross-functional teams often face challenges when it comes to inter-team collaboration. Because each team has considerable autonomy, each is likely to have its own ways of working.
In the context of service creation, these teams are bound to reinvent the wheel every time. It becomes all the more important to leverage the benefits of time efficiency and standardization in this case. A copy of a template does the trick, and with the basic implementations in place, the teams can then independently focus their efforts on fleshing out the particularities of the service. Templates are powerful in this sense, as they can help boost the efficiency of multiple teams in one go.
Streamline the Process
In some cases, teams are already saving the code for their basic functionalities and cloning them when building a new service. Having well-defined templates only formalizes this tendency, helping streamline the process and ensuring that the code is without faults.
Creating microservices with the Scaffolder
The Scaffolder tool introduces consistency into your microservices architecture by helping you build and modify services using templates. To understand how the tool works, let us briefly discuss Cookiecutter, the Python package undergirding it.
Cookiecutter is an open-source command line tool that helps you generate templates for your microservices. It lets you build templates for both your code and the result generated from that. With a relatively flat learning curve, it makes for a suitable tool for companies looking to build microservices against certain standards.
To create a template, you can begin by defining a number of variables or inputs in a cookiecutter.json file. Examples of variables include a project name and description, a repository name, and whether the service is open source. Once defined, you can run the appropriate command in the tool. At this point, the inputs are pulled into the actual template itself and Cookiecutter generates the final templated files for you.
Based on your specific objectives and preferences, you can select the appropriate options when building the templates. This will generate different files or configurations for you to subsequently use. Cookiecutter will then generate a template, i.e., all the code for you. For this reason, Cookiecutter has been the standard in the industry of building such templates. As a result, our Scaffolder uses Cookiecutter underneath the hood.
Some common use cases include creating a microservice, using Java Spring Boot, deploying a Jenkins CI/CD pipeline to a few environments, or choosing, for instance, Postgres over MySQL for your database. In the context of creating a new service, you will be interested in configuring aspects such as monitoring, capability, and the CI/CD pipeline. Or you may want to update a service to deploy to production or QA.
While you have the option to choose from existing templates, you have the freedom and flexibility to define your own templates. You can build any templates you want using Cookiecutter, and then feed them to Cortex’s Scaffolder. If, for example, you want to build a Java Spring Boot microservice, you can create a template that aligns specifically with that framework and add it to the Scaffolder. The tool will then load your cookiecutter.json file and automatically generate a form for your developers to fill out and select the flags they want. Once completed, Cortex will use that information in the template to create a git repository for you.
The Scaffolder also integrates completely with our service catalog to establish an end-to-end flow of creating a microservice. After creating the git repository, the Scaffolder generates the code and pushes it to the repository. Finally, the microservice is added to the service catalog.
Going one step further
There are multiple ways to use the Scaffolder. Traditionally, Cookiecutter is by and large used to create entire projects from scratch, whether it is a microservice or a notebook. However, Cortex goes one step further to help you create services and add to existing ones.
For instance, you have a service that you have been deploying on Heroku for some time. Now, you want to move your entire architecture to Kubernetes. As part of this migration, you will require that everyone create a Kubernetes YAML file that defines their microservice. For the sake of standardization, you might ask that they use the same labels, annotations, and integrations across the organization. Now, you can create a Cookiecutter template that only generates a Kubernetes YAML file and then open a pull request against the existing repository. This will allow everyone involved to use the same template when migrating to Kubernetes. If at this point somebody is setting up a linter, for example, they only need to fill out the Scaffolder form and specify the repository they want to open a pull request against.
As a result, not only can you create entire services and git repositories, but you can also modify and add to existing microservices. This helps you make the most of what Cookiecutter has to offer by extending its capabilities into your microservices architecture.
Building a template structure for your workflows
How can you best utilize these features of the Scaffolder together to set up your templates and get the ball rolling for your teams? One way to go about this is to create a bare bones set of templates for your core frameworks. This can include a Golang microservice template, a Java microservice template, and a Javascript microservice template, for instance. The job of these three templates does not extend beyond providing you with a basic outline for setting up the microservice. By themselves, they cannot offer any specific support for the infrastructure, for instance. These templates are each isolated to their particular frameworks and codebases.
However, you can build a few add-on templates to go on top of these foundational templates. Deploying to QA, for example, or to production, would constitute a separate, level two template. Owing to the distinctness of the two kinds of templates, you can reuse these regardless of which base template you are using. Additionally, depending on your needs, you can stack one template on another in a sequence. You could use a NodeJS template and a production template on top of it, and then an S3 bucket template.
Let us illustrate this process using the Scaffolder. A developer can open it up and click on “Create a new service” to create a JavaScript service. Following this, they choose “Add to an existing service,” where they proceed to select the Kubernetes template, then the one to deploy to production, and finally the QA template. Each of these steps opens pull requests against the initial service they just created.
This allows you to avoid duplicating the same logic across multiple templates. Regardless of which language you are using, you can pick the relevant templates that you want to stack on top of your microservice.
With the need for copies of the same template eliminated, making changes to the templates is no longer cumbersome either. The infrastructure team, for example, can modify or adjust one production template instead of having to go back and update five templates by copy pasting the same changes into those. This method offers an extendable structure for incorporating templates into your service building process by eliminating unnecessary repetition.
Cortex’s Scaffolder harnesses Cookiecutter’s capabilities to make this possible. Designing and organizing your microservices templates in this manner has proven useful to many Cortex users.
Why you should build two layers of templates
The following are a few other benefits of thinking of your templates in terms of two separate layers:
Reusability: Templates are by default reusable, but utilizing them in this manner expands the ways in which you can use and reuse them. Because you are using these in tandem with templates from the other level, there is greater room for experimentation and the process of making changes is simplified.
Easy maintenance: Maintaining these templates is easier as each one has a well-defined purpose and is in line with the single responsibility principle. This keeps the templates simple and ensures that they do what they are supposed to. You also need to maintain fewer templates, as opposed to hoarding multiple copies of every template for each of the services using them.
Distributed ownership: This structure allows for different teams to maintain their own templates. A security team could have a sneak vulnerability scanning template that adds a sneak file. The platform team may be interested in maintaining their own Terraform templates. As a result, ownership is distributed across different teams, adding to the ease of maintenance.
Try it yourself
By displaying relevant metrics and information for all the microservices in your architecture, Cortex’s service catalog gives your team visibility into the services. Without visibility, it becomes nearly impossible to know where the services are lacking and how they can be improved.
Even with the relevant metrics at your disposal, a microservices architecture is significantly more manageable when it has a certain level of consistency. Our Scaffolder tool comes in handy here by helping you capitalize on templates as a way to set up new services in a matter of minutes or to alter them. An underutilized resource, templates streamline these processes and save your teams time and energy that can be directed towards tasks that require their expertise.
To get a deeper understanding of the process yourself, book a demo with us today. Also, subscribe to our blog for more updates on strategies you can employ to elevate your microservices architecture.
