Just enough standardization

One of the core reasons to use Microservices is to work on a part of an application with minimal dependency on other teams and deploy it separately. This is because the team won’t be slowed down by other teams in delivering features. It’s very likely each service contains similar functionality but a bit differently implemented in code. If this difference becomes a drag on the speed of deployment then standardization becomes needed. Also the amount of cognitive complexity for implementing cross cutting concerns like logging or identity management is a good reason. This can come in many forms like API rules, architectural patterns, documentation standards or internal shared libraries. So how much standardization is enough?

The other side of standards
The problem with standardization can be that it slows down innovation and create extra dependencies within an organization. Another problem is that it limits the choice in technology for solutions. Standards can be less favorable for delivering new functionality in the best way or the fastest way possible. Standardization decisions also need updates when they are not the best decisions anymore because the scope of the software changed or that the standardization itself became less relevant. Standardization can become less relevant when new technologies become available or when changes in a company occur. For example Docker containers moved the dependencies of an application away from the server OS which made deploying applications with different library or OS requirements much easier, some standards that companies had around operating systems became less important.

Holding on to standards can get a project in real problems. Some years ago I was part of a project that used a lesser known column based database. Mostly because of the costs of managing different kind of databases. Trying to use this database in every project lead eventually to a mismatch. Things that PostgreSQL could offer out of the box, would have to be implemented and shared over the projects. These kinds of standards are born out of realism and efficiency but eventually lead to more costs if not properly updated in a later stage of a project. Although this example is a bit of exaggeration it does show the need for flexibility and that some standards should change.

read more:

https://tech-talk.the-experts.nl/just-enough-standardization-d86984d13585