The properties of a flexible and scalable IT infrastructure: an educational program on basic concepts and the main evaluation criteria

The method and logic of interaction between elements within the IT infrastructure gives it certain properties. For example, scalability and flexibility, or vice versa — sluggishness and vulnerability to errors. Understanding these properties and correlations is key to correctly choosing specific approaches and tools for integrations.

Otherwise, the company runs the risk of becoming a hostage to a tool—for example, implementing an ESB layer to simplify integrations, but still failing to overcome the limitations of the good old monolith.

Therefore, in this article, we will discuss the theoretical basis: the concepts of connectivity, module connectivity and encapsulation. We will also propose specific criteria for assessing the flexibility of the IT infrastructure and a stress test for testing your circuit for a monolith.

Connectivity, connectivity and encapsulation in microservice architecture

Microservices allow individual functions to be updated and run. For example, a user management system or a payment processing module without affecting other parts of the application.

To build a working microservice architecture, it is necessary to clearly define the boundaries of the modules. In the context of the quality of microservices boundaries, there are three main concepts:

1. Coupling — a measure of how interdependent different subprogrammes or modules are. In other words, the method and degree of interdependence between software modules within a single IT architecture.

Connectivity can be strong (high coupling) and weak (low/loose coupling).

Strong connectivity (high coupling) means a high dependence between modules, which makes them more difficult to understand, modify and test. It is perceived as a serious flaw in the system, and is also one of the characteristic properties of monolithic systems.

Low coupling — the state of the system when changes in one module do not require changes in another. A poorly connected service has the necessary minimum of information about the services it has to work with and is only responsible for its own data in the general context. A loosely connected service has three main features:

• A small number of dependencies between subsystems (modules)
• One module is poorly dependent on changes in another module.
• Easy reuse of subsystems.

‍

2. Cohesion — the degree of interconnectedness of elements within the module: how the tasks performed by one software module are related to each other.

As with connectivity, there are two levels of connectivity:

Strong connectivity (high cohesion) — a condition where the responsibilities of components within one module are well coordinated with each other and it does not perform huge amounts of work. In contrast to strong connectivity (where different modules are connected), strong connectivity within one module is a positive sign.

Poor connectivity (low cohesion) — a condition when one module performs many heterogeneous functions or unrelated duties. This module property leads to the following problems:

• Difficulty understanding
• Difficulty in reuse
• The complexity of support
• Unreliability, constant susceptibility to change

The concepts of connectivity and connectivity are closely intertwined. Connectivity represents relationships between objects across module boundaries. Connectivity, on the other hand, applies to relationships between functional objects within the module boundaries. It is important not to confuse these two concepts. In this article, we focus on the connectivity category as an indicator of flexible IT architecture.

The ideal option is to combine weak connectivity between service modules and strong connectivity between components within the module. That is, when the module has a small number of external connections and is responsible for solving problems that are similar in meaning.

‍

3. Encapsulation is about hiding implementation details within a microservice. These parts are, as it were, placed in a capsule so that they cannot be damaged from the outside. The idea is to use only the data that is available and not go inside.

That is, the service must know a minimum of context and data about the other service it is communicating with. And he should only use what is available by default.

For example, David Parnas, a Canadian computer scientist and one of the creators of the concept of software modularity, saw connections between services as assumptions they make about each other. The fewer such assumptions, the easier it is to change one part of the service without affecting the other. Reducing the number of connections and service information from each other makes it possible to speed up development, make the service more transparent and flexible.

What does all this mean in practice and what does the overall context have to do with it?

Before moving from complex theory to practice, let us introduce context category.

There are two contexts in software development: the application context and the enterprise context. Service-oriented architecture, microservice architecture, and monolithic architecture are built around context.

For example, orders in the context of a CRM system and an online store (e-shop) are different things. The order attributes in the CRM system and the online store are different:

For the enterprise context, it is important to know only a limited set of parameters about an order, such as ID, customer, and amount. The enterprise context does not need all other CRM system attributes.

To explain the difference between strong and weak connectivity in practice, let's consider two options for exchanging information between CRM and an online store.

1. In order to share data, CRM and an online store must understand each other. The process begins by sending an order from an online store to a broker, and then another system takes the data and translates it into its own internal language. But to do this, another system needs to know the context of the first one — this is a strong connection or a monolith. The contexts are mixed, which complicates integration, resulting in a point-to-point approach.
2. What principles would be used to communicate between services in the event of poor connectivity? Each system would “think” that it is alone in the enterprise and would be responsible only for what it conveys into the enterprise context. Service buses (ESB) are a tool for implementing integrations in a loosely coupled architecture

The main features of a loosely connected architecture

1. Fast scalability.

‍It is easy to scale a loosely connected system and add new services — other systems don't know that you've added something to the overall context and continue to manage your backlog on their own.

In a highly connected or monolithic architecture, there quickly comes a time when developers find themselves overwhelmed with endless integration improvements, cross-team testing, order uploads, etc. But still, something keeps going wrong, and at some point the changes become also economically unprofitable.

For example, Amazon faced a similar situation in 2001→, when their monolithic architecture caused large delays in releasing new features and difficulties in managing changes. As a result, the transition to microservices improved scalability and development speed, although it required Amazon to invest heavily in infrastructure and management.

2. Resiliency.

‍There are all errors in a loosely connected integration encapsulated due to the small number of connections between services. If one stream fails, all the others continue to work as usual. At the same time, the system can easily cope with even peak loads.

3. Easy monitoring and high speed of incident resolution.

‍In highly connected systems, incidents are monitored and resolved by a super signor, often overloaded, as only he can figure it out spaghetti connections→ between services and find the source of the error.

In loosely connected systems, monitoring is simple — it can be delegated to technical support. You can also set up automatic alerts to exceed some parameters.

4. High speed of change.

‍Upgrading any of the services will not affect the work of everyone else in any way, and new data streams can be launched quickly. Companies with loosely connected architectures are deploying new services more quickly. The faster innovations are introduced, the less profit is lost. According to experts, more than 80% of companies in the world are already using microservices→to improve your chances of winning a competitive race.

5. The relevance of data in systems.

‍Here we return to the concept of general context and the example of a CRM system and an online store within the same enterprise. 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. There is no such problem in loosely connected circuits, because each system is only responsible for transferring its data into the overall context.

6. Vendorlock protection (vendor binding).

The presence of integrations between a particular service and some others is not an obstacle to replacing or refining a particular service. And integration can be delegated not only to the external service development team or vendor, but also to any developer and contractor.