% !TeX root = ../thesis.tex
%----------------------------------------------------------------------------
\chapter{Áttekintés a perem és \gls{felho} rendszerekről}
%----------------------------------------------------------------------------


% TODO: bevezetés

\section{Klasszikus \gls{felho} számítástechnikai megközelítés} % Egy kis áttekintés a "tradícionális felhőről"
\label{sec:tradicionalis_megkozelites}

\subsection{Általánosságban a \gls{felho}ről}

Általánosságban véve az informatikában akkor beszélhetünk \gls{felho}ről, amikor egy adott alkalmazást általunk üzemeltetett infrastruktúra helyett egy távoli szolgáltató által fenntartott környezetben futtatunk\cite{what_is_cloud}. Ebben a megközelítésben a környezet üzemeltetéséhez szükséges infrastruktúra egy vagy több -- a szolgáltató által fenntartott -- \gls{adatkozpont}ban foglal helyet.

A \gls{felho}szolgáltatások alkalmazásának több előnye is van, ezekből talán a legfontosabbak az
általános hardverelemek használatára visszavezethető alacsonyabb beruházási költség és az automatizált
folyamatok biztosította alacsonyabb üzemeltetési költség\cite{costofcloud}. Ezzel leveszi az üzemeltetés terhét és költségét az alkalmazás fejlesztőinek válláról.

Gyakran a \gls{felho}szolgáltató egynél több \gls{adatkozpont}ot tart fenn, amelyeket a világ több pontján helyeznek el. Ezzel biztosítva redundanciát, magasabb rendelkezésre állást és hatékonyabb elérést\cite{geodist}.

A felhő architektúráknak több modelljét is megkülönböztetjük. Ezeket pedig aszerint osztályozhatjuk, hogy mekkora kontrollt adnak a felhasználónak a futó alkalmazás felett. Ennek a kontrollnak a legalacsonyabb szintjén van az úgynevezett \acrfull{saas} (Szoftver mint szolgáltatás), amely egy előre telepített szoftver eszközt biztosít a szolgáltató \gls{felho} környezetében, amelyet általában a felhasználó az interneten keresztül ér el. Legmagasabb szintjén pedig a \acrfull{iaas} foglal helyet, ahol az alapvető infrastruktúrát készen kapjuk, de minden mást a szolgáltatás felhasználójának kell megterveznie, feltelepíteni, konfigurálni és üzemeltetni \cite{aas}.

Előnyei miatt, manapság a nagyvállalatok csaknem 94\%-a már használja a \gls{felho} szolgáltatások nyújtotta előnyöket és alkalmazásaiknak már 83\%-a valamilyen \gls{felho} környezetben futnak\cite{cloudadpotation}.

Amellett, hogy a \gls{felho}szolgáltatások adaptációja növekvő tendenciát mutat, az internetre kapcsolt eszközök száma is szépen gyarapodik\cite{annualinternetreport}. Ehhez a felhasználói készülékek mellett jelentősen hozzájárul az utóbbi időben jelentős fejlődésnek örvendő \acrfull{iot} rendszerek egyre nagyobb volumenű alkalmazása\cite{iotadpotation}.

Ezek alapján a \gls{felho} szolgáltatásokat nyújtó \gls{adatkozpont}ok kapacitásukat mind számítási teljesítményben, mind rendelkezésre álló sávszélességre való tekintettel egyre növekvő elvárással szembesülnek. Mindazonáltal a \gls{vegeszkoz}öket összekötő hálózatok is jelentősen növekvő igényeknek néznek elébe. Mindeközben pedig egyre nagyobb igény mutatkozik arra, hogy az alkalmazásaink jó válaszidővel, alacsony késleltetéssel működjenek\cite{stateofart}.


\subsection{Felhős alkalmazásüzemeltetési eszközök}

\subsubsection{Alkalmazás Konténer}

