The architecture of distributed systems  —  Microservices and their challenges

The construction of distributed systems in the microservices architecture solves problems with accessibility and scalability, while also increasing flexibility and shortening the time-to-market of new functionalities, which is an important part of software development projects.

However, the complexity of such systems requires solid knowledge of how to deal with challenges like distributed transactions, load balancing, state storage, monitoring, communication between services, and security. As a result, programmers have to spend some of their time making decisions pertaining to the selection of tools and patterns and solving problems, none of which are directly related to the implementation of business logic.

Dapr — the construction of platform-independent distributed systems from building blocks

In response to these challenges, in October 2019, Microsoft launched the Dapr (Distributed Application Runtime) open source project on the GitHub platform (https://github.com/dapr), releasing the first stable version of the project for production use in February 2021. In accordance with the motto “Any language, any framework, run anywhere”, the key feature of Dapr is its independence from the programming language and the environment in which microservices are run.

It is a set of good practices (design patterns) implemented in the form of independent building blocks made available using the sidecar pattern. Developers often ask “Is Dapr a Service Mesh?” Whereas Service Mesh tools such as Istio, Linkerd or OSM facilitate communication between microservices using a sidecar proxy, DAPR’s task is to support developers building distributed applications.

Read also: Microservices architecture explained. Is it still a revolution or already standard in IT projects?

The sidecar pattern

The sidecar pattern is a single-node pattern consisting of two containers: the application (containing the business logic) and the sidecar. The role of the sidecar container is to extend (provide new functionality) and improve the application container. The advantage of using this pattern is its modularity and the ability to reuse components used as sidecars. It also facilitates integration with older solutions without having to interfere with their code.

The container or process of Dapr sidecars (Dapr is not dependent on Kubernetes and can be run independently even on edge devices) provides the container/application process with a universal API for individual building blocks. Communication takes place via HTTP/gRPC protocols, so the use of building blocks does not require any dependencies to Dapr to be placed in the application code, and integration takes place when the code is run, not compiled. Additionally, to make the process more intuitive, Dapr makes SDK available for languages such as:

• Go
• Java
• JavaScript
• Python
• .NET
• PHP
• C++

This approach also allows applications to take advantage of solutions/patterns not available in the language in which they were written. For example, an application written in PHP can draw upon the actor pattern (a pattern used for multi-threaded applications).

Building blocks — key components

Building blocks are the framework for the distributed systems created thereon, encapsulating the functionalities of the infrastructure. Each block consists of a public API and components that implement its functionality. These components can be replaced without having to change the API provided, which constitutes an extra layer of abstraction. This approach separates the application and makes it independent of solutions from various vendors, enabling migration without the need to interfere with the code.

Use case: migrating from Mongo DB to Redis

Our application state management app uses a no-SQL database — the MongoDB solution, referencing it directly in the code through the SDK. For reasons of best performance, we decided to migrate to Redis. As a result, we need to change the SDK and application code, which is specific to MongoDB, to adapt it to Redis. If we were to use the state management building block from Dapr from the beginning, such a change would be limited to correcting the component type in the YAML configuration file.

Dapr consists of 7 building blocks; however, adding more is not a problem due to its inherent openness. Let’s take a look at the individual blocks in the context of their responsibilities.

Service-to-service invocation

It allows direct communication between services, ensuring:

• reliability — automatic attempts to resend messages in case of errors, e.g., network errors
• mutual authentication (mTLS) and encryption
• access control (ACL)
• load balancing — the Round Robin algorithm
• automatic service discovery — uses Kubernetes DNS or mDNS depending on the environment.

State management

It allows you to manage the state of services/actors, ensuring:

• datastores in the form of plug-ins — you can connect one of the many solutions available on the market, like Redis, MongoDB, MySQL, etc.
• optimistic concurrency control using Etag headers
• data integrity — supports strong and eventual consistency
• bulk operations

Publish and subscribe

Implements the Publish/Subscribe pattern, ensuring:

• integration with solutions like Redis Streams, Azure Service Bus, AWS SNS/SQS, etc.
• sent messages formatted in accordance with the CloudEvents specification
• message delivery guarantee (at least once)
• message lifetime control (Time-To-Live)
• topic-based grouping of messages, enabling control of senders and recipients
• grouping message recipients — implements the pattern of competing recipients

Resource bindings

This enables two-way integration with external sources (systems/components) in isolation from a specific implementation. Binding events to specific actions takes place at the level of YAML configuration files. For example, in response to user registration events, we call up an external SendGrid service to send a confirmation e-mail. Changing the service provider for sending e-mails will not involve changes to the application code — changing the configuration is sufficient, and the application operator can do so without getting software developers involved.

Actors

It implements the actor model, which simplifies the construction of highly available and reliable systems without the need for complex concurrency and scaling patterns. In this model, the actor is the basic concurrent processing unit. The actors are completely hermetic and communicate with the outside world only via messages.

Characteristics of an actor:

• manages their own state (actors do not share states)
• receives messages from other actors and processes them sequentially (one actor = one thread)
• communicates asynchronously with other actors

Similarly to the Microsoft Orleans framework, Dapr utilizes the concept of a virtual actor, whereby the management of the actor’s life cycle takes place automatically.

Observability

Provides a structured approach for using:

• metrics — we can use, e.g., Grafana to monitor them
• logs — browsing can be done by means of, e.g., FluentD or Elasticsearch and Kibana
• distributed tracing — compliant with W3C Trace Context standards, which ensures integration with solutions such as ZIPKIN, Jaeger, and Application Insights

Secrets

Provides secure storage of sensitive configuration data, i.e., passwords and keys, integrated with solutions such as Azure Key Vault, HashiCorp Vault, Kubernetes Secrets, etc.

Summary

The COVID-19 pandemic and the related changes and business challenges have dramatically accelerated the pace of moving infrastructure to the cloud and contributed to the growing popularity of multicloud and hybrid environments. The requirement for high application scalability has forced the “breaking” of monoliths and transformation to the microservices architecture.

This poses a serious technological and staffing challenge for companies (due to the limited availability of specialists in a given field). Solutions such as Dapr (https://dapr.io) and Open Application Model (https://oam.dev) and the concepts on which they are based, providing a set of best practices and streamlining the migration process, can significantly shorten this path and smooth it out as well.

DATA ANALYTICS SERVICES Use data to your advantage Discover our Data Management End-to-End offer! Find out more!

Ports and adapters, aka hexagonal architecture

Ports and adapters architecture, also known as hexagonal architecture, is a pattern that imposes the way an application’s code is built and organized. The main assumption of this pattern is to create code in such a way as to maximally separate the implementation of business logic from any external dependencies, such as frameworks, databases, external services, etc. As a result, we gain greater control over the code and independence from external libraries and the changes made to them. Let’s take a closer look at the pattern:

Also read: Microservices architecture pattern

Ports and adapters pattern

The pattern of ports and adapters divides the code structure into two areas:

• internal (application / domain)
• external (infrastructure)

The internal area focuses on the solution and implementation of the main problem (use case). This area does not make any reference to or draw from frameworks, databases, and other services or external libraries. The external area, in turn, includes the implementation of ports in the form of adapters and classes related to frameworks, such as Spring, Hibernate, etc. Communication between the internal and external areas is via ports and their implementation, that is, adapters (hence the name of the pattern).

Some basic assumptions of hexagonal architecture:

1. The internal area, that is, the proper implementation of logic, “does not know anything” about the external area. There is no relationship between this area and frameworks (like Spring, Hibernate, etc.).
2. The problem solving logic is closed in the internal area. We have access to it only through the class of the domain facade.

Implementation of this type of software architecture

The main goal of the example is to present the implementation of classes and package organization based on the concept of ports & adapters architecture. An example is the domain area responsible for registering new users in the system. Two use cases have been implemented here:

• Registration of a new user – includes functionalities related to generating an account activation code and sending an activation e-mail.
• Activation of the user account – verifies the generated code, activates the account and sends a message to the external system.

Packages

1. Package: user

This is the main package of the domain within which we will operate – namely user domains. This package contains two subpackages: crud and registration.

2. Package: user.crud

This package holds the logic associated with simple data retrieval operations.

It can also include other operations that do not have complex business logic and only serve simple operations such as CRUD (create, read, update and delete).

3. °Package:°user. Registration°° user.registration°Package:°user. Registration°° user.registration

This package contains all classes related to the logic of registering new users in the application (implementation and handling of the aforementioned use cases).

4. Package: user.registration.domain

The package contains classes with the main implementation of business logic and ports’ definitions (Java interfaces) through which communication with other system components takes place. The core.user.registration.domain package contains the vanilla Java code, or code that is not dependent on frameworks and other external libraries. The only access point to the implemented logic in this package is the façade class. Bear in mind: the choice of libraries to use (e.g. commons-lang, Dozer, Orika) inside the package is up to the team and depends on the general arrangements in the project.

5. Package: user.registration.infrastructure

This package includes the implementation of adapters that are used through the ports defined in the code. The package includes the implementation and configuration of components using the functions and methods of the frameworks. Libraries of other solution providers are often used here. These are responsible, for example, for generating PDF files, sending e-mails or communicating with external systems, such as Kafka, SOAP, etc.

6. Package: user.registration.infrastructure

This package should include a configuration related to creating and operating framework components.

7. Package: user.registration.infrastructure

This package includes controller classes and DTO classes, through which other systems or modules can use the functions of our domain. The DTO classes describe the input and output structures for the REST API.

8. Package: user.registration.infrastructure

A package of classes related to the persistence layer, meaning classes responsible for retrieving and saving data in the database. These are the definitions of the data model (ORM), the DAO classes. This package includes, among other things, the implementation of the data access adapter class. In more complex cases, we may have more model classes or refer to model classes (ORM) of other packages.

Hexagonal architectural pattern – description of an implementation of classes

1. Classes from user.registration.domain:

• UserRegistration – the main class of implementation of business logic. Access to the class is limited at the package level.
• UserRegistrationDataProvider – port for I/ O operations related to database access.
• UserRegistrationNotifier – the output port for sending messages to the queue.
• ConfirmationMailSender – the output port for sending e-mail message.

The abovementioned ports are public interfaces of Java classes, the implementation of which is done at the level of infrastructure packages.

UserRegistrationFacade – domain facade. The class through which we can access methods (functions) of the domain. In the illustrated example, the facade class performs the calling function for the UserRegistration class – it acts as the wrapper function. In more complex cases, we may have more classes containing business logic. Then the facade is the access point to the calls of all these domain functions. Sometimes we may need to add some framework-related validations at this stage. This may be due to the fact that some other domain areas will need to use logic from another domain. The validation function can then be used at the facade level. Of course, as in the aforementioned cases, everything depends on the general arrangements and project assumptions in the team.

2. Classes from the user.registration.infrastructure package

Implementation of adapters:

• ConfirmationMailSenderAdapter
• UserRegistrationNotifierAdapter
• UserRegistrationDataProviderAdapte

3. The UserRegistrationService class is responsible for the transactionality of operations. This class calls the business logic code through the UserRegistrationFacade. For more complex operations at the level of this class, facades from other areas can be injected.

4. Classes from the user.registration.entrypoint package.

5. The UserRegistrationController class issues a REST API. It uses the UserRegistrationService class to execute transactions. In the event that operations do not require transactions, we can directly use the facade class here.

In the example implementation of the domain package, you can see many classes – this is one of the attributes of this pattern. Thanks to this, we gain the hermeticity of implementing business logic and structures that are related to it. The access point to the domain function is the facade class. By default, domain classes should not use framework classes, and therefore a larger number of data-related POJO (plain old Java object) classes. In the case of complex use cases, you can create more classes with business logic implementation; for example, you can separate account activation into a separate class

Ports and adapters – FAQ

Ports and adapters design pattern – summary

I hope that I have been able to present the main ideas of coding in the hexagonal architecture, and answer some of the questions that may arise during implementation. Of course, everything may differ depending on the project.

It is entirely up to you. The team creates the software, so organization and code structure should be readable for everyone and make work more convenient. In fact, how the pattern will be implemented depends on the team and their decision.

A consistent approach to software design is key

When starting a new project, software engineers usually want to complete their first task very quickly, overlooking the importance of preparing the design. This is a mistake! After all, it is the initial stage of new application development that is the most important. It allows you to work out a consistent, fixed approach that will be used by other programmers involved in the project.

Architecture versus technology debt

Another mistake that developers often make is causing technological debt. It is true that we often create something quickly, which seems to make sense…

However, due to various factors, we incur more and more technological debt. When working on projects, taking shortcuts doesn’t pay. Haste and negligence are the most common reasons for technological debt!

It is not so bad if we cause a debt that we can later “pay off”, that is, make corrections on time. It is worse if it leads to debt that exceeds our skills or goes beyond the project timeframe. Unpayable technological debt can lead to something we are all familiar with. This is perfectly illustrated by the image below:

Clean Architecture – Technological debt based on the example of Poland’s public debt

To avoid this problem, it is worth using some of the many patterns available for architectural design. My favorite approach, one which I use most often, is Clean Architecture.

What is a Clean Architecture solution?

Clean Architecture is an approach to application programming that involves separating the four main functional modules in a project.

These modules are:

• Application,
• Presentation, 
• Domain, 
• Data.

I will discuss each of them in detail. To start with, a few words about the main concept of the Clean Architecture approach.

Principles of Clean Architecture 

In his book “Clean Architecture”, Robert C. Martin (“Uncle Bob”) defines the purpose of architecture as supporting the life cycle of a system. As he says:

“Good architecture makes a system easy to understand, easy to develop, easy to maintain and easy to implement. The ultimate goal is to minimize system lifecycle costs and maximize developer productivity.” 

While creating the Clean Architecture approach, Martin aimed to work out a project structure with clearly separated responsibilities of different layers.

According to the Clean Architecture design principles, each layer should perform one task and be easily isolated from others. Another assumption is that a single piece of code could be shared between multiple environments. This would be done by bringing out two main modules independent of the technology in which we create the application: Presentation and Domain, and sharing them in other environments, adding only the Application and Data layers. These layers are closely linked to the environment in which we run the project. A good example would be writing business logic once and sharing it across iOS and Android mobile applications as well as web and desktop applications.

Also read:

• Microservices architecture
• MongoDB 
• Hexagonal architecture, a.k.a. ports and adapters

Clean Architecture – design patterns

The presentation module can be implemented using a number of popular design patterns:

• Model View ViewModel (MVVM),
• Model View Presenter (MVP),
• Model View Intent (MVI),
• Model View Controller (MVC)

and many others. Each developer has their own preference when it comes to choosing a pattern, although each of them has advantages and disadvantages. For the purpose of describing this architecture, we will focus on the MVP approach, the one I personally prefer.

Application

The application layer has the strongest connection to technology, where we use the Clean Architecture approach. It provides the entire visual part of the project and reacts to the tasks provided by the presentation layer. This layer determines how the data will be displayed. It contains the display logic and informs the presentation layer of any actions performed by the user. It also handles the Presenter’s state maintenance mechanism and prepares all the necessary dependencies for its proper operation.

Presentation

The Presenter controls both the entire application and individual screens. It also reacts to individual actions performed by the user in the visual part (GUI). It is also here that the decision is made on how to handle given tasks or which part of the application to show to the user in turn. UseCases, described below, are the only way this module communicates with others. It is used, for example, to execute business logic or to retrieve specific data. In the MVP approach, each Presenter has an interface to communicate with the view. This communication only allows tasks to be delegated to the view, but it does not allow something to be requested in return. Simply put, the Presenter executes functions on the visual interface, but these functions cannot have a return type.

Domain

Domain is the module that contains the business logic. It consists of a number of components:

UseCase

The most important, externally visible component. It is used by the presentation layer. UseCases are mappings of real business requirements that provide the presentation logic with access to data operations (fetch, change, listen for changes). They also allow business logic to be performed – calculations or manipulations – on data. It is worth mentioning that they are the only means of communication between the presentation layer and the domain layers. Data is transported by models stored in this layer as well. UseCases access data through DataSources via the interface they provide. The other type of dependencies they use are classes from the Logic layer described in the next parts of the article.

Model

This is a collection of data gathered in some logical way, used by business logic. This model does not have to be identical to the data layer model. It can, for example, combine several data models depending on the needs of the application.

Logic

A place in the structure that is used to store separated classes with extended business logic. This place makes it possible to avoid an extensive UseCase.

DataSource

The most important task of DataSources is to decide where data will be retrieved from or stored. DataSources, by means of interfaces, have access to all the data sources that the Data module exposes. In addition to the data inside, you will also find Mappers to translate the data from the Data layer into business models that will be used later. The DataSources are the only connection between the Data module and the rest of the business logic, and they are the ones that further expose the interfaces that give access to the customized data for the UseCase.

Mappers

The mappers in the Clean Architecture are responsible for the consistency of data provided by the Data layer. Here we check that all the necessary data has been provided so that the business logic can be fully operational. Mappers often combine several data layer objects from different sources to create one with all the data needed by business logic.

Data

A module that provides access to all types of data sources and models that map these data. The methods provided by this module can only be accessed via interfaces provided by this module. It is also the second module with the biggest dependence on the platform which Clean Architecture is used on.

Data transfer object

A data transfer object (DTO) is a model for two-way data transfer. Such models are only used in the Data layer, and depending on whether the data is being sent or retrieved, it is translated into or from business models using Mappers.

Data

Here data used in the rest of the application is retrieved and stored. Some examples of data sources are Bluetooth, Internet, Shared Preferences, databases, files, GPS, camera, gyroscopes or systems. Such data is accessed via the interface, which allows the source to be easily swapped. The substitution of such a source is done by specifying different objects implementing this interface. The substitution of data sources is most commonly used, for example, to support different types of servers or to support data mocking.

Disadvantages of Clean Architecture

Time-consuming

Implementing such complex architecture requires more time. In my experience, writing code using the Clean Architecture approach requires about 10% more time than developing an application without any special architecture.

You need know-how 

There is a high entry threshold into this type of approach for people with no prior architectural experience.

A large number of small classes and interfaces

Some will see this as a disadvantage, and others quite the opposite. Suffice to say that there is a grain of truth in each opinion. In my view, it is an advantage – those with a different opinion find the number of files difficult to manage and the changes made to them unreadable.

Project team building. Get to know the practical tips for Scrum Teams. Read the article

Advantages of Clean Architecture

Easier maintenance

Clean Architecture significantly simplifies project maintenance. Fixing and locating bugs with this approach is easier and faster.

Better change management

The approach speeds up the introduction of changes to the project. Thanks to small classes with separate responsibilities, it is very easy to modify the code for new requirements or add new functionalities without worrying about the impact on the rest of the project.

A large number of small classes and interfaces

As I have already written, there are myriad opinions on this topic. I consider it an advantage because, thanks to many small classes with separate functionalities, the code can be testable – that is, easily covered by tests.

Which projects should I use Clean Architecture in?

In my opinion, Clean Architecture works well in medium-sized to large projects. In small projects, the complexity of the approach may result in additional work.

But does this mean we shouldn’t use Clean Architecture in small projects? It’s worth remembering that they develop quickly and naturally. Deciding to use the CA approach even for smaller projects is justified, in my view. It allows you to avoid incurring the technological debt I mentioned in the opening paragraphs, especially when deadlines are not tight.

Summary

Referring to the concept of sharing two modules between multiple technologies, I think this is a great idea and we are getting closer to its application. So far it has been difficult to utilize its potential, but along with the development of programming languages like Kotlin, we may soon have the first projects that take full advantage of it. I hope I have been able to introduce the main principles of Clean Architecture and encourage you to use it in your projects. A well-considered choice of architecture will allow you to avoid technological debt, and this type of architecture – despite requiring detailed knowledge and allocating more time for implementation – undoubtedly works well in the long term in projects both large and small.

Go To:

1. 1. What is IT architecture?
2. 2. What is systems and application architecture?
3. 3. System architecture – the most common problems
4. 4. Do I need an IT architect?
5. 5. Summary

What is IT architecture?

Striving to order and simplify is human nature. It is the same in the complex and dynamic IT world. A well-thought-out and ordered architecture allows you to maintain control over the enormous number of elements. But what do we mean by “IT Architecture”?

The concept of architecture covers several areas:

• IT architecture – this is the broadest term that applies to IT infrastructure, meaning all devices, software, applications, solutions and processes in the company.
• Architecture of systems and applications – defines the way in which software functions in the ecosystem and how it communicates with its other elements. In order to achieve optimal results, the architecture should be created based on an analysis of processes in the organization.
• Data architecture – defines models of collecting, processing, organizing and storing data, as well as the method of managing and integrating this data (ETL processes – Extract, Transform, Load, and ESB – Enterprise Service Buses)
• Test architecture – includes a comprehensive description of the developed software test architecture and the dependencies of modules in the ecosystem, specifying the steps and techniques of testing.
• Cybersecurity architecture – defines standards and best practices for network and system security. It consists of the analysis of network protocols, physical device configuration, anti-virus software, encryption techniques, etc. In order to ensure proper functioning in this area, companies employ people in positions such as IT Security Architect, Security Engineer and Security Software Developers.

Elevate Your Application Development

Our tailored Application Development services meet your unique business needs. Consult with Marek Czachorowski, Head of Data and AI Solutions, for expert guidance.

Schedule a meeting

What is systems and application architecture?

In the era of Digital Transformation, companies are increasingly often deciding to implement new solutions. As we know, every project should start with a requirements analysis, which is the absolute basis of any product implementation or launch. Only then it is possible to suggest the optimal architecture.

Since good architecture is the foundation that allows you to build on the potential of an organization, it is worth spending time on a thorough analysis of the requirements. It all starts with the key question: “What is my goal?”. Having a defined goal, we consider how and within what timeframe we want to achieve it, therefore we must ask ourselves:

• How do I want to develop my systems and applications?
• Do I plan to implement new solutions, and if so, when?
• What are my business needs now and what will they be in 5 or 10 years’ time?
• What tasks should the architecture fulfil (e.g. the integration of existing solutions with other applications, the possibility of development, adding new components)
• Do I plan to transfer services to the increasingly popular cloud?

Good systems and applications architecture is one that fulfils the task which it is designed for. If you have difficulty defining your goal and in turn it prevents you from starting new projects, consult experienced IT architects. Such specialists provide consulting support, carry out individual analysis and build systems using only proven solutions and technologies.

System architecture – the most common problems

• The application architecture does not meet the business requirements – the market is dynamic, and the architecture of the implemented systems and applications should enable continuous development, be flexible, and allow for the use of the most recent technologies. Regardless of whether the company is undergoing a comprehensive transformation or is implementing a single application, a common problem in IT projects is the lack of a defined project goal, and implementation is carried out without an analysis of our needs. The result? Wasting money on a solution that does not pay for itself and does not bring any business value. A good architect will always pay attention to this type of issue, ask for clarification of business requirements and propose the optimal architecture.
• The solution is expensive to maintain – in projects, it may be that everything goes smoothly at the implementation stage, and only with time does the solution turn out not to be scalable. As a result, instead of saving, the company has to invest in expensive equipment. The IT architect creates optimal solutions based on proven technologies and new possibilities, such as the cloud.
• Architecture fails to meet safety standards – “Anything that can go wrong, will go wrong”. Nowhere is this truer than in the case of cybersecurity architecture. Cyberattacks and data leakage can happen to any company, and in 2020 IT security became an important aspect of investments. According to available studies, the threat of cyberattacks is growing by 30%, and cybersecurity audits and tests allow you to minimize this risk.

Do I need an IT architect?

Architects or IT engineers are specialists with broad competences, and demand for their services is increasing. These professionals are difficult to recruit and their rates are among the highest on the market. No wonder, as IT solutions architects are valuable and the most experienced developers for whom the role of an architect is a natural step in their IT career. Who would not wish to have a specialist who will not only analyze and design the way a given application functions in the system, but also take care of security and help to outline long-term strategy, as part of a project?

Tasks and skills of an IT architect:

• Designing IT systems and supervising the implementation and compliance with security policies
• Knowledge of the tools and techniques required to maintain architecture
• Analysis of business requirements in cooperation with a business analyst
• Business sense and expertise in programming
• High-level understanding of IT architecture and business architecture and the ability to build a long-term strategy
• Solid foundations of software engineering and support of developers
• Knowledge of the latest technological trends and developing technologies
• Connecting the past with the future – the architect implements new components and maintains the existing ones, making sure that all the elements work together.
• Connecting the world of IT and administration – knowledge of DevOps techniques and tools

Summary

A good and well-thought-out architecture of systems and applications is becoming increasingly important, and the dynamic market forces the development of and increased expenditure on new systems and cybersecurity. Investments in these solutions pay off and allow companies to save in the long run. This is the easiest way to minimize the risk of ill-considered implementation.