HOSN-app/thesis/content/02-background/software-system-architecture.tex

The software system architecture describes the relationships and properties of individual software components. It is a model that describes a software on a high-level design. The structure of an architecture can be represented mathematically as a graph, with the nodes representing the individual software components and the edges their relationships to each other. Although the individual components can be executed on the same computer, they are usually interconnected via networks. In general, a distinction is made between centralized, decentralized and distributed architectures as shown in Figure \ref{fig:software-system-architecture}.

\begin{figure}[h!]
	\centering
	\includegraphics[width=1.0\textwidth]{network-architectures}
	\caption{Schematic representation of various software system architectures. In centralized applications (A), all clients (blue) are in connection with a central server (red), while in decentralized applications (B) several servers provide for improved stability. In distributed applications (C), all nodes have the same role with the same tasks, which is why we also speak of peers (green).}
	\label{fig:software-system-architecture}
\end{figure}

%\begin{itemize}
%	\item Centralized Applications
%	\item Decentralized Applications
%	\item Distributed Applications
%\end{itemize}

In the following, the characteristics and peculiarities of the different architectures are described in detail.

\subsection{Centralized Applications}
\label{sec:centralized-applications}
In a centralized application, the software essentially runs on a central node with a static address with which all other nodes communicate. This central node is called a server and the nodes connected to it are called clients. The clients use the services of the server.

Typically, most web applications are designed as centralized applications. The clients are usually (mobile) apps or browsers that act as the interface to the user. Examples of this are social networks such as Facebook.

The advantages of such an architecture include that new clients can easily join the system simply by connecting to the server. Also, the maintenance of the software is easy to perform, since only the server node needs to be updated. Such structures are also advantageous for the speed and the associated user experience since servers are generally reachable via fast connections, have sufficient resources and do not need to use complicated routes across several nodes. Due to the special role of the server, the authentication of a client in the system is easy to perform. Only the server has to check whether the client only performs the actions to which it is authorized and can intervene if necessary. If a client is offline, this has no negative impact on the architecture. Because the software essentially runs on the server, clients only need to have low resources.

The biggest disadvantage with this architecture is that with the failure or the blockade of the server, the entire system collapses. So, the server is the single point of failure of the whole system. Due to the design, the server has all the data. This makes him not only a popular target for hackers but also brings the clients into total dependency on the server. Having access to all the data can be used to provide an improved user experience by adapting the software to the user's needs. But it can also be used for targeted advertising or sensible data can even get sold to third parties. Furthermore, the server decides which data to send to the client, which brings with it the danger of censorship. As the number of clients increases, the server must scale to have sufficient resources.

\subsection{Decentralized Applications}
\label{sec:decentralized-applications}
What are the advantages and disadvantages of centralized applications, is largely reversed in decentralized systems. Unlike centralized applications, decentralized applications do not have a single point of failure. But there is no node in the system that has all the data which makes accessing information sometimes hard. There are any number of nodes that perform the tasks of a server and by exchanging with other servers in total form a complete system.

Thus, the advantages of decentralized applications include, in addition to the already mentioned increased reliability, even further advantages. Each server only records the number of users covered by its resources. New servers contribute new resources to the overall system. Distributed applications cannot be disabled easily because a new server can be started at any time that does not fall under a lock. Because the data are not centrally available, they cannot be processed, so that user data are better protected. Also, there is no longer a prominent attack target. So, hacking a single server loses lucrativeness.

The drawbacks include the difficulty of finding data because they are spread across multiple servers. Search functionalities are thus difficult to implement. If a server is taken offline, the data is no longer available, even if the system itself remains functional. Since there is no longer a central point that is managed by an operator, rolling out updates is difficult. This raises the challenge that server nodes of different versions can still work together.

Examples of decentralized applications are the social networks Diaspora and Mastodon. Each user can operate his own server in these networks. Unlike Facebook, the decision on the existence of the service is therefore not in the control of the operator, but the user. Bitcoin is also a decentralized application architecture. In doing so, transactions are carried out in a decentralized database (blockchain).

\subsection{Distributed Applications}
\label{sec:distributed-applications}
A feature of distributed applications is the distributed computation across all nodes. At the same time, a single task is executed in parallel on several nodes of a system, and the entire system delivers the result in total.

In distributed applications, there is no hierarchy with servers or clients. Each node is equal to the other nodes with everyone performing the same tasks. For this reason, a node in this architecture is called a peer. The structure is then referred to as peer to peer (P2P). With such structures, there are no scaling problems, since each node contributes the required resources itself. Thus, the resources of the entire system grow with each new node added.

BitTorrent is an application that belongs to this architecture type. It solves the problem of downloading large files efficiently. When downloading a file, it is offered by several nodes so that different pieces can be loaded in parallel from different sources in difference to HTTP where only one source provides the file. Each node not only downloads but also provides itself to other files. In order to avoid that nodes download only (so-called Leechers) but also contribute, they are penalized with slow download speeds. This principle is known as \textit{tit for tat}.

\subsection{Comparison}
\label{sec:architecture-comparison}
The following table \ref{tab:comparison-architectures} compares the main features of the different architectures as described before.

\begin{table}[h!]
	\centering
	\begin{tabular}{l|c|c|c|}
		\cline{2-4}
		& \multicolumn{1}{l|}{Centralized Systems} & \multicolumn{1}{l|}{Decentralized Systems} & \multicolumn{1}{l|}{Distributed Systems} \\ \hline
		\multicolumn{1}{|l|}{Scalability}                                                  &                                          & +                                          & ++                                       \\ \hline
		\multicolumn{1}{|l|}{Maintenance}                                                  & ++                                       & +                                          &                                          \\ \hline
		\multicolumn{1}{|l|}{\begin{tabular}[c]{@{}l@{}}System \\ Stability\end{tabular}}  &                                          & +                                          & ++                                       \\ \hline
		\multicolumn{1}{|l|}{Performance}                                                  & ++                                       & +                                          &                                          \\ \hline
		\multicolumn{1}{|l|}{\begin{tabular}[c]{@{}l@{}}Data \\ Availability\end{tabular}} & ++                                       & +                                          &                                          \\ \hline
	\end{tabular}
	\caption{Comparison of different software system architectures on scalability, maintenance, system stability, performance, and data availability. The pluses indicate how positive something is relative to the other systems.}
	\label{tab:comparison-architectures}
\end{table}