Egy alkalmazás konténer általánosságban egy önálló csomag, amely tartalmazza a futtatni kívánt alkalmazást és a futtatásához szükséges szoftver környezetet. A konténerek használata jelentősen megkönnyíti és meggyorsítja az alkalmazás fejlesztési és telepítési ciklust. Mivel magába foglalja a teljes környezetet, amely szükséges a futtatáshoz, így a szoftver  ugyanúgy fut a fejlesztők számítógépein, a tesztkörnyezetben és az éles környezetben is \cite{application_containers}.

Az alkalmazás konténerek koncepciójának megvalósítására egy népszerű implementáció a \textit{Docker}, amely a \gls{linux} kernelben található izolációs szolgáltatásokra épít. Ezzel valósítja meg, hogy a konténerek egymástól független környezetben tudjanak futni. Egyetlen szoftver erőforrás, amin közösen osztoznak az a kernel maga.

Dockerben az alkalmazást és környezetét úgynevezett képfájlokban (image) tároljuk. Ezek a képfájlok általában csak a legszükségesebb komponenseket tartalmazzák, ezért a virtuális számítógépekhez képfájlaihoz képest kisebb méretűek. Ezeket a képfájlokat az alkalmazás fejlesztése után készítjük és az alkalmazás konténer indításához használjuk \cite{docker_docs}.

\subsubsection{Kubernetes}

Manapság egyre jobban terjed a konténer alapú szoftver fejlesztés és a felhő alapú megoldások\cite{containermarketshare}. Az egyik legnépszerűbb ilyen felhő implementáció a \textit{Kubernetes}. A \textit{Kubernetes} egy konténer orkesztrációs platform, amely felügyeli és kezeli az egyes alkalmazásokat vagy szolgáltatásokat megvalósító konténerek életciklusát egy multihoszt környezetben.

Az életciklus kezelés mellett több hasznos szolgáltatást is nyújt. Ilyenek az automatikus szolgáltatás felderítés és terhelés elosztás, tárhely orkesztráció, konfiguráció kezelés. Bizonyos, megfelelően felkonfigurált helyzetekben a \textit{Kubernetes} képes alapszintű hibajavításra is, bizonyos szolgáltatások programozott újraindításával.\cite{kubernetes_docs}

Kubernetes klaszternek nevezzük azt a multihoszt környezetet, ahol több -- egymással hálózatba kötött -- számítógép (fizikai vagy virtuális) valósítja meg a \textit{Kubernetes} környezetet.

A klaszteren belül két jól elkülöníthető szerepkört definiálunk, ezek a master (mester) és a worker (munkás) szereprek. A master felel az erőforrások elosztásáért, a konténerek workerhez rendeléséért és összességében a klaszter irányításáért. A workerek felelnek a konkrét alkalmazásunkhoz tartozó konténerek futtatásáért. 

Egy \textit{Kubernetes} környezetben különböző objektumokat definiálunk, amelyekkel leírhatjuk a klaszterünkben futó alkalmazások elvárt állapotát. Ezek az objektumok közül a legkisebb kezelhető egység a \textit{Pod}. A \textit{Pod} egy vagy több futó konténert reprezentáló logikai egység. Az egy \textit{Pod}on belül futó konténerek osztoznak bizonyos névtereken, ilyen a hálózati vagy a folyamatok névtere.

Eggyel \enquote{nagyobb} objektum ezeknél a \textit{Deployment}, a \textit{Deployment} egy alkalmazás futtatásához szükséges állapotot írja le. A \textit{Kubernetes} klaszter törekszik a \textit{Deployment}ben megfogalmazott állapot elérésére és fenntartására.

\subsubsection{Mikroszolgáltatások}

A mikroszolgáltatás modell egy újkeletű architekturális megközelítés a szoftver fejlesztésben. Ebben a megközelítésben egyfunkciós modulokat tervezünk és fejlesztünk, amelyek jól definiált Alkalmazás programozói interfész (\acrlong{api}; \acrshort{api}) használatával kommunikálnak egymással\cite{microservices}. Ennek hála, amíg egy komponens teljesíti az elvárt \acrshort{api} definíciót, addig szabadon kicserélhető

