Phenquestions
Füüsilised arvutid
Dotcomi ajastu tohututest serveritest oleme jõudnud kaugele. Sel ajal oli serverite infrastruktuur enamasti kohapealne. Ettevõte käitas oma lahendusi füüsilises serveris. Inimesed kasutasid eri eesmärkidel terveid eraldi servereid (varukoopiad, meiliserver, veebiserver jne). Kui teatud server ei suutnud ettevõtte kasvavate vajadustega kaasas käia, asendati see uuema kiirema serveriga. Parandasite riistvara hankimist. Skaalatasite vertikaalselt.
Hüpervisaatorid
Siis saabus hüpervisorite ajastu. See sai hoogu VMWare'i esiletõusuga ja inimesed mõistsid, et neil on üks juhtimispult nende kõigi juhtimiseks. Üks riiul kõigi erinevate kasutusjuhtumite käitamiseks ja igaühe jaoks eraldi virtuaalse masina pakkumine. See tõi kaasa ka pilvandmetöötluse ning ettevõtted lõpetasid otse investeerimise serveririistvarasse ja otsustasid selle asemel virtuaalservereid rentida.
Tohutuid ja kalleid andmekeskusi haldasid pilvepakkujad üle kogu maailma. Ettevõtted kasutasid seda ära, pakkudes oma teenuseid ülemaailmselt, kasutades võimalikult laia andmekeskuste valikut. Seda tehti peamiselt latentsuse vähendamiseks, kliendikogemuse parandamiseks ja suurema turu sihtimiseks.
See pani tarkvara autorid mõtlema ka hajutatud süsteemide osas. Nad kirjutasid tarkvara, mis töötab järjepidevalt ja usaldusväärselt mitte ühes hiiglaslikus arvutis, vaid paljudel keskpärastel arvutitel. Skaleerisite horisontaalselt.
Skaleerida saab ikkagi vertikaalselt. Tegelikult muutus virtualiseerimise tõttu suurema ressursside eraldamine lihtsamaks. Lülitasite VM-i välja, kohandasite selle ressursse ja maksite oma pilveteenuse pakkujale veidi lisa. Käkitegu.
Alused füüsilised serverid pole kuhugi kadunud. Pilvepakkujad vastutavad nüüd võrguliideste keerukuse, operatsioonisüsteemi ühilduvuse ja muude kohutavate patoloogiate haldamise eest.
Konteinerid
Siis tulid konteinerid. Konteinerid olid see hämmastav kerge abstraktsioon. Operatsioonisüsteemiga virtuaalne keskkond, mis võimaldas tarkvara pakendada ja juurutada ühe üksusena. Nagu virtuaalsed masinad, töötasid kõik konteinerid teistest konteineritest teadmata, kuid neil oli sama operatsioonisüsteemi kernel.
See võimaldas inimestel serveritesse tarkvara (füüsilist või virtuaalset, see ei loe) juurutada veelgi kõrgemal abstraktsioonitasemel. Te ei hoolinud tootmise operatsioonisüsteemist. Niikaua kui see toetab teie konteineritehnoloogiat, käitab see teie tarkvara. Samuti on konteinereid kergem üles keerata, mis muutis teenused mastaapsemaks kui kunagi varem.
See suurendas hajutatud süsteemide paindlikkust veelgi. Selliste tehnoloogiate abil nagu Kubernetes saate keerukate teenuste massi käivitada hulgaliselt konteinereid. Hajutatud süsteemid pakuvad palju eeliseid - kõrget kättesaadavust, vastupidavust ja võimet end sõlme rikke tõttu ravida.
Kuna need on nii keerukad, on neid ka raskem kavandada, juurutada, hooldada, jälgida ja siluda. See on vastuolus algse suundumusega oma tarkvara keerukus välja tõmmata ja see vastutus delegeerida oma pilvepakkujale. Siin tuleb sisse serverivaba arhitektuur.
Serverita või funktsioonina teenusena (FaaS)
Serveritute idee on saanud tõuke peamiselt AWS Lambda tõttu ja siin kasutan seda mudelit, et rääkida serverivabast. FaaS-i aluseks olevad põhimõtted on järgmised:
- Maksate selle eest, mida kasutate
- Te ei pea skaleerimisest hoolima
- Keskendute oma koodile, jätate infrastruktuuri haldamise AWS-i hooleks
Kui keegi ei pääse teie teenustele juurde, pole teenused aktiivsed. See ei olnud nii traditsiooniliste hostimislahenduste puhul, kus maksate alati kasutusel oleva VPS-i eest, isegi kui see seisis jõude ja ei teinud midagi kasulikumat kui uue päringu kuulamine.
Serverita arhitektuuris ei tööta teie teenus, kui keegi seda tegelikult kasutada ei soovi. Kui päring tuleb, luuakse selle haldamiseks teenus käigu pealt.
Kuidas see töötab?
Teie funktsioon (näiteks Python, Go või Java programm) asub failina AWS Lambdas. Selle funktsiooniga seostate teatud käivitusüritused, näiteks API-lüüsi või uue objekti, mis tuleb teie S3 ämbrisse. Ja teatud ressursid nagu andmebaas või mõni muu objektipood või EC2 eksemplar.
Vastuseks mis tahes seotud käivitusüritusele loob AWS Lambda konteineri, milles on teie funktsioon. Funktsioon täidab ja annab vastuse. Näiteks kui teie S3 ämbrisse tuleb uus pilt, võib AWS Lambda sees olla masinõppekood, mis seda pilti analüüsiks ja kirjutaks selle väljundi DynamoDB-sse (AWS-i üks andmebaaside teenus).
Te ei pea maksma kogu serveri eest, vaid ainult funktsioonile eraldatud mälumahu, saadud taotluste arvu ja funktsiooni töötamise eest.
Pealegi ei pea te muretsema konteinerite skaleerimise pärast vastusena suurele sissetulevale töökoormusele. Kui samaaegselt juhtub palju käivitavaid sündmusi, hoolitseb AWS uute konteinerite keerutamise ning nende ja kõigi muude keerukuste vahelise töökoormuse ajastamise eest.
Pole täielik lahendus
Kui virtuaalsed masinad tulid, ei lakanud füüsilised serverid olemast. Konteinerite saabudes kasutasime endiselt VM-e. FaaS on kõrgema taseme abstraktsioon ja see sobib väga hästi RESTful API-de, kodakondsuseta teenuste ja kergete keeltega nagu Node kaasaegse kujundusega.js või Python.
Kuid töötab endiselt füüsilises serveris (mida haldab näiteks AWS), see siiski kuulab sissetulevaid päringuid (te lihtsalt ei maksa selle eest otse) ja peate endiselt andmeid püsivalt salvestama, mistõttu see on S3, EC2 ja muude teenuste integreerimine. Sellest hoolimata on see kasulik abstraktsioon.
