Enforcing standards in a distributed system might impose the risk of
constraining innovation but it can help preserving everyone’s sanity.
The importance of standards
Microservice architectures can quickly evolve into an integration nightmare and
a fractured ecosystem if standards are not taken seriously. Do you remember what
it was like before most manufacturers standardised on USB for the mobile
Do you remember when the following adapter was a thing?
The same can be said about web standards. Have you ever had to make your
competing browser had their own interpretation of how HTML and CSS should be
structured and rendered. Things definitely moved in the right direction over
time thanks to the W3C.
Standard libraries in programming languages are another example, they are
usually preferred due to their intrinsic interoperability, even when some
third-party libraries might offer better features. But what’s the best approach
in modern languages? Some languages tend to start with a very minimal standard
library allowing for competing third-parties to come up with ideas and expect
the community to choose a winner.
The recent rise of reactive programming highlighted similar issues. There are a
lot of libraries out there implementing streams and observables but most of the
languages don’t have an API for it in their standard libraries yet. Developers
end up having to integrate different streaming libraries, this line of work is
not particularly fun or rewarding. Reactive Streams made the first step towards
standardising the API which has now been included in the JDK 9.
The need for standards in microservices
Today, the same pitfalls apply to distributed systems and microservices in
particular. Microservices are usually promoted as a very flexible architecture,
with one of its main selling point being the ability to use the right technology
stack for the problem at hand in a heterogeneous distributed environment. The
reality is that microservice architectures, at least the healthy ones, tend to
be quite restrictive, especially in regards to communication protocols.
Moreover, communication between microservices is only the first piece of the
puzzle. Your distributed system will most likely need to have a shared core
infrastructure, distributed logging and tracing, solid continuous integration
and deployment pipelines, a monitoring dashboard showing the overall health
state of the system and established ways of managing security concerns.
Implementing all of these components for different technology stacks is usually
not feasible in the long run.
Allowing the teams to share and contribute to a core platform can help reducing
friction when the need of new services or features come up. This can increase
efficiency and help a growing team maintaining and sharing knowledge about the
Standard protocols and well-known ways of communicating between services help
giving developers some solid ground they can rely on. They can worry about
solving actual problems rather than wasting time building and testing different
integration points. This is usually a welcome standardisation due to the fact
that most developers don’t really enjoy integration-related work.
Everything that can be standardised should be standardised
Standards in microservices will also help to give some guidelines on what is
expected from new services as well, due to the fact that a few badly written
services can have a big impact on the overall system integrity. Creating a new
service is rather easy, but making it fit nicely within the overall distributed
system can be hard if there isn’t a set of principles guiding the teams.
Standardisation promotes knowledge sharing and builds a common skill set that
can ease the process of shifting developers between different areas of the
organisation. It also helps to maximise return on investment by avoiding
reinventing wheels all the time and by reducing the risk of fixing the same
issues over and over again in different contexts.
It can help promoting collaboration between teams, which can rely on each
other’s expertise to improve the overall system. It also allows developers to
have a bigger impact on the organisation when necessary, rather than only within
Having a standard set of tools also helps to streamline how licenses for
third-party services are managed and reduces the infrastructure costs year after
year. If there is a standard cloud platform, a standard product to manage
logging and monitoring, keeping track of the necessary licenses and costs is
usually straightforward. On the other hand, if every team uses different tools
it can cause real pain for whoever is responsible for managing those licenses.
This also facilitates how new hires are on-boarded. A new developer joining the
team won’t need access to a variety of different tools depending on the
circumstances. The same advantages apply to leavers as well. How many time in
your organisation have people found out an ex-colleague still had access to some
of the internal infrastructure after months from his departure?
Security and regulatory compliance
Standards and common principles can have a very profound impact on how security
is managed and verified. A more diverse system will open up the infrastructure
to a higher number of attack vectors, and different teams will have a different
level of expertise in regards to security.
Standard ways of managing data will mitigate the risk of violating compliance
with policies as well. It can be a tough challenge trying to keep track of how
sensitive information is handled in different services if they use different
Avoiding premature standardisation
It’s worth understanding that premature standardisation can cause big troubles.
If it’s the first time you are adding a vital piece of infrastructure, don’t set
it in stone until you are sure it can actually be a worthy candidate for a
standard. The approach can be applied to your cloud provider, your message
broker, your protocols, your log formats and everything else you deem
Standards can be dangerous. When any potential issue is found in the current
enforced standard, it will impact everything relying on it. Avoiding premature
standardisation might help to reduce such risks.
Allowing local standards
Allow a constant feedback process from the wider team in order to keep the
platform and its standards open to improvements. It’s always good to keep in
mind that even though some fixed standards can work for most uses cases there
are always exceptions.
Some standards might constrain innovation and the ability to build optimal
solutions to particular problems. Developers will get frustrated if they are
forced to use tools that don’t fit their use case. They should be allowed to act
in the best interest of their product. Of course, a cost-benefit analysis is in
order to help to make the right decision.
Making sure the supported standards are well known and understood by the tech
teams is critical. In addition, the teams using different standards should be
aware that they will need to be the ones responsible for supporting their
exceptional use cases in production.
Standards can be continuously improved and can influence best practices.
Principles can be promoted and taught to new developers joining the teams
without welcoming them into a world of unknowns, diversity and despair.
Junior developers will also feel less overwhelmed knowing they won’t be expected
to know how to set up or understand all the necessary infrastructure in order to
build and deploy a new service to production.
Documenting your standards
Supported platform components can benefit from a higher organisational focus and
can drive not only their continuous improvement but also more detailed
Developers don’t generally waste much time writing documentation for things used
only by a few people. On the other hand, comprehensive documentation about
common platform components can help. Newcomers might not know what is available
on the current platform or how these components work unless they are documented
Are we there yet?
When done right, microservices can be a great way to scale up a development
team. If you are experiencing some of the issues outlined above try to start
analysing which components in your architecture are redundant.
Don’t ignore the valuable lessons learned from the painful consequences of lack