Az egységek a fejlesztése, és tesztelése sokkal gyorsabb ütemben tud haladni a kisebb kódbázis miatt. A rajtuk eszközölt fejlesztések sokkal hamarabb kerülhetnek ki az éles rendszerbe, hiszen a változtatásuk nem érinti a teljes rendszert, ezért könnyebb őket frissíteni, vagy valamilyen szélsőséges esemény hatására visszaállni egy korábbi változatra.

Mikroszolgáltatásokkal az alkalmazások skálázása is jelentősen leegyszerűsödik. Míg egy monolit rendszerben a teljes alkalmazást skálázni kellett, ha nagyobb teljesítményre volt szükség, itt -- feltéve, hogy tisztában vagyunk vele, hogy mely komponensek jelentik a szűk keresztmetszetet -- elég csak a megfelelő szolgáltatásokat.

A mikroszolgáltatásoknak további előnyös jellemzője, hogy az egyes komponensek teljesen egyedül kezelik a saját belső adatstruktúrájukat. Az egyetlen kompatibilitási réteg, amelyet biztosítaniuk kell az az \acrfull{api} interfész. A mikroszolgáltatások teljesen szabadon változtathatják a belső struktúrájukat akár verziók között is. De nem csak az adatstruktúrával szemben van ekkora szabadságunk, hanem akár a különböző programnyelvekkel is.


\section{Peremhálózati rendszerek} % Szóval itt felvezetem hogy van ez a perem meme
\label{sec:peremhalozati_rendszerek}

A \gls{felho}-számítástechnika tradicionális megközelítésben való alkalmazásában jelentős hatékonysági kérdések merülnek fel. Mint ahogy azt \aref{fig:overview_no_edge}.\ ábra is szemlélteti, ha az egyes \gls{vegeszkoz}ök közvetlenül kommunikálnak a \gls{felho}szolgáltatást nyújtó \gls{adatkozpont}tal, az lineárisan növekvő terhelést jelent, mind a köztes hálózatnak, mint az \gls{adatkozpont}nak. Emellett a megtett távolság miatt a késleltetés is növekszik.

\begin{figure}[h!]
	\centering
	\includegraphics[width=0.7\textwidth]{figures/overview_no_edge.pdf}
	\caption{A hagyományos megközelítésben a \gls{vegeszkoz}ök közvetlenül az \gls{adatkozpont}okkal kommunikálnak}
	\label{fig:overview_no_edge}
\end{figure}


A fent vázolt problémákra megoldást ígér a peremhálózati rendszerek alkalmazása. A következőkben ismertetésre kerül a rendszer működése, elméleti felépítése és gyakorlati alkalmazása.


\subsection{Használt fogalmak}

A peremhálózat pontos definiálása egyelőre nem teljesen tisztázott mivel nem is egy egyszerű kérdés\cite{cureforedge, cloudflare_whatisedge}. Egyes források szerint a peremhálózati számítástechnika az magukon a \gls{vegeszkoz}ökön futtatott alkalmazások\cite{verge_whatisedge}, míg más források a \gls{felho} és a \gls{vegeszkoz}ök között elhelyezkedő számítási környezetre hivatkoznak így\cite{ibm_whatisedge}, illetve vannak források amelyek a határokat teljesen elmosva mindkettőt értelmezik\cite{cb_whatisedge, dataplace_whatisedge}

