Phenquestions
Fizikai számítógépek
Hosszú utat tettünk meg a dotcom korszak hatalmas szervereitől. Azokban a napokban a kiszolgálói infrastruktúra többnyire helyszíni volt. Egy vállalkozás fizikai kiszolgálón futtatta megoldásait. Az emberek egész különálló szervereket használtak különböző célokra (biztonsági mentések, levelezőszerverek, webszerverek stb.). Amikor egy bizonyos szerver nem tudott lépést tartani a vállalat növekvő igényeivel, akkor egy újabb, gyorsabb szerver váltotta fel. A jobb hardver javításával méretezett. Függőlegesen méretezett.
Hipervizorok
Aztán eljött a hipervizorok korszaka. A VMWare térnyerésével lendületet kapott, és az emberek rájöttek, hogy egy állványt kaphatnak mindannyiuk irányítására. Egy állvány az összes különféle felhasználási eset futtatásához, és mindegyiknek külön virtuális gépet biztosít. Ez felhőalapú számítástechnikát is eredményezett, és a vállalkozások abbahagyták a beruházásokat a szerver hardverébe, és inkább a virtuális szerverek bérlését választották.
Hatalmas és drága adatközpontokat kezeltek felhőszolgáltatók az egész világon. A vállalkozások ezt kihasználták azzal, hogy szolgáltatásaikat globálisan, a lehető legszélesebb adatközpont felhasználásával biztosították. Ez elsősorban a késleltetés csökkentése, az ügyfélélmény javítása és egy nagyobb piac megcélozása érdekében történt.
Ez a szoftverek szerzőit az elosztott rendszerek tekintetében is gondolkodásra késztette. Olyan szoftvert írtak, amely nem egyetlen óriás számítógépen, hanem sok középszerű számítógépen futtatható következetesen és megbízhatóan. Vízszintesen méretezett.
Továbbra is függőlegesen méretezhet. Valójában a virtualizáció miatt a több erőforrás rendelkezésre bocsátása könnyebbé vált. Kikapcsolta a virtuális gépet, módosította az erőforrásait, és fizetett egy kis többletet a felhőalapú szolgáltatójának. Szelet torta.
A mögöttes fizikai szerverek nem tűntek el. A felhőszolgáltatók most felelősek a hálózati interfészek összetettségének, az operációs rendszerek kompatibilitásának és más félelmetes kórképek kezeléséért.
Konténerek
Aztán jöttek a konténerek. A konténerek voltak ez a csodálatos könnyű absztrakció. Virtuális környezet operációs rendszerrel, amely lehetővé tette a szoftverek csomagolását és telepítését egyetlen egységként. A virtuális gépekhez hasonlóan mindegyik tároló nem tudott más tárolókról, de ugyanazon az operációs rendszer kernellel rendelkeztek.
Ez lehetővé tette az emberek számára, hogy még magasabb absztrakciós szinten telepítsenek szoftvereket szerverekre (fizikai vagy virtuális, mindegy). Nem érdekelt a termelési operációs rendszer. Amíg támogatja a konténerezési technológiát, addig futtatja a szoftverét. A konténereket is könnyebb felpörgetni, ami skálázhatóbbá tette a szolgáltatásokat, mint valaha.
Ez tovább növelte az elosztott rendszerek rugalmasságát. Az olyan technológiákkal, mint a Kubernetes, sokféle konténert futtathat komplex szolgáltatási tömbben. Az elosztott rendszerek számos előnnyel járnak: magas rendelkezésre állás, robusztusság és képesség arra, hogy meggyógyuljon egy csomópont meghibásodásából.
Ugyanakkor, mivel annyira összetettek, nehezebb őket megtervezni, telepíteni, karbantartani, figyelemmel kísérni és hibakeresni is. Ez ellentmond annak az eredeti trendnek, hogy elvonják a szoftver összetettségét, és ezt a felelősséget átruházzák a felhőszolgáltatóra. Itt jön be a szerver nélküli architektúra.
Szerver nélküli vagy szolgáltatásként funkcionáló (FaaS)
A szerver nélküli ötlet főleg az AWS Lambda miatt nyert vonzódást, és itt ezt modellként fogom használni a szerver nélküli. A FaaS alapelvei a következők:
- Fizet azért, amit használ
- Nem kell törődnie a méretezéssel
- Ön a kódjára összpontosít, az infrastruktúra kezelését pedig az AWS-re bízza
Ha senki nem ér hozzá az Ön szolgáltatásaihoz, a szolgáltatások nem aktívak. Nem ez volt a helyzet a hagyományos tárhely-megoldásoknál, ahol fizet egy VPS-ért, amely mindig működik és működik, még akkor is, ha tétlenül ült, és nem tett semmi hasznosat, mint meghallgatni egy új kérést.
Szerver nélküli architektúrában a szolgáltatás csak akkor működik, ha valaki valóban használni akarja. Amikor bejön egy kérés, menet közben egy szolgáltatás jön létre.
Hogyan működik?
A funkciója (például egy Python, Go vagy Java program) fájlként található az AWS Lambda fájlban. Ezzel a funkcióval társíthat bizonyos kiváltó eseményeket, például egy API-átjárót, vagy egy új objektumot, amely az S3-csoportba kerül. Bizonyos erőforrások, például egy adatbázis vagy egy másik objektumtár vagy egy EC2 példány.
Bármely társított eseményre reagálva az AWS Lambda létrehoz egy tárolót, amelyben a függvény található. A függvény végrehajtja és választ ad. Például, ha új kép kerül az S3 vödörbe, akkor az AWS Lambda tartalmazhat egy gépi tanulási kódot, amely elemzi ezt a képet, és a kimenetét egy DynamoDB-be írja (az AWS egyik adattárolási szolgáltatása).
Nem kell fizetnie egy teljes szerverért, csak a funkcióhoz rendelt memória mennyiségéért, a kapott kérések számáért és a függvény meddig tartó működéséért.
Sőt, nem kell aggódnia a konténerek méretezése miatt a beérkező nagy terhelés miatt. Ha sok kiváltó esemény történik egyidejűleg, akkor az AWS gondoskodik az új tárolók felpörgetéséről és a munkaterhelések ütemezéséről közöttük és az összes többi összetettség között.
Nem teljes megoldás
Amikor megjelentek a virtuális gépek, a fizikai szerverek nem szűntek meg létezni. A konténerek megérkezésekor még mindig virtuális gépeket használtunk. A FaaS egy magasabb szintű absztrakció, és nagyon jól illeszkedik a RESTful API-k, a hontalan szolgáltatások és a könnyű nyelvek, például a Node modern kialakításához.js vagy Python.
Ugyanakkor továbbra is egy fizikai szerveren fut (például az AWS kezeli), továbbra is hallgatja a beérkező kéréseket (csak közvetlenül nem fizet ezért), és továbbra is tartósan kell tárolnia az adatokat, ezért integrációk az S3, EC2 és más szolgáltatásokhoz. Ennek ellenére hasznos absztrakció.
