Phenquestions
Физически компютри
Изминахме дълъг път от масивните сървъри от епохата на доткомите. По онова време сървърната инфраструктура беше предимно локална. Бизнесът управлява своите решения на физически сървър. Хората използваха цели отделни сървъри за различни цели (резервни копия, пощенски сървър, уеб сървър и т.н.). Когато даден сървър не успя да отговори на нарастващите нужди на компанията, той беше заменен от по-нов по-бърз сървър. Вие мащабирате, като получавате по-добър хардуер. Вертикално сте мащабирали.
Хипервизори
След това дойде ерата на хипервизорите. Той набра скорост с възхода на VMWare и хората осъзнаха, че могат да получат една стойка, която да управлява всички тях. Една стойка за изпълнение на всички различни случаи на употреба и осигуряване на всеки от тях собствена отделна виртуална машина. Това също породи изчислителни облаци и бизнесът спря да инвестира директно в сървърния хардуер и вместо това избра да „наеме“ виртуални сървъри.
Огромни и скъпи центрове за данни се управляваха от доставчиците на облак по целия свят. Бизнесът се възползва от това, предоставяйки услугите си в световен мащаб, използвайки възможно най-широк спектър от центрове за данни. Това беше направено главно за намаляване на латентността, подобряване на клиентското изживяване и насочване към по-голям пазар.
Това също накара авторите на софтуера да мислят по отношение на разпределени системи. Те написаха софтуер, който да работи не на един гигантски компютър, а на много посредствени по последователен и надежден начин. Мащабирали сте хоризонтално.
Все още можете да мащабирате вертикално. Всъщност, поради виртуализацията осигуряването на повече ресурси стана по-лесно. Изключихте виртуалната машина, коригирахте нейните ресурси и платихте малко повече на вашия доставчик на облак. Парче торта.
Основните физически сървъри не са изчезнали. Облачните доставчици вече са отговорни за управлението на сложността на мрежовите интерфейси, съвместимостта на операционната система и други ужасяващи патологии.
Контейнери
След това дойдоха контейнерите. Контейнерите бяха тази невероятна лека абстракция. Виртуална среда с операционна система, която позволява пакетирането и внедряването на софтуер като едно цяло. Подобно на виртуалните машини, всеки контейнер работи без да знае за други контейнери, но те споделят едно и също ядро на операционната система.
Това позволи на хората да разполагат софтуер на сървъри (физически или виртуален, без значение) на още по-високо ниво на абстракция. Не ви беше грижа за производствената операционна система. Докато поддържаше вашата технология за контейнеризиране, той щеше да изпълнява вашия софтуер. Освен това контейнерите се въртят по-лесно, което прави услугите по-мащабируеми от всякога.
Това допълнително увеличи гъвкавостта на разпределените системи. С технологии като Kubernetes можете да имате легиони контейнери, изпълняващи сложен набор от услуги. Разпределените системи предлагат много предимства: висока наличност, стабилност и способност да се излекува от повреда на възел.
В същото време, тъй като са толкова сложни, те са и по-трудни за проектиране, внедряване, поддържане, наблюдение и отстраняване на грешки. Това противоречи на първоначалната тенденция да абстрахирате сложността на вашия софтуер и да делегирате тази отговорност на вашия облачен доставчик. Тук идва безсървърната архитектура.
Без сървър или функция като услуга (FaaS)
Идеята за безсървърно е придобила сила най-вече заради AWS Lambda и тук ще го използвам като модел, за да говоря за безсървърни. Принципите, на които се основава FaaS, са:
- Вие плащате за това, което използвате
- Не е нужно да се грижите за мащабиране
- Фокусирате се върху вашия код, оставете управлението на инфраструктурата на AWS
Когато никой няма достъп до вашите услуги, те не са активни. Това не беше така при традиционните хостинг решения, при които плащате за VPS, който е винаги работещ, дори ако той не работи без да прави нищо по-полезно от това да слушате нова заявка.
В безсървърната архитектура вашата услуга не работи, освен ако някой действително не иска да я използва. Когато влезе заявка, в движение се създава услуга, която да я обработва.
Как работи?
Вашата функция (например програма на Python, Go или Java) се намира като файл на AWS Lambda. С тази функция свързвате определени задействащи събития, като API шлюз или нов обект, идващ във вашата S3 група. И определени ресурси като база данни или друго хранилище на обекти или екземпляр EC2.
В отговор на някое от свързаните събития на задействането, AWS Lambda създава контейнер с вашата функция вътре в него. Функцията се изпълнява и дава отговор. Например, ако ново изображение влезе в кофа ви S3, тогава AWS Lambda може да има код за машинно обучение вътре в него, който да анализира това изображение и да запише изхода му в DynamoDB (една от услугата за съхранение на данни на AWS).
Не плащате за цял сървър, а само за обема памет, който сте разпределили за вашата функция, броя на заявките, които получавате, и за колко време се изпълнява вашата функция.
Освен това не е нужно да се притеснявате за мащабиране на контейнери в отговор на голямо входящо натоварване. Ако едновременно се случват много задействащи събития, тогава AWS ще се погрижи да върти нови контейнери и да планира натоварвания между тях и всички останали сложности.
Не е цялостно решение
Когато се появиха виртуални машини, физическите сървъри не престанаха да съществуват. Когато контейнерите пристигнаха, все още използвахме виртуални машини. FaaS е абстракция от по-високо ниво и се вписва наистина добре с модерния дизайн на RESTful API, услуги без гражданство и леки езици като Node.js или Python.
Въпреки това все още работи на физически сървър (управляван от AWS, например), той все още слуша входящи заявки (просто не плащате за това директно) и все още трябва да съхранявате данни по постоянен начин, поради което има интеграции за S3, EC2 и други услуги. Въпреки това е полезна абстракция.