A fogalom -- és a kapcsolódó fogalmak -- tisztázására és egységesítésére a \textit{Linux Foundation} egy nyitott szójegyzéket hozott létre "\textit{Open Glossary of Edge Computing}" néven\footnote{\url{https://www.lfedge.org/openglossary/}}. Ezt a szabadon elérhető szójegyzéket egyre több gyártó ismeri el és használja\cite{openglossary}. 

A szójegyzék jelenlegi (2.0-ás verzió) kiadása alapján néhány fontosabb fogalmat az alábbiak szerint definiálhatunk:
\begin{itemize}
	\item \textbf{Cloud Computing} (\Gls{felho} számítástechnika): Egy olyan rendszer, amely igény-vezérelt hozzáférést biztosít megosztott erőforrásokhoz, beleértve a hálózatot tárolást és számítási kapacitást. Tipikusan kevés számú de nagy méretű regionális \gls{adatkozpont}okat használva.
	
	\item \textbf{Edge Computing} (Perem számítástechnika): A számítási kapacitás eljuttatása hálózat logikai végpontjaiba, annak érdekében hogy ezzel növeljék a teljesítményt, csökkentsék a működtetési költségeket illetve növeljék a rendelkezésre állását a biztosított alkalmazásoknak és szolgáltatásoknak. [\dots]
	
	\item \textbf{Edge Cloud} (Perem \gls{felho}): \Gls{felho}-szerű képességek az infrastruktúra peremén, amely -- a felhasználó perspektívájából -- hozzáférést enged \gls{elasztikus}an allokált számítási, adat tárolási és hálózati erőforrásokhoz. Többnyire észrevétlenül szolgál a centralizált privát- vagy publikus \gls{felho} kiterjesztéseként. A hálózat peremén telepített mikro-\gls{adatkozpont}okból épül fel. Időnként elosztott perem-\gls{felho}ként hivatkoznak rá.
	
	\item \textbf{Edge Data Center} (Perem-\gls{adatkozpont}): Olyan \gls{adatkozpont} amelyet a mennyire csak lehet a hálózat pereméhez lehet telepíteni szemben a hagyományos \gls{adatkozpont}okkal. Képes arra, hogy ugyanazokat a szolgáltatásokat nyújtsa, de önmagában egy sokkal kisebb skálán. [\dots] A \textit{perem} itt a telepítés helyére hivatott utalni. [\dots] Több perem-\gls{adatkozpont} egymással közvetlen kapcsolatban állhat, hogy ezzel biztosítsanak nagyobb kapacitást, migrációt meghibásodás elkerülés vagy terhelés elosztás céljából egy nagy virtuális \gls{adatkozpont}ként funkcionálva.
	
	\item \textbf{Infrastructure Edge} (Infrastruktúra pereme): Számítási kapacitás a peremen tipikusan egy vagy több perem-\gls{adatkozpont} formájában megvalósítva, amelyet a szolgáltatói \gls{lastmile}ön telepítenek. Számítási, adattárolási és hálózati előforrások, amelyeket az infrastruktúra peremére telepítenek lehetővé teszi a \gls{felho}szerű szolgáltatások nyújtását, hasonlóképp mint a centralizált központi \gls{adatkozpont}okban. Ilyenek például az erőforrások \gls{elasztikus} allokációja. De mindezt alacsonyabb késleltetéssel és csökkentett adat továbbítási költségekkel, a magas fokú lokalizációnak köszönhetően szemben a centralizált vagy regionális \gls{adatkozpont}okkal.
	
\end{itemize}

\textbf{A dolgozat további részeiben ezek a fogalmak a mérvadóak} (kivéve ahol ez külön jelölve van).

\subsection{Architekturális előnyök} % TODO: cite

Az előbbiek alapján ez a dolgozat peremhálózati \gls{adatkozpont}oknak azokat tekinti, amelyek logikailag -- és valamilyen szinten fizikailag is -- a \gls{felho} és a \gls{vegeszkoz}ök között helyezkednek el. Ezen a tartományon értelmezve "közel" áll a \gls{vegeszkoz}höz.

Ezt a fajta logikai "közelség" úgy valósul meg, hogy az úton, amelyet egy hálózati üzenetnek be kell járnia a \gls{vegeszkoz}től a \gls{felho}ig, a peremhálózati \gls{adatkozpont}ot a lehető legközelebb igyekszünk helyezni a \gls{vegeszkoz}höz. Következésképp egy hálózati csomagnak jelentősen rövidebb utat kell bejárnia a peremhálózati \gls{adatkozpont}ig, mint a központi megfelelőjéig. Egy ilyen architektúra vázlatát mutatja be \aref{fig:overview_with_edge}.\ ábra. Az \gls{adatkozpont} "közelebb" helyezése a végeszközökhöz számos előnnyel jár. 

\begin{figure}[h!]
	\centering
	\includegraphics[width=0.7\textwidth]{figures/overview_with_edge.pdf}
	\caption{A peremhálózati adatközpontok alkalmazásával egy kisebb skálájú, de teljes funkcionalitású \gls{adatkozpont}ot ékelődik a \gls{vegeszkoz} és a központi \gls{felho} közé.}
	\label{fig:overview_with_edge}
\end{figure}

Az egyik ilyen jelentős előny a késeltetés javítása. A hálózati adattovábbításhoz szükséges időt jelentősen befolyásolja mind az, hogy fizikailag milyen távolságba kell eljuttatni az információt (a jelenlegi legerősebb limitáló faktor maga a fényebesség az optikai összeköttetések esetén) de sokkal inkább az, hogy hány csomóponton kell áthaladnia útközben a csomagnak\cite{server_location_matters}. Azzal, hogy a távolságot és a köztes csomópontok számát csökkentjük jelentős javulást tudunk elérni a késleltetésben.

Az adatforgalomért sok esetben az interneten szolgáltatók között is fizetniük kell az egyes feleknek\cite{cloudflare_price_of_bandwidth}. Azzal, hogy az információnak kevesebb köztes csomóponton kell áthaladnia jelentős adatforgalmi költségeket lehet megtakarítani a köztes szolgáltatóknak. Különös tekintettel arra az esetre, ha az adatforgalom nem hagyja el a szolgáltatói hálózatot.

% TODO: privacy

% Villany használat
% Privacy/Security


\section{\Gls{felho} és perem rendszerek együttes alkalmazásának előnyei} % A perem és a felhő hálózatok mire jók

Ugyan a peremhálózati adatközpontok alkalmazása önmagában sok előnnyel kecsegtet, fontos megjegyezni, hogy a peremhálózati rendszerek nem fogják és nem is tervezik kiváltani a tradicionális megközelítést. Sokkal inkább azt kiegészítve szimbiózisban tudnak igazán érvényesülni.

% Itt le kell írni hogy van ez a két dolog
Egy ilyen "szimbiózisban" a peremhálózati rendszerekre mint a felhős szolgáltatások kiterjesztéseként tekinthetünk\cite{7807196}. A peremhálózati rendszerek korábban említett két előnye, amelyek az alacsony késleltetés és csökkentett hálózati költségek, kiegészítik a \gls{felho}s alkalmazásokat. A késleltetés érzékeny, vagy nagy adatot fogadó komponenseket kiszervezhetjük a peremre, ott akár még előfeldolgozást is végezhetünk az adatokon, így csökkentett mennyiségű és kevésbé késleltetés érzékeny adatokat kell csak eljuttatnunk a felhőbe, ezzel akár még a felhasználói élményt is javítva.

A gyakorlatban a technológia adott arra, hogy szinte bármit a kiszervezzünk a központi \gls{felho}ből a peremhálózati rendszerekre. Viszont a fent említett előnyök általában véve csak az alkalmazás valamely részegységében adnak értelmezhető hasznot. Fontos ezért a megfelelő architekturális tervezése az alkalmazásnak, illetve az alapos felmérése az igényeknek és a hasznoknak.


\section{Gyakorlati alkalmazás}
Számos olyan alkalmazás van, amelynél a peremhálózati és felhő rendszerek alkalmazásával jelentős javítást lehet elérni a fenti szempontokban. 

Jelenleg is már több alkalmazásnál is használják, vagy tervezik használni. Ilyenek például az önvezető járművek\cite{liu2019edge}, ipari rendszerek távfelügyelete\cite{hao2020cloud}, betegfelügyelet\cite{wang2020secure}, felhő alapú játék szolgáltatások\cite{edge_gaming}, okos otthonok és városok\cite{shi2016edge} és még sok minden más területen\cite{edge_companies}.

A dolgozatom részeként a \gls{felho} és a peremhálózati rendszerek előnyeinek bemutatására két konkrét alkalmazást készítettem, amelyen jól demózhatóak az előnyök. Ezeknek a megvalósítását a  \aref{chapter:birbnetes}.\ és \aref{chapter:ursim}.\ fejezetek részletezik.

\section{Alkalmazás futtatási és fejlesztési keretrendszerek}

% itt le lehet írni, hogy igazából mit is kell egy keretrendszernek tudnia

A feladatom megvalósításához több keretrendszert is megvizsgáltam, ezeket az alábbiakban részletezem.

\subsection{EdgeX Foundry}

Az \textit{EdgeX Foundry} egy mikroszolgáltatásokból felépülő környezet, amelynek a célja az, hogy a perem alkalmazások fejlesztésénél gyakran felmerülő feladatokat ellátó komponensek egységesek legyenek\cite{edgexfoundry_docs}.

A keretrendszer komponensei lazán csatoltak. Ez lehetővé teszi, hogy akár az előbb bemutatott három szintű peremhálózati architektúránál akár több réteget is bevezessünk. A komponensek mind platform függetlenek és a megfelelő környezetben egymástól függetlenül bárhol futtathatóak.

A keretrendszert felépítő mikroszolgáltatások négy rétegbe sorolhatóak:
\begin{itemize}
	\item \textit{Core Services Layer} (Központi szolgáltatások rétege): Ez a réteg tartalmazza az \textit{EdgeX} működéséhez elengedhetetlen komponenseket. Ezek felelnek az adatok és parancsok továbbításáért illetve a konfiguráció kezeléséért.
	
	\item \textit{Supporting Services Layer} (Támogató szolgáltatások rétege): Ez a réteg fogja össze a peremhálózaton működő analitikát, naplózást, ütemezést és tisztítási munkálatokat ellátó szolgáltatásokat. Ezek a szolgáltatásoknak valamilyen formában mindig szüksége lesz a központi réteg szolgáltatásaira hogy működjenek. Ezek a szolgáltatások teljesen opcionálisnak tekinthetőek.
	
	\item \textit{Application Services Layer} (Alkalmazás szolgáltatások rétege): Ebben a rétegben található szolgáltatások felelnek a az információ külső szolgáltatásba való továbbításáért: a gyűjtött adatok feldolgozásáért átalakításáért és továbbküldéséért. Az itt elhelyezkedő szolgáltatások "funkcionális csővezetéket" valósítanak meg. Ami azt jelenti, hogy minden feldolgozandó adat egy folyamatot indít el, amelynek során az funkciókon keresztül jut el végül a küldésig.
	
	\item \textit{Device Services Layer} (Eszköz szolgáltatások rétege):  A rétegben elhelyezkedő szolgáltatások feladata a többi eszközzel szenzorral való interfész megvalósítása. Egy szolgáltatás egy vagy több eszközt vagy szenzort kiszolgálhat annak natív protokollját használva. A natív protokollon érkező, vagy arra küldendő adatokat ezeknek a szolgáltatások a felelőssége átalakítani az \textit{EdgeX} többi rétegében használt közös formátumra alakítani.
\end{itemize}

Mindezek mellett két további két rendszerszolgáltatást is tartalmaz, ezek a biztonságért és a rendszerfelügyeletért felelnek.

\subsection{Project EVE}

A Project EVE célje egy különálló, direkt peremhálózati rendszerek megvalósítására tervezett operációs rendszer fejlesztése. A \Gls{linux} alapokra épül, erre épülő operációs rendszerük neve az EVE-OS. A rendszer célja a fejlesztés, orchestráció egyszerűsítése és egy nyílt platform létrehozása. Az EVE-OS jelenleg támogat Docker konténereket, virtuális gépeket és Kubernetes klasztereket, viszont utóbbi támogatása kezdetleges.

A projekt tervezése során kiemelt figyelmet fordítottak a a teljesítmény optimalizálásra. Lehetőség van az operációs rendszerben hogy a processzor és GPU erőforrásokat az egyes alkalmazások számára dedikáltan rendelje hozzá, valamint lehetséges távolról befolyásolni a processzor, memória, hálózat és egyéb erőforrások ütemezését. Mindezek mellett hangsúlyosak a biztonsági szempontok is mind hardveresen és szoftveresen is: A nem használt \acrshort{io} portokat ki lehet kapcsolni. A használt szoftverek távoli és automatizált frissítése is lehetséges. Az EVE-OS a rajta futó alkalmazásoknak további védelmet nyújt a policy alapú, elosztott tűzfal alkalmazásával. A fejlesztők igyekeznek az rendszert úgy konfigurálni, hogy az biztonságos alapbeállításokkal rendelkezzen.

Az EVE-OS a különböző futtatókörnyezeteket backendként definiálja. A rendszert képes egyszerre több backendhez csatlakozni egy időben. Ilyen backend lehet a felhőben vagy helyileg telepített. Egyszerre képes futtatni Kubernetes klaszterben lévő alkalmazásokat, virtuális gépeket és konténereket. 

A különböző backendek támogatása azzal jár, hogy ezeket egységes absztrakt interfészen keresztül kell tudnia kezelnie. Ennek az lehet a hátránya, hogy az elérhető funkcionalitások között a legkisebb közös halmazt szolgálja ki a felhasználó számára. A konkrét platformok egyéni előnyeinek kiaknázásra nem sok lehetőséget ad.


\subsection{Akarino Edge Stack}

A többi bemutatott megoldással szemben az \textit{Akarino Edge Stack} egy specifikáció halmaz, amely igyekszik a peremhálózati rendszerek fejlesztése során gyakran felmerülő problémákra tervezési mintákat adni.

Ezek a specifikációk lefednek számos az peremhálózati számítástechnika esetében releváns felhasználási területet, például a valós idejű játékokat, videófeldolgozást és elosztott gépi tanulást. A specifikációk megalkotása során cél a komplexitás minimalizálása véges számú lehetséges konfiguráció alkalmazásával. A specifikációk biztonsági szempontokból validálásra kerülnek.

% TODO befejezni

\subsection{StarlingX}

% TODO erről is írni valamit

\subsection{KubeEdge}

A \textit{KubeEdge} egy \textit{Kubernetes}re épülő rendszer, amely kiterjeszti annak képességeit peremhálózati rendszerek kezelésével\cite{kubeedge_docs}. Így lehetővé teszi a konténerizált alkalmazások futtatását a peremhálózaton. Architektúrája két részből épül fel, a központi felhőből és a peremhálózatól.

A központi felhőben található fő komponensek a \textit{CloudHub} és az \textit{EdgeController}. Az előbbi egy kommunikációs interfész, amely a peremhálózatot megvalósító szervergépekkel kommunikál. Felelőssége megoldani hogy az információ a lehető legnagyobb valószínűséggel eljusson azokhoz. Ennek érdekében egy átmeneti tárolót is fenntart a küldés alatt álló üzenetekhez. Az utóbbi magukért a szervergépek menedzselésért felel.

A peremhálózaton megtalálható a kommunikációs interfész párja \textit{Edged} néven. Emellett itt fut a \textit{KubeEdge} saját \textit{Pod} életciklus kezelője és meta adat tárolója. Emellett tartalmaz még egy \textit{EventBus} nevű komponenst is, amely a peremhálózaton belüli kommunikációért felel.

Az alkalmazás komponensek ugyanúgy képesek kommunikálni egymással, mint egy \textit{Kubernetes} környezetben a perem és a központi felhő komponensek között. Ugyanazok a monitorozó, felügyeleti és ütemezős eszközök működnek mindkét oldalán a rendszernek. Ezáltal a \textit{KubeEdge} lehetővé teszi, hogy a hagyományos formában felépített mikroszolgáltatás alapú alkalmazások komponenseit kiszervezze a peremhálózatra. Viszont bizonyos helyzetekben az alkalmazásnak a felelőssége megoldani, hogy áthidalja az olyan helyzeteket, amikor nem áll rendelkezésre kapcsolat a központi felhővel.

Mindennek köszönhetően a \textit{KubeEdge} platformon futtatható alkalmazások fejlesztése nagyon könnyű, hiszen az szinte teljesen megegyezik a mikroszolgáltatás alapú alkalmazások fejlesztésével.

\subsection{\acrshort{aws} \acrshort{iot} Greengrass}

Az \textit{\acrshort{aws} \acrshort{iot} Greengrass} egy az \textit{Amazon} által fejlesztett menedzselt (\acrshort{paas}) \acrshort{iot} platform. Segítségével a fejlesztés során lehetőség van az alkalmazáskomponensek helyi tesztelésére, valamint azok üzemeltetési folyamatainak felügyeletére is lehetőséget kínál. Az egyes telepített komponensek távoli frissítése is megoldott.

A rendszer két fő részből áll. Az egyik az \acrshort{aws} felhőben futó szolgáltatások halmaza, a másik pedig a peremhálózati rendszerre telepíthető\footnote{Az \textit{\acrshort{aws} \acrshort{iot} Greengrass} támogatja azt a megközelítést is ahol a peremhálózat maga a végeszközök rendszere. Ennek megfelelően a "kliens" alkalmazást oda is lehet telepíteni.} (itt átjáróként hivatkozott) "kliens" szoftver. Az \acrshort{iot} eszközök ezen az átjárón futó szoftverrel kommunikálnak. Az itt futó peremhálózati szolgáltatások pedig az interneten keresztül kommunikálnak az \acrshort{aws} felhőben futtatott többi komponenssel.

A két fő rész képes bizonyos ideig egymástól teljesen függetlenül üzemelni. Ha megszakad az összeköttetés a perem és a felhő rendszer között, akkor azok a peremhálózati rendszer képes továbbra is zavartalanul kiszolgálni az \acrshort{iot} eszközöket.

A szolgáltatás árazása az első tízezer csatlakoztatott eszköz esetében havi szinten \$0.16, viszont ebben az árban egyéb \acrshort{aws} szolgáltatások nem tartoznak bele, ami egy konkrét alkalmazás esetében jóval magasabb költségeket is eredményezhet

\subsection{Azure \acrshort{iot} Edge}

Sajnos itt egyértelműen úgy értelmezik a peremhálózati rendszereket, mint ami konkrétan az \acrshort{iot} eszközökön fut, így ez a feladat megoldása szempontjából nem alkalmas. Jelen bemutatása csak a teljesebb kép bemutatását szolgálja.


Az \textit{Azure \acrshort{iot} Edge} egy a \textit{Microsoft} által fejlesztett menedzselt (szintén \acrshort{paas}) platform. A rendszer lehetőséget nyújt \acrshort{iot} eszköztár menedzselésére, azokon távoli frissítéseket végezni és az önálló eszközök állapotát megfigyelni. Szükség esetén irányított beavatkozásra is lehetőséget az egyes eszközökön. 

A rendszer felépítése három fő komponensből áll. Az első az \textit{\acrshort{iot} Edge modules} amely a konkrét futtatható alkalmazásokat jelenti. Ezeknek a futtatásáért felel az \textit{\acrshort{iot} Edge runtime} amelyet az \acrshort{iot} eszközökön kerül telepítésre. És maga a \textit{cloud-based interface} amely a rendszer távoli monitorozásáért és kezeléséért felel.

A rendszer üzembe helyezéséhez az \acrshort{iot} eszközökön kizárólag az \textit{Azure \acrshort{iot} Edge} csomag telepítése szükséges. Az eszköz regisztrálása után központilag van lehetőség alkalmazásmodulok telepítésére.

Az \textit{Azure \acrshort{iot} Edge} előnye, hogy egy kiforrott ipari megoldásról van szó, viszont a belső működése a szolgáltatásnak zárt. Az árazás szintekbe van sorolva, az ingyenes szinten naponta csupán nyolcezer üzenetet lehet átvinni a \gls{felho}ben futó rendszer és a peremen\footnote{A dolgozat értelmezésében a végeszközök.} található eszközök között.