Application evolution or where are we going

To call the article “The Evolution of Applied Information Systems and the Prospects for the Development of Their Architecture” would be too academic, but there will be a very brief squeeze from real practical experience, possible options for the development of technologies that caused their needs and solutions. I hope that the article will help summarize and rethink a wide range of tasks related to applied information systems, and at once I want to clarify what I mean by these terms. IP is a system that provides processing, transmission and storage of data. This is not all programming, but now IP is most often associated with web and mobile applications, although they do not completely coincide with them, an equal sign between UI and IP cannot be put even more so. I ask everyone to look at the question as widely as possible and join the discussion in the comments. And yet, I deliberately will not use the names of frameworks and technologies to avoid unnecessary holivars, limiting myself to the generally accepted names of architectures, standards and protocols, which I recommend in comments.

Branches in technology have happened many times in history, but after a period of uncertainty there always follows a stage of sustainable development, when non-essential branches go into the shadows, and actual features are combined into the most viable hybrid. To begin with, we briefly trace how IP has evolved since their very appearance. For memories to flood, we need only 9 lines and a picture.

I did not specify the time of existence for architectures, because even now almost all of the listed solutions exist in their niches in parallel. For modern ICs, the prevailing technology is still # 5, i.e. Regular web pages with reloading by links (thin client) and all the logic on the server. For many tasks, more is not needed. At the leading edge of # 8, here web applications and mobile applications have merged architecturally, although they have many differences in technology and implementation. What next? Trends are already evident: the server is an API, a database on the client, rendering on the client, a rich GUI, work offline, high loads and a lot of users. But technologically, these needs are met by such different platforms that a fork has occurred. This is equally relevant for the web and for mobile applications. It must be said that for desktop applications the situation also coincides, with some reservations, but they are not in the trend now and we will assume that the following 4 development options can be applied to applied information systems in general.

Handling high cloud loads (#A Cloud Highload)

Advantages : Clouds perfectly cope with scaling, using the principle of REST, applications can serve tens of millions of subscribers, if they refuse the state, i.e. server processes do not store states in memory, all network calls are independent and do not transfer the session to any state.

Disadvantages : In real applications, they often deviate from REST precisely because a state is needed to solve a problem. It turns out pseudo-REST , not scalable, but with a bunch of restrictions. And most importantly, it is absolutely not suitable for applications that interact interactively with the user or provide interaction between users.

Conclusion : In many cases, this is the optimal solution: publishing content, information resources, and media can be effectively built in the cloud, but for complex applications with databases and interactivity, this is a step back from architecture # 8.

Application Servers (#B Application servers)

Benefits : The application server takes the place of the web server, i.e. it is not the application that runs under the control of the web server, but the web server is embedded in the application or application server. Moreover, to increase efficiency, HTTP / HTTPS can be replaced with specialized protocols based on TCP / TLS. This is especially true for mobile and desktop applications, which makes it possible to build RPC, event bus, database synchronization.

Disadvantages : Such applications do not yet have universal cloud solutions, but everything goes to the fact that they will soon appear. And before that, you need to reinvent your technology stack and build a private cloud yourself. It is difficult to maintain and maintain. In addition, the synchronization of the database on the server and the client is done manually, through the application, usually by super-efforts of developers, and it is usually not possible to reuse such solutions.

Conclusion : This direction is now available only to large companies that have the need to serve millions of users , create interactive applications or R & D laboratories preparing similar solutions for the mass user.

DB centric approach (#C Database-centric)

Advantages : It is very attractive to put the database forward on the application and set up synchronization (partial replication) between databases. Thus, we have DBMS embedded in applications and work not with the server, but from the local database. Many methods have already been invented for this: optimistic replication, operational transformation, conflict-free replicated data type, because the DBMS has been around for a long time and learned how to scale.

Disadvantages : Communication between applications only through data clearly limits our capabilities. This is a reduction of everything to work with the base. But what about the transfer of events, integration at the API level, a call to remote procedures? All this must be forgotten with the DB-centric approach.

Conclusion : For a certain class of tasks, this is a smart solution, and together with introspection and UI scaffolding, such an architecture automatically rolls out into a very wide field of application of more complex competitors, integrating with the help of the API and requiring all the time to write the interaction programmatically.

Peer-to-Peer or Peer-to-Peer Interaction (#D Peer-to-Peer)

Benefits : This will offload the servers that will only perform the bind / broker function. Local interaction between users is often more efficient than through a remote server, especially for large data streams. Gives hope for anonymity of private data exchange.

Disadvantages : The question of "trust" in peer-to-peer networks is still not completely overcome. It will not be possible to build distributed ICs only on P2P, the servers will still be in this scheme. So far there are no common protocols, libraries, frameworks and other software tools for implementation in the amount necessary for the construction of application ICs.

Conclusion : Elements of the peer-to-peer networks will be integrated into centralized IS.

Generalization of trends

It is not yet clear which hybrid will come out as a result of the merging of these areas, but it is already possible to build several assumptions and, at a minimum, to highlight trends.

It is already obvious that the branching of architectures at this stage will occur, first of all, by embedding the system components in the application itself:

• Embedded into the communication server application: HTTP / WS, HTTPS / WSS, TCP / TLS, etc.
• Embedded DBMS with automatic synchronization.
• By analogy, we can recall about another function of the IP, it is data processing or computation. So, embedded in applications of systems of distributed computing will happen sooner or later too. After all, user devices in our time have a large computing power and not to use them for distributed data processing, this is an impermissible architectural omission.

Personally, I want to combine the Data-centric architecture (which, according to the Pareto principle, will cover 80% of the needs with full automation) with the application server (which will enable integration at the API or event bus level for the remaining 20% ​​of cases). For this, the interaction protocol The IC must support 5 interaction types simultaneously: RPC, REST, Event BUS, DB Sync, Binary streaming. Our team is working on such a complex solution now.

In addition to four major architectures, you can build hybrids from a combination of individual features:

• Synchronization - synchronization of data structures between applications in distributed systems in a time mode close to real;
• Offline - the ability to work with part of the data stored in the local storage in a browser or a mobile application, and synchronize when you go online;
• Interactivity - the possibility of two-way exchange of events with the server and the construction of reactive components: UI, database cursors, application logic, network exchange, etc .;
• Low latency (or High availability) - the characteristic of readiness of processing requests and the optimization of server response time (not to be confused with bandwidth);
• Highload - processing of the intensive request flow (request per second), which includes their frequency, size, priority, waiting time in the queue, lifetime and resources for maintenance;
• High connectivity - a large number of competitive (simultaneous and long-lived) client connections to the server with the possibility of two-way data exchange initiated by any of the parties;
• High interconnection - characteristic of the intensity of interaction between competitive compounds, as well as the size of the interacting groups of compounds;
• Scalability - a group of horizontal and vertical scaling characteristics that provide scaling transparency for software and hardware (without rewriting code);
• Big data - the ability to process large amounts of data, such as streaming data processing or building queries to distributed repositories;
• Big memory and in-memory DB - high utilization of memory volumes or database transfer to the full memory with additional indexes for quick execution of queries;
• Integration flexibility is a characteristic of the flexibility and ease of integrating solutions based on introspection, automatic interface binding, scaffolding, and dynamic interpretation of metamodels .

In order for us all to understand the trends, I propose to answer questions, as well as, I will be grateful for constructive criticism and comments.