Characteristics of flexible, scalable IT infrastructure: a primer on the basic concepts and key evaluation criteria

Microservices make it possible to update and run individual functions

For example, a user management system or a payment processing module can be changed without affecting other parts of the application. To build a working microservice architecture, you need to define module boundaries clearly. When it comes to the quality of microservice boundaries, there are three main concepts:

Coupling is a measure of how interdependent different subroutines or modules are. In other words, it is the way and degree of interdependence between software modules within a particular IT architecture. Coupling can be strong or weak (high coupling and low/loose coupling). Strong coupling means a high dependency between modules, which makes them harder to understand, change, and test.

It is seen as a serious system drawback and is also one of the characteristic traits of monolithic systems. Low coupling is a system state in which changes in one module do not require changes in another. A loosely coupled service knows only the minimum it needs about the services it works with and is responsible only for its own data in the shared context.

A loosely coupled service has three main properties: a small number of dependencies between subsystems (modules), weak dependence of one module on changes in another module, and ease of subsystem reuse.

Cohesion is the degree of interrelatedness of the elements inside a module: how closely the tasks performed by one software module are related to one another. As with coupling, there are two levels of cohesion: strong cohesion is a state in which the responsibilities of the components inside a module are well aligned and the module does not perform an excessive amount of work.

Unlike strong coupling, which refers to the coupling between different modules, strong cohesion within a single module is a positive sign. Low cohesion is when one module performs many unrelated functions or responsibilities. This property leads to the following problems: difficulty understanding it, difficulty reusing it, difficulty maintaining it, unreliability, and constant susceptibility to change. The concepts of coupling and cohesion are closely intertwined.

Coupling describes relationships between objects across module boundaries. Cohesion applies to relationships between functional objects within a module boundary. It is important not to confuse these two concepts. In this article, we focus on coupling as an indicator of flexible IT architecture. The ideal setup is weak coupling between service modules and strong cohesion between components inside a module.

That is, when a module has a small number of external connections and is responsible for solving closely related tasks.

Encapsulation is the hiding of implementation details inside a microservice. Those details are, as it were, placed in a capsule so they cannot be affected from the outside. The idea is to use only the data that is available and not dig inside. In other words, a service should know the minimum context and data about the other service it communicates with, and it should use only what is available by default.

For example, David Parnas, a Canadian computer scientist and one of the founders of the software modularity concept, viewed the links between services as assumptions they make about one another. The fewer such assumptions there are, the easier it is to change one part of a service without affecting another. Reducing the number of connections and the amount of information services have about one another helps speed up development and makes the service more transparent and flexible.

Fast scalability. A loosely coupled system is easy to scale and extend with new services - other systems do not know that you added something to the shared context and continue managing their own backlogs independently. In a tightly coupled or monolithic architecture, developers quickly become overwhelmed by endless integration tweaks, cross-team testing, order exports, and so on.

But something still keeps working incorrectly, and at some point the changes also become economically unviable. For example, in 2001 Amazon faced a similar situation when its monolithic architecture caused major delays in releasing new features and made change management difficult. In the end, moving to microservices improved scalability and development speed, although it required significant investment from Amazon in infrastructure and governance.

Fault tolerance

In a loosely coupled integration, all errors are encapsulated thanks to the small number of links between services. If one flow fails, all the others continue to work as usual. At the same time, the system handles even peak loads without issues.

Simple monitoring and fast incident resolution

In tightly coupled systems, monitoring and incident resolution are handled by a super senior engineer, who is often overloaded, because only they can make sense of the spaghetti connections between services and find the source of an error. In loosely coupled systems, monitoring is straightforward - it can be delegated to support. You can also set up automatic alerts when certain thresholds are exceeded.

High rate of change

Updating any of the services will not affect the operation of the others, and new data flows can be launched quickly. Companies with a loosely coupled architecture roll out new services faster. The faster innovations are introduced, the lower the lost opportunity cost. According to experts, more than 80% of companies worldwide already use microservices to improve their chances of winning the competitive race.

Data freshness in systems

Here we return to the concept of a shared context and the example of a CRM system and an online store within one company. In monolithic systems, every request from one system to another must be translated into its own context. This leads to data errors, losses, and inaccuracies. In loosely coupled environments, this problem does not exist because each system is responsible only for passing its own data into the shared context.

Protection from vendor lock-in

The fact that a specific service has integrations with others does not prevent that service from being replaced or modified. And integration can be delegated not only to the team that develops the external service or to the vendor, but also to any developer or contractor.