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}.

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


\begin{figure}[h!]
	\centering
	\begin{subfigure}[c]{0.32\textwidth}
		\includegraphics[width=\textwidth]{architecture-centralized}
		\caption{Centralized}
		\label{fig:architecture-centralized}	
	\end{subfigure}
	\begin{subfigure}[c]{0.32\textwidth}
		\includegraphics[width=\textwidth]{architecture-decentralized}
		\caption{Decentralized}
		\label{fig:architecture-decentralized}
	\end{subfigure}
	\begin{subfigure}[c]{0.32\textwidth}
		\includegraphics[width=\textwidth]{architecture-distributed}
		\caption{Distributed}
		\label{fig:architecture-distributed}
	\end{subfigure}
	\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, hence they are called peers (green).}
	\label{fig:software-system-architecture}
\end{figure}


\subsection{Centralized Applications}
\label{sec:centralized-applications}
In a centralized application (see Figure \ref{fig:architecture-centralized}), 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, web applications are designed as centralized applications. The clients are usually (mobile) apps or browsers that act as the interface to the user. Examples are social networks such as Facebook and Twitter.

The advantages of a centralized 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. These 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 solely 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 failure or the blockade of the server leads to a collapses of the entire system. 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. 

With regard to web platforms like Facebook, 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 mostly reversed in decentralized systems. Unlike centralized applications, decentralized applications do not have a single point of failure (see Figure \ref{fig:architecture-decentralized}). However, there is no node in the system that has all the data which makes accessing information sometimes hard. There is any number of nodes that perform the tasks of a server and by exchanging with other servers in total form a complete system.

Another advantage is that each server only handles the number of users covered by its resources. New servers contribute additional 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 are no longer available, even if the system itself remains functional. To tackle this issue, data needs to be replicated. 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 of the same application can still work together.

Examples of decentralized applications are the social networks diaspora* and Mastodon. In these networks, each user can operate a server on his own. Unlike Facebook, the decision on the existence of the service is therefore not in the control of the operator, but the user.

\subsection{Distributed Applications}
\label{sec:distributed-applications}
A feature of distributed applications is the computation across all nodes (see Figure \ref{fig:architecture-distributed}). 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. The boundaries between decentralized and distributed networks are becoming blurred. A decentralized network consisting only of servers corresponds quasi to a distributed network.

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 \ac{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 various sources in difference to \ac{HTTP} where only one source provides the file. Each peer not only downloads files but also provides files to other users. In order to avoid that nodes solely download (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}
Table \ref{tab:comparison-architectures} compares the main features of the different architectures as described before.

\begin{table}[h!]
	\centering
	\begin{tabularx}{\textwidth}{X|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{tabularx}
	\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}