Phenquestions
Fiziskie datori
Mēs esam nonākuši tālu no dotcom laikmeta masveida serveriem. Tajās dienās serveru infrastruktūra galvenokārt bija uz vietas. Uzņēmums savus risinājumus vadīja fiziskajā serverī. Cilvēki dažādiem mērķiem izmantoja veselus atsevišķus serverus (rezerves kopijas, pasta serveri, tīmekļa serveri utt.). Kad noteikts serveris nespēja sekot līdzi pieaugošajām uzņēmuma vajadzībām, to nomainīja jaunāks ātrāks serveris. Jūs mērogojāt, iegūstot labāku aparatūru. Jūs mērogojāt vertikāli.
Hipervizori
Tad pienāca hipervizoru ēra. Tas ieguva impulsu, pieaugot VMWare, un cilvēki saprata, ka viņi var iegūt vienu plauktu, lai tos visus pārvaldītu. Viens plaukts, lai palaistu visus dažādos lietošanas gadījumus un katram no tiem nodrošinātu savu atsevišķo virtuālo mašīnu. Tas arī radīja mākoņdatošanu, un uzņēmumi pārtrauca tiešus ieguldījumus serveru aparatūrā un tā vietā izvēlējās "īrēt" virtuālos serverus.
Milzīgus un dārgus datu centrus visā pasaulē pārvaldīja mākoņu nodrošinātāji. Uzņēmumi to izmantoja, nodrošinot savus pakalpojumus visā pasaulē, izmantojot pēc iespējas plašāku datu centru klāstu. Tas tika darīts galvenokārt, lai samazinātu kavēšanos, uzlabotu klientu pieredzi un mērķētu uz lielāku tirgu.
Tas arī lika programmatūras autoriem domāt par izplatītām sistēmām. Viņi uzrakstīja programmatūru, lai tā konsekventi un uzticami darbotos nevis vienā milzu datorā, bet gan daudzos viduvējos. Jūs mērogojāt horizontāli.
Jūs joprojām varat mērogot vertikāli. Faktiski virtualizācijas dēļ vairāk resursu nodrošināšana kļuva vieglāka. Jūs izslēdzāt VM, pielāgojāt tā resursus un nedaudz samaksājāt savam mākoņa nodrošinātājam. Kūkas gabals.
Pakārtotie fiziskie serveri nav pazuduši. Mākoņpakalpojumu nodrošinātāji tagad ir atbildīgi par tīkla saskarņu, OS saderības un citu drausmīgu patoloģiju sarežģītības pārvaldību.
Konteineri
Tad nāca konteineri. Konteineri bija šī apbrīnojamā vieglā abstrakcija. Virtuāla vide ar operētājsistēmu, kas ļāva programmatūru iepakot un izvietot kā vienu vienību. Tāpat kā virtuālās mašīnas, katrs konteiners darbojās nezinot citus konteinerus, taču tiem bija kopīgs operētājsistēmas kodols.
Tas ļāva cilvēkiem izvietot programmatūru serveros (fiziskā vai virtuālā, tas nav svarīgi) vēl augstākā abstrakcijas līmenī. Jums nerūpēja ražošanas operētājsistēma. Kamēr tas atbalstīs jūsu konteineru tehnoloģiju, tas darbinās jūsu programmatūru. Arī konteinerus ir vieglāk uzvilkt, kas padarīja pakalpojumus mērogojamākus nekā jebkad agrāk.
Tas vēl vairāk palielināja izplatīto sistēmu elastību. Izmantojot tādas tehnoloģijas kā Kubernetes, jums var būt daudz konteineru, kas vada sarežģītu pakalpojumu klāstu. Izplatītās sistēmas piedāvā daudz priekšrocību - augstu pieejamību, izturību un spēju dziedēt sevi no mezgla atteices.
Tajā pašā laikā, tā kā tie ir tik sarežģīti, tos ir arī grūtāk izstrādāt, izvietot, uzturēt, uzraudzīt un atkļūdot. Tas ir pretrunā sākotnējai tendencei nojaukt programmatūras sarežģītību un deleģēt šo atbildību savam mākoņa nodrošinātājam. Šeit ienāk arhitektūra bez servera.
Bez servera vai FunctionS as-a-Service (FaaS)
Ideja par serveri bez saites galvenokārt ir guvusi AWS Lambda, un šeit es to izmantošu kā modeli, lai runātu par bez serveriem. FaaS pamatā ir šādi principi:
- Jūs maksājat par to, ko izmantojat
- Jums nav jārūpējas par mērogošanu
- Jūs koncentrējaties uz savu kodu, atstājot infrastruktūras pārvaldību AWS ziņā
Ja neviens nepiekļūst jūsu pakalpojumiem, pakalpojumi nav aktīvi. Tas nenotika tradicionālajos mitināšanas risinājumos, kur jūs maksājat par VPS, kas vienmēr ir izveidots un darbojas, pat ja tas sēdēja dīkstāvē, nedarot neko noderīgāku nekā klausoties jaunu pieprasījumu.
Bez servera arhitektūrā jūsu pakalpojums nedarbojas, ja kāds to patiešām nevēlas izmantot. Kad tiek iesniegts pieprasījums, lidojuma laikā tiek izveidots pakalpojums, kas to apstrādā.
Kā tas darbojas?
Jūsu funkcija (piemēram, Python, Go vai Java programma) atrodas failā AWS Lambda. Ar šo funkciju jūs saistāt noteiktus aktivizēšanas notikumus, piemēram, API vārteju vai jaunu objektu, kas nonāk jūsu S3 spainī. Un noteikti resursi, piemēram, datu bāze vai cits objektu veikals vai EC2 instance.
Reaģējot uz jebkuru no saistītajiem aktivizēšanas notikumiem, AWS Lambda izveido konteineru ar jūsu funkciju tajā. Funkcija izpilda un sniedz atbildi. Piemēram, ja jūsu S3 spainī nonāk jauns attēls, tad AWS Lambda var būt mašīnmācīšanās kods, kas analizētu šo attēlu un ierakstītu tā izvadi uz DynamoDB (vienu no AWS datu glabāšanas pakalpojumiem).
Jums nav jāmaksā par visu serveri, bet tikai par atmiņas apjomu, ko esat piešķīris savai funkcijai, saņemto pieprasījumu skaitu un cik ilgi funkcija darbojas.
Turklāt jums nav jāuztraucas par konteineru mērogošanu, reaģējot uz lielu ienākošo darba slodzi. Ja vienlaicīgi notiek daudz aktivizējošu notikumu, AWS rūpēsies par jaunu konteineru izveidi un darba slodžu plānošanu starp tām un visām citām sarežģītībām.
Nav pilnīgs risinājums
Kad parādījās virtuālās mašīnas, fiziskie serveri nebeidza pastāvēt. Kad ieradās konteineri, mēs joprojām izmantojām VM. FaaS ir augstāka līmeņa abstrakcija, un tā ļoti labi sader ar RESTful API, bezvalstnieku pakalpojumu un tādu vieglu valodu kā Node moderno dizainu.js vai Python.
Tomēr tas joprojām darbojas fiziskajā serverī (kuru pārvalda, piemēram, AWS), tas joprojām klausās ienākošos pieprasījumus (par to vienkārši nemaksājat tieši), un dati joprojām ir jāuzglabā pastāvīgi, tāpēc tas ir S3, EC2 un citu pakalpojumu integrācijas. Tomēr tā ir noderīga abstrakcija.
