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 chargers?

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 Javascript application run on multiple browsers about a decade ago? Every 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.

Improved efficiency

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 current infrastructure.

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.

Collaborative standardisation

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 their realm.

Streamlined licensing

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 data strategies.

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 appropriate.

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.

Promoting best practices

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 documentation.

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 somewhere.

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 of standards.