How to keep consistency in Polyglot architectures

One challenge that faces organisations that ‘use the right tool for the job’ is they can end up losing out on the benefits of consistency around a lot of the supporting functionality like logging and metrics. In fact, Netflix identifies four different benefits you ‘get for free’ by standardising your technology stack, which are:

• Consistency
• Leverage
• Interoperability
• Quality

Using multiple languages often means multiple implementations of supporting libraries, with different levels of maturity. The end result is people are often scared to adopt new technologies and don’t want other people to either.

Instead of focusing on how everyone should use specific libraries (written in specific languages) for this supporting functionality, I strongly suggest in a polyglot company that you create a list of ‘Technology Platform Requirements’. Then, any implementation that a team comes up with, as long as these requirements are met, then they can use whatever tool works best.

For your benefit, I have created a base list, to give you something to get started with. These are additionally common features needed to take solutions from proof of concept (P.O.C.) to ‘production ready’. They may also be useful for startups, to take into account all the non work, which does not offer strict business value, that has to go into making a product.

Technology Platform Requirements

Any choice of technology should create processes and shared libraries to enable the features below. Their implementation should follow any conventions and guidelines, such as the naming structure of metrics.

Development

• Init Should be able to create a new component on the platform with ease, such as templates, examples or factories for creating boilerplate.
• Debugging Often taken for granted and provided by tools, but need a way to debug in different environments.
• Linting/Styling Linting and style guides need to be able to be enforced across components.
• Static Analysis Static analysis rules need to be consistent across the platform for the technology.
• Documentation Where appropriate, automated documentation should be set up and stored somewhere.

State

• Logging Handles Errors, Warnings, Information messages at different levels, for different types of environment.
• Metrics Storing information about the state of the component in real time. This includes not just component metrics, but server and data store metrics and any other appropriate ones over the 7 network layers.
• Alarms Alerted when something goes wrong.
• Dashboards Being able to see the state of the component. These often rely on the metrics and logs already mentioned.

Component

• Configuration Where is configuration stored and are there libraries to easily access it?
• Third Party Access Components will often want to call third-party services or data stores. Shared wrappers around these services should be created so that they are accessed consistently and any gaps of what is provided out of the box are filled in.
• Security AuthN and AuthZ through the specified convention, which is shared across all technology platforms.
• Data Generation How to generate data used for testing purposes and pre-defined live data, such as lookups.

Environment

• Deployment How in the component, changes to data store schemas and infrastructure deployed to different environments?
• Discoverability The ability to discover that an instance of a component exists, for example, to share out the load via a load balancer.
• Health Checks The ability to check on the health of a component. At a basic level, this needs to define if a component is up or not.
• Clustering How to allow for multiple threads of instances of the same component to run. This might be within the component itself or by spinning off extra instances, such as the lambda swarm technique.
• Scaling Scaling in and out additional instances of a component. Usually based on metrics or alarms or the items to process.
• Keep Alive Needs the ability to restart on failures. This might be within the component itself or through a managing process such as ECS.
• Tear Down The ability to tear down an environment when it is no longer of use.

Please share with all your friends on social media and hit that clap button below to spread the word. Leave a response of your favourite language and why. 👏

If you liked this post, then please follow me and check out some of my other articles.

About

Matthew Bill is a passionate technical leader and agile enthusiast from the UK. He enjoys disrupting the status quo to bring about transformational change and technical excellence. With a strong technical background (Node.js/.NET), he solves complex problems by using innovative solutions and excels in implementing strong DevOps cultures.

He is an active member of the tech community, writing articles, presenting talks, contributing to open source and co-founding the Norwich Node User Group. If you would like him to speak at one of your conferences or write a piece for your publication, then please get in touch.

Find out more about Matthew and his projects at matthewbill.gihthub.io

Thanks for reading!