
\section{Základní architektonické vzory a jejich návrhové vzory}
Existují dvě velice odlišné architektury programu: monolitická architektura a mikroslužební architektura. \cite{analyzaModernichSWArchitektur} Obě  mají svoje výhody a nevýhody. Abychom v budoucnu nemuseli měnit kompletně design aplikace, aby se zamezilo případným problémům a snížily se tak budoucí náklady na údržbu, porovnáme tyto dvě architektury a vybereme pro BillSaver vhodnější variantu v kapitole \ref{subsection:architecture}.

\subsection{Monolitická architektura}
Monolitická architektura je považována za tradiční styl tvorby aplikací. Celý systém se staví jako jeden nedělitelný celek, jenž obsahuje celou logiku programu. Vnitřně se většinou dělí do logických vrstev, které obsluhují různé části aplikace.

\begin{figure}[h]
    \centering 
    \includegraphics[width=10cm]{images/Monolithic-architecture.png}
    \caption{Příklad monolitické architektury \cite{architectureImg}} 
    \label{fig:monolithicModel}
\end{figure}
Monolitická architektura se vyznačuje svou provázaností mezi jednotlivými vrstvami aplikace. Celý systém se píše do jediného projektu a je riziko, že tak všechny vrstvy budou silně provázány. Toto způsobuje u velkých projektů komplikace. Změny v jediné komponentě mohou kaskádovat v masivní změny v různých částech celého programu, které tak mohou prodloužit implementační dobu klidně i 10krát. To poté zvyšuje náklady na případné změny a prodlužuje vývojový čas. \cite{analyzaModernichSWArchitektur} 

Na druhou stranu silná provázanost a přímá komunikace, která probíhá pouze uvnitř aplikace, může vést k lepší rychlosti a celkové odezvě systému. Rozdíl mezi mikroslužební a monolitickou architekturou může být až 6\%. \cite{monoliticMicroserviceSpeedComparison} Studie, která porovnávala rychlosti jednotlivých architektur, však nebrala v potaz škálovatelnost mikroslužební architektury.

Další výhoda monolitické aplikace je její relativně jednoduchá instalace na lokálním stroji, kde bude probíhat vývoj. Programátorovi potřebuje běžet na počítači pouze jedna aplikace, kterou může následně upravovat na jednom místě. Protože však každá změna vede k překompilování celého programu, může vývoj aplikace doprovázet dlouhé prostoje.

\subsubsection{Výhody}
\begin{itemize}
\item Snadné nasazení – Monolitická aplikace je pouze jedna, nasazení nové verze aplikace do serveru je tak velice jednoduché. 
\item Snadná konfigurace – Nastavení celé aplikace se většinou nachází pouze na jednom místě. Není tak potřeba mít dedikovaný systém, v němž se bude sledovat více konfiguračních souborů, stačí pouze jeden.
\item Snadné testování – Díky tomu, že celý kód aplikace se nachází na jednom místě, můžeme se spolehnout, že případná chyba bude vždy v daném kódu. Dále také není  potřeba spouštět více aplikací, které bychom potřebovali ke zprovoznění naší aplikace.
\item Jednoduché monitorování – Monitorování aplikace je velice jednoduché. Není potřeba agregovat více souborů s detailní činností aplikace. Zjišťování stavu aplikace se většinou také nachází na jednom místě.

\end{itemize}

\subsubsection{Nevýhody}
\begin{itemize}
\item Komplexnost – Celý systém se stává komplexním a provázaným velice rychle.
\item Velikost týmů – Čím více aplikace nabývá funkci, tím více lidí ji většinou musí udržovat. Domluva ve velkých týmech je neefektivní a dohoda na nových postupech a technologiích je tak pomalá.
\item Pomalá kompilace – Čím větší je aplikace, tím narůstá nejen kompilační, ale i testovací čas.
\item Pomalá adopce nových technologií – Pro přesun na novou technologii je zapotřebí upravit spoustu existujícího kódu. To navyšuje čas a tím i cenu adopce nových technologií.
\end{itemize}

\subsection{Mikroslužební architektura}
Jak je z názvu patrné, mikroslužební architektura se dělí na malé části. Každá část neboli služba funguje jako samostatně spustitelný program. Tyto služby zprostředkovávají jednu a pouze jednu logickou službu. Pro příklad můžeme uvést webový obchod, který je postaven na mikroslužební architektuře. Služby by mohly vypadat takto: registrační služba, platební služba, služba pro uživatelské rozhraní, služba pro řízení stavu skladu, účetní služba a mnoho dalších. Velikost jedné služby není přesně definovaná.

Pokud bude služba příliš velká, dostáváme se do stejných problémů jako u monolitické architektury. Pokud bude naopak příliš malá, budeme řešit spoustu problémů s komunikací mezi aplikacemi. Systém se stane celkově  neúnosně roztříštěným. \cite{microserviceArchitecture}

Protože by každá služba měla být nezávislá, můžou se používat různé technologie napříč všemi službami. Toto se však nedoporučuje kvůli případným problémům se znalostí velkého množství technologií. Pokud jeden tým nakonec bude muset udržovat více služeb, může nastat problém s tím, že nezná určité technologie, které jsou v některých službách. 

Každá služba může vznikat nezávisle na ostatních. Tím pádem se do produkčního prostředí dají nasazovat také nezávisle. Kvůli velikosti obsahuje každá služba méně firemní logiky, a je tak většinou jednodušší na pochopení a rychlejší na vývoj. 

Na rozdíl od monolitické aplikace se však jen těžko dá zabránit nekonzistentnosti dat mezi službami. Monitorování celé aplikace je také náročné kvůli množství nezávislých služeb. Prvotní návrh je složitější a vyžaduje komplexní znalost celé problematiky. \cite{microserviceArchitecture} Dokonce vznikají i nové problémy, které vůbec neexistovaly v monolitické architektuře. Zajištění komunikace mezi službami může být náročné, protože se musí řešit i síťové problémy. Je nutné zajištění automatického nasazení služeb, bez něhož by to vyžadovalo neúměrné úsilí od administrátorů.

\begin{figure}[h]
    \centering 
    \includegraphics[width=10cm]{images/Microservice-architecture.png}
    \caption{Příklad mikroslužební architektury \cite{architectureImg}} 
    \label{fig:microserviceModel}
\end{figure}

\subsubsection{Výhody}
\begin{itemize}
\item Flexibilita -- Vývoj úplně nové funkcionality je velice jednoduchý kvůli neexistujícímu stávajícímu kódu. Vždy se začíná od začátku. \cite{microserviceArchitecture}
\item Jednoduchá adopce nových technologií -- V případě, že jedna služba chce adoptovat novou technologii, není zapotřebí upravovat velké množství kódů. Toto však neplatí při adopci technologie napříč vícero službami.
\item Robustnost – Pád jedné služby neznamená kolaps celé aplikace.
\item Rychlý vývoj – Po vytvoření aplikačního rozhraní můžou týmy nezávisle pracovat na různých službách.
\item Rychlá kompilace – Kvůli velikosti jedné služby není potřeba kompilovat velké množství kódů.
\item Jednoduché porozumění – Protože jedna služba dělá pouze určitou funkci, její obchodní logika není tak rozsáhlá a pochopení služby je jednodušší a rychlejší.
\item Jednoduchá škálovatelnost – Architektura celého systému umožňuje nezávislou replikaci jednotlivých služeb. Například v případě vánoční nákupní horečky se může platební systém replikovat a odbavit tak více uživatelů najednou.
\item Schopnost používat tu nejlepší technologii pro danou činnost – Každá služba může používat specializovanou technologii, která nejlépe řeší její problematiku. \cite{microserviceArchitecture}

\end{itemize}

\subsubsection{Nevýhody}
\begin{itemize}
\item Obtížné testování – Pro testování je zapotřebí procházet více aplikací. Nastavení testovacího scénáře vytváří nutnost spouštění více služeb najednou. \cite{microserviceArchitecture}
\item Nutnost řešit datovou konzistentnost – Protože každá služba může vlastnit databázi, je zapotřebí informovat ostatní služby o změnách v uživatelských datech. \cite{analyzaModernichSWArchitektur}
\item Velice obtížné zachování ATOM-icity – V případě chybného správcování je zapotřebí zrušit uživatelský požadavek mezi službami. \cite{architectureImg}
\item Obtížná komunikace mezi službami – Každá služba musí řešit komunikaci přes jednotné rozhraní a tak musí i řešit případné chyby v síťové komunikaci.
\item Obtížný návrh služeb – Vytvořit správné rozvržení služeb vyžaduje komplexní znalost problematiky, která nemusí být na začátku celkově známá. \cite{analyzaModernichSWArchitektur}
\end{itemize}

\subsection{Porovnání architektur}

\noindent
\begin{minipage}{\linewidth}
\centering
\begin{tabular}{|>{\centering}m{0.182\linewidth}|>{\centering}m{0.238\linewidth}|>{\centering}m{0.267\linewidth}|>{\centering\arraybackslash}m{0.25\linewidth}|} \hline
\multicolumn{2}{|>{\centering}m{0.42\linewidth}|}{\textbf{Monolitická aplikace}} &  \multicolumn{2}{>{\centering\arraybackslash}m{0.517\linewidth}|}{\textbf{Mikroslužební aplikace}}       \\ \hline
\textbf{Klady}   & \textbf{Zápory}    & \textbf{Klady}     & \textbf{Zápory}  \\ \hline\hline
Snadné nasazení         & Komplexnost   & Flexibilita                           & Obtížné testování                     \\ \hline
Snadná konfigurace      & Velikost týmů & Jednoduchá adopce nových technologií  & Nutnost řešit datovou konzistentnost  \\ \hline
Snadné testování        & Pomalá kompilace                    & Robustnost      & Velice obtížné zachování ATOM-icity   \\ \hline
Jednoduché monitorování & Pomalá adopce nových technologií    & Rychlý vývoj    & Obtížná komunikace mezi službami     \\ \hline
&    & Rychlá kompilace             & Obtížný návrh služeb                  \\ \hline
&    & Jednoduché porozumění                                          &     \\ \hline
&    & Jednoduchá škálovatelnost                                      &     \\ \hline
&    & Schopnost používat tu nejlepší technologii pro danou činnost   &     \\ \hline
\end{tabular}

\captionof{table}{Porovnaní jednotlivých  architektonických stylů}
\label{table:architectureComparison}

\end{minipage}
