Architectural Patterns | Technology blog
2021-03-02
technologY blogs from anasoft
In today’s edition of the technology blog, we will talk with Martin Vozár, one of the designers at ANASOFT. He has more than 20 years of experience with the development of custom-made applications from the smallest to the largest enterprise solutions. We will discuss the distributed approach to application creation and its specifics.
How would you explain the distributed approach to application creation to readers?
Anyone who has experience with programming knows about the desire to have all the functionality in one application. It’s natural. When a person begins programming, they start with small applications where they develop everything on their own and where a different approach than one application is not even wanted. It would only complicate things.
However, as solutions become more complex, the number of developers and the need or suitability to implement the solutions in another way grow.
I can use one of our recently implemented applications as an example. The task was to process an enormous amount of data from a large system and then return it to the system.
What did you do in this situation and why?
It’s important to realize what exactly an application like this is supposed to do. First, it needs to obtain data for processing from an external system. It needs to save this data on its own local database, and subsequently initiate business processes on them. User interface, through which an operator controls the system, is also added to these business processes. Afterwards, the processed data needs to be returned to the system they came from.
It is evident from the nature of the application that it performs many different operations. These include integrational or interface operations such as obtaining data from an external system and returning them, backend operations related to local storage and data processing and front-end operations of user interface for placing commands by the operator and the presentation of results.
And this requires a distributed approach?
It doesn’t, but in this case, it was one of the options, and it turned out to be a good one. Of course, it was possible to have a technical solution by creating one large monolithic application. In this case, however, we decided to create several individual applications, each of which would perform a very specific task. The individual applications worked together based on certain signals.
Could you give us a more specific example?
An application which is responsible for returning the data to the former large system functions by regularly monitoring the content of the agreed directory and if it finds files in the agreed format, it will process and send them to the former system. This approach has multiple advantages.
It was possible to have a technical solution by creating one large monolithic application. In this case, however, we decided to create several individual applications, each of which would perform a very specific task. The individual applications worked together based on certain signals.
Which are the most important ones?
It begins with the development itself. An individually designed application can be implemented independently from the rest of the system. A developer who doesn’t need to know about other parts of the system, can work on it. They only need to know that they need to monitor the content of the directory and to know how to process data and transfer them to the external system. This allows parallel development during a complete solution.
Another advantage is that codes of solutions like these codes remain relatively clean and readable. The application for the processing of files only deals with its task; other parts of the system, the other applications, do not need to worry about input output operations or connections to surrounding systems.
This approach simplifies the upkeep of the entire system as well as the error search. For example, if data are not returned to the external system, it is logical to start looking for the error in the application responsible for their transfer.
If the external system is not running, it only influences this one application while other parts of the system can continue running. Furthermore, if an error is found in the application that transmits data to the external system, it is only necessary to repair the code for this one application, and then test and deploy it. Other parts of the system, other partial applications, remain unchanged.
It’s also worth mentioning the higher option of simultaneously developing tasks and the option of using the specific knowledge of developers. Not every task is appropriate for each developer. Some are better at user interface creation, while others feel more at home with database operations or interfaces between various systems. The development of one large application means that various developers share a code and must at least have a basic knowledge about it, even about parts that are not concerned with their work. With individual applications, each developer has their own “playground” and it is only important to correctly set the connection between the individual parts of the solution.
If the external system is not running, it only influences this one application and other parts of the system can continue running. Furthermore, if an error is found in the application that transmits data to the external system, it is only necessary to repair the code of this one application, and then test and deploy it.
Thank you.
The interview was conducted by Boris Rybár
Manager of the Software Development Team
Does this distributed approach also have some disadvantages?
Like every approach, this one also has its own specifics. I intentionally don’t call them negatives.
To begin with, the correct design of the entire solution is very important to ensure that everything plays together as it should in the end. This requires a bit more time in the preparation phase, but it is necessary for solutions of a similar kind.
Setting the correct standards of development throughout all of the applications and on various levels is also important. Apart from naming conventions, correct logging plays an important role in this architectural pattern. Even though individual applications themselves log the activities they do on their own, it is important to remember that they are performing a task together.
If the entire process gets stuck somewhere, it is important to know how to effectively find where the first problem occurred and how it travelled throughout the entire system. This is why it is important to establish logging settings to ensure that individual applications log in a shared space, and apart from logging the specifics of the given application, that they also log some sort of business attribute, for example the number of the event, which is shared across the entire system.
If, for example, we imagine a distributed system for the processing of invoices, the individual parts of the system should, in addition to other things, log the number of the invoice on which they are performing the operation. This makes it possible to quickly search for the error in the central log and recognize the events related to the same operation (the invoice) across the entire system.
