snippetMinor
How can I ensure consistency between new microservices?
Viewed 0 times
cannewensurebetweenconsistencyhowmicroservices
Problem
My organisation is experiencing an explosion of microservices. We currently have no formalised way of bootstrapping new projects. I'm finding that a team will come to me with a bug in their deployment or build process, and I will spend time on it only to realise I've already resolved it in another project. There's also a lot of inconsistency between projects that I'd like to see standardised.
The changes often involve a single file (e.g. serverless.yml or a Makefile) so a solution involving shared libraries e.g. git submodules doesn't seem viable. Each project will have its own set of configuration that needs to be maintained, e.g. Dockerfiles or serverless.yml, so centralised configuration management solutions for VMs aren't really applicable.
How can I ensure that new microservices conform to organisation standards and include bugfixes/features from existing projects in a way that's easy and intuitive for developers who want to start new projects? What are some best practises around resolving these issues?
The current workflow we have is to ask the person next to you "what project should I clone from to use as a template?" and then delete all the stuff that's not necessary for that project.
The changes often involve a single file (e.g. serverless.yml or a Makefile) so a solution involving shared libraries e.g. git submodules doesn't seem viable. Each project will have its own set of configuration that needs to be maintained, e.g. Dockerfiles or serverless.yml, so centralised configuration management solutions for VMs aren't really applicable.
How can I ensure that new microservices conform to organisation standards and include bugfixes/features from existing projects in a way that's easy and intuitive for developers who want to start new projects? What are some best practises around resolving these issues?
The current workflow we have is to ask the person next to you "what project should I clone from to use as a template?" and then delete all the stuff that's not necessary for that project.
Solution
I'll add an answer of what my solution is so far, but I'm still really interested in hearing how other organisations are solving this problem and the best practices they have.
To resolve the issue of not having a consistent base to create projects for, my idea is to create a repository (repositories?) of boilerplates/templates and use cookiecutter as a tool to scaffold out new microservices. This way, each project is created from a standard base with all the lessons we've learned as an organisation integrated in to it. Any changes we make can be integrated upstream in to the boilerplate repository. I imagine we'll have templates for Nodejs Docker images, Serverless SPAs, Python lambdas, etc.
To resolve the problem of changes made to the templates being propogated downstream to every project, my solution is to implement a process where owners of microservices are made aware of changes to the template and are then responsible for propagating those changes to their microservice.
To resolve the issue of not having a consistent base to create projects for, my idea is to create a repository (repositories?) of boilerplates/templates and use cookiecutter as a tool to scaffold out new microservices. This way, each project is created from a standard base with all the lessons we've learned as an organisation integrated in to it. Any changes we make can be integrated upstream in to the boilerplate repository. I imagine we'll have templates for Nodejs Docker images, Serverless SPAs, Python lambdas, etc.
To resolve the problem of changes made to the templates being propogated downstream to every project, my solution is to implement a process where owners of microservices are made aware of changes to the template and are then responsible for propagating those changes to their microservice.
Context
StackExchange DevOps Q#2320, answer score: 5
Revisions (0)
No revisions yet.