Phenquestions
Fizični računalniki
Prišli smo daleč od množičnih strežnikov dotcom dobe. Takrat je bila strežniška infrastruktura večinoma lokalna. Podjetje je svoje rešitve izvajalo na fizičnem strežniku. Ljudje so uporabljali celotne ločene strežnike za različne namene (varnostne kopije, poštni strežnik, spletni strežnik itd.). Ko določen strežnik ni uspel slediti naraščajočim potrebam podjetja, ga je nadomestil novejši hitrejši strežnik. Prilagodili ste si z boljšo strojno opremo. Prilagodili ste navpično.
Hipervizorji
Nato je prišla doba hipervizorjev. Z vzponom VMWare je dobilo zagon in ljudje so spoznali, da lahko dobijo en stojalo, ki bo vladal vsem. Eno stojalo za zagon vseh različnih primerov uporabe in zagotavljanje vsakega od njih lastnega navideznega stroja. To je povzročilo tudi računalništvo v oblaku in podjetja so prenehala neposredno vlagati v strežniško strojno opremo in so se namesto tega odločila za najem virtualnih strežnikov.
Ogromne in drage podatkovne centre so upravljali ponudniki oblakov po vsem svetu. Podjetja so to izkoristila tako, da so svoje storitve zagotavljala po vsem svetu z uporabo najširšega nabora podatkovnih centrov. To je bilo storjeno predvsem za zmanjšanje zakasnitev, izboljšanje izkušnje strank in ciljanje na večji trg.
Zaradi tega so avtorji programske opreme razmišljali tudi o porazdeljenih sistemih. Napisali so programsko opremo, ki ne deluje na enem velikanskem računalniku, temveč na številnih povprečnih na dosleden in zanesljiv način. Prilagodili ste vodoravno.
Še vedno lahko merite navpično. Pravzaprav je zaradi virtualizacije zagotavljanje več virov postalo lažje. Izklopili ste VM, prilagodili njegove vire in ponudniku oblaka plačali malo več. Malenkost.
Osnovni fizični strežniki niso izginili. Ponudniki v oblaku so zdaj odgovorni za upravljanje zapletenosti omrežnih vmesnikov, združljivosti OS in drugih grozljivih patologij.
Zabojniki
Nato so prišli zabojniki. Zabojniki so bili ta neverjetna lahka abstrakcija. Navidezno okolje z operacijskim sistemom, ki je omogočilo, da se programska oprema zapakira in uvede kot ena enota. Tako kot navidezni stroji tudi vsak vsebnik ni vedel za druge vsebnike, vendar si je delil isto jedro operacijskega sistema.
To je ljudem omogočilo, da so programsko opremo na strežnikih (fizični ali virtualni ni pomembno) razporedili na še višji stopnji abstrakcije. Ni vam bilo mar za produkcijski operacijski sistem. Dokler je podpiral vašo tehnologijo zabojnikov, bi poganjal vašo programsko opremo. Tudi zabojnike je lažje vrteti, kar je storitve naredilo bolj razširljive kot kdaj koli prej.
To je še povečalo prilagodljivost porazdeljenih sistemov. S tehnologijami, kot je Kubernetes, lahko dobite številne kontejnerje z zapleteno paleto storitev. Razdeljeni sistemi ponujajo veliko prednosti, saj so na voljo razpoložljivost, robustnost in sposobnost samozdravljenja zaradi okvare vozlišča.
Ker pa so tako zapleteni, jih je tudi težje načrtovati, uvajati, vzdrževati, spremljati in odpravljati napake. To je v nasprotju s prvotnim trendom, da se programska oprema odvzame iz zapletenosti in to odgovornost prenese na ponudnika storitev v oblaku. Tu nastopi brezstrežniška arhitektura.
Brez strežnika ali funkcija kot storitev (FaaS)
Ideja brez strežnika se je vlekla predvsem zaradi AWS Lambda, in tukaj jo bom uporabil kot model za pogovor o brezstrežnikih. Načela, na katerih temelji FaaS, so:
- Plačate za tisto, kar uporabljate
- Ni vam treba skrbeti za skaliranje
- Osredotočite se na svojo kodo, upravljanje infrastrukture prepustite AWS
Ko nihče ne dostopa do vaših storitev, storitve niso aktivne. To ni veljalo za tradicionalne rešitve gostovanja, kjer plačujete za VPS, ki je vedno v pogonu, tudi če je bil v prostem stanju in ni naredil nič bolj koristnega kot poslušanje nove zahteve.
V brezstrežniški arhitekturi se vaša storitev ne izvaja, razen če jo kdo dejansko želi uporabiti. Ko pride zahteva, se sproti ustvari storitev, ki jo obravnava.
Kako deluje?
Vaša funkcija (na primer program Python, Go ali Java) je kot datoteka na AWS Lambda. S to funkcijo povežete določene dogodke sprožilca, na primer prehod API ali nov predmet, ki prihaja v vedro S3. In določeni viri, kot je baza podatkov ali druga shramba predmetov ali primerek EC2.
Kot odgovor na kateri koli povezani dogodek sprožilca AWS Lambda ustvari vsebnik z vašo funkcijo v njem. Funkcija se izvede in poda odgovor. Če na primer v vašo vedro S3 pride nova slika, ima lahko AWS Lambda v sebi kodo za strojno učenje, ki analizira to sliko in zapiše svoj izhod v DynamoDB (eno od storitev shrambe podatkov AWS).
Za celoten strežnik nimate plačila, temveč le za količino pomnilnika, ki ste jo dodelili svoji funkciji, število zahtev, ki jih prejmete, in koliko časa deluje vaša funkcija.
Poleg tega vam ni treba skrbeti za skaliranje vsebnikov kot odziv na veliko dohodno delovno obremenitev. Če se hkrati zgodi veliko sprožilnih dogodkov, bo AWS poskrbel za predenje novih zabojnikov in razporejanje delovnih obremenitev med njimi in za vse druge zapletenosti.
Ni popolna rešitev
Ko so se pojavili navidezni stroji, fizični strežniki niso prenehali obstajati. Ko so prispeli zabojniki, smo še vedno uporabljali VM-je. FaaS je abstrakcija višje stopnje in se zelo dobro prilega sodobni zasnovi API-jev RESTful, storitvam brez državljanstva in lahkim jezikom, kot je Node.js ali Python.
Vendar še vedno deluje na fizičnem strežniku (na primer upravlja AWS), kljub temu posluša dohodne zahteve (tega preprosto ne plačate neposredno) in še vedno morate trajno shranjevati podatke, zato je integracije za S3, EC2 in druge storitve. Kljub temu je koristna abstrakcija.
