Без сървъри в облака: AWS срещу Google Cloud срещу Microsoft Azure

Ако някога сте се събуждали в 3 часа сутринта, защото сървърът се е объркал, ще разберете привлекателността на модна дума като „без сървър“. Конфигурирането на машините може да отнеме часове, дни или понякога дори седмици и след това трябва да се актуализират постоянно, за да се поправят грешки и дупки в сигурността. Тези актуализации обикновено водят до собствени кавги, тъй като новите актуализации причиняват несъвместимости, принуждаващи други актуализации или поне така изглежда безкрайно.

Безкрайната верига от главоболия от управлението на сървър е една от причините големите облачни компании да възприемат „безсървърната“ архитектура. Те знаят, че шефът е чувал оправданията - сървърът този, сървърът - твърде дълго. Ако можехме да се отървем само от тези сървъри, шефът трябва да помисли.

Това е прекрасен термин за продажби, единственият проблем е, че не е строго верен. Тези приложения са без сървъри по същия начин, по който ресторантите са без кухня. Ако това, което искате, е в менюто и ви харесва как готвачът го приготвя, седенето в ресторант е страхотно. Но ако искате различно ястие, ако искате различни подправки, добре, вземете си собствена кухня.

Amazon, Google и Microsoft са три от по-големите компании, които се борят да хостват приложения на бъдещето, такива, които се надяват да бъдат записани в техния API без сървъри и управлявани чрез техния слой за автоматизация. Ако платформите правят това, което искате - а новите модели са доста общи - те могат да бъдат най-простият и бърз начин за създаване на ваше собствено уеб приложение за еднорог за милиарди долари. Пишете само най-важните логически битове и платформата обработва всички подробности.

Безсървърните функции се превръщат в лепило или скриптов език, който свързва всички функции на облака. Инструментите за картографиране или AI, които преди бяха доста независими, сега са свързани чрез безсървърни функции, управлявани от събития. Сега повече от вашата работа може да бъде решена чрез заявки, които се вълнуват и отскачат през различните ъгли на всеки облак, задействайки и задействани от поток от събития. Ако искате да изследвате машинното обучение и да го използвате за анализ на вашите данни, един от най-бързите начини да го направите е да създадете безсървърно приложение и да започнете да изпращате събития до ъгъла за машинно обучение в облака.

Неявното обещание е, че нарязването на всичко по-тънко улеснява споделянето на ресурси в облака. В миналото всички биха трескаво създавали нови екземпляри с, да речем, Ubuntu Server, работещ в собствена виртуална машина. Всички използваха една и съща операционна система и тя беше дублирана милион пъти в една и съща реална кутия, която се преструваше на дузина или повече виртуални кутии на Ubuntu. Безсървърните операции избягват цялото това дублиране, което прави облачните изчисления драстично по-евтини, особено за работни места, които се изпълняват спорадично и никога не са засядали старата кутия, седнала във вашата климатизирана сървърна стая.

Разбира се, всичко това удобство има скрити разходи. Ако някога искате да напуснете или преместите кода си на друг сайт, вероятно ще останете при пренаписването на по-голямата част от стека. Приложните програмни интерфейси (API) са различни и въпреки че има известна стандартизация около популярни езици като JavaScript, те са доста близки до собствените. Има много възможности за заключване.

За да разбера привлекателността на безсървърните опции, прекарах известно време в изграждането на няколко функции и размишляването около стековете. Не написах много код, но това беше смисълът. Прекарах повече време в щракване върху бутони и въвеждане в уеб формуляри, за да конфигурирам всичко. Спомняте ли си, когато конфигурирахме всичко с XML и след това с JSON? Сега попълваме уеб формуляр и облакът го прави вместо нас. Все пак трябва да мислите като програмист, за да разберете какво се случва зад кулисите и извън вашия контрол.

AWS Ламбда

AWS Lambda се разраства в слоя на обвивката за целия облак на Amazon. Това е основна система, която ви позволява да вграждате функции, които отговарят на събития, които могат да бъдат генерирани от почти всяка част от огромната облачна инфраструктура на Amazon. Ако нов файл се качи в S3, може да го накарате да задейства функция, която прави нещо интересно с него. Ако някакво видео се транскодира от Amazon Elastic Transcoder, може да имате функция Lambda, която чака да бъде задействана, когато приключи. Тези функции от своя страна могат да задействат други ламбда операции или може би просто да изпратят на някого актуализация.

Можете да пишете Lambda функции в JavaScript (Node.js), Python, Java, C # и Go. Като се има предвид, че тези езици могат да вграждат много други езици, е напълно възможно да стартирате друг код като Haskell, Lisp или дори C ++. (Вижте тази история за компилиране на наследения C ++ в библиотека, която да се използва с AWS Lambda.)

Писането на Lambda функции често се чувства много по-сложно, отколкото очаквате, защото Amazon предлага толкова много възможности за конфигуриране и оптимизиране. Макар че е технически вярно, че можете да напишете само няколко реда код и да постигнете страхотни неща, почувствах, че тогава трябваше да отделя повече време за конфигуриране на работата на кода. Голяма част от това се постига чрез попълване на формуляри в браузъра, вместо въвеждане в текстови файлове. Понякога се чувства, че току-що сме заменили текстов редактор за форма на браузър, но това е цената за запазване на цялата гъвкавост, която Amazon предоставя на потребителя на Lambda.

Някои от допълнителните стъпки се дължат на това, че Amazon излага повече опции на потребителя и очаква повече от писателя на функции за първи път. След като приключих с писането на функция в Google или Microsoft, можех да насоча браузъра си към правилния URL и да го тествам незабавно. Amazon ме накара да щракна, за да конфигурирам шлюза на API и да отворя дясната дупка в защитната стена.

В крайна сметка всичко това щракване добавя слой задържане, който прави работата малко по-лесна от започването с текстов файл. Когато създавах една функция, браузърът имаше предупреждение „Тази функция съдържа външни библиотеки.“ В дните на чистия възел това беше нещо, което просто се очакваше да знам, или щях да го науча, като погледнах съобщението за грешка, докато кръстосах пръсти и се надявах, че отговорът е там. Сега облакът се втурва на помощ.

Amazon има редица други опции, които са почти толкова „безсървърни“, колкото AWS Lambda, ако безсървърните средства ви освобождават от задълженията за управление на сървъра. Разполага с еластични инструменти като Amazon EC2 Auto Scaling и AWS Fargate, които въртят и изключват сървърите, и AWS Elastic Beanstalk, който взема качения от вас код, внедрява го в уеб сървъри и се справя с балансирането и мащабирането на товара. Разбира се, с много от тези инструменти за автоматизация вие все още сте отговорни за създаването на образа на сървъра.

Едно от най-полезните предложения е AWS Step Functions, нещо като инструмент за безграмовна диаграма за създаване на машини за състояние, за да моделира това, което софтуерните архитекти наричат ​​работен поток. Част от проблема е, че всички безсървърни функции трябва да бъдат изцяло без състояние, нещо, което работи, когато налагате доста основна бизнес логика, но това може да е малко кошмар, когато разхождате някой клиент през контролен списък или блок-схема. Постоянно излизате в базата данни, за да презаредите информацията за клиента. Функциите на стъпки залепват заедно функциите на ламбда със състоянието.

Google Cloud Functions и Firebase

Ако целта ви е да се отървете от неприятностите с конфигурирането на сървъри, Google Cloud има редица услуги, които предлагат различни количества свобода от неща като нужда от коренна парола или дори използване на команден ред изобщо.

Започвайки с Google App Engine през 2008 г., Google бавно добавя различни „безсървърни“ опции с различни комбинации от съобщения и прозрачност на данните. Един, наречен Google Cloud Pub / Sub, скрива опашката за съобщения от вас, така че всичко, което трябва да направите, е да напишете кода за производителя и потребителя на данни. Google Cloud Functions предлага изчисление, управлявано от събития, за много от основните продукти, включително някои от инструментите за маркиране и API. И тогава има Google Firebase, база данни за стероиди, която ви позволява да смесвате JavaScript код в слой за съхранение на данни, който доставя данните на вашия клиент.

От тях Firebase е най-интригуващият за мен. Някои предполагат, че базите данни са оригиналното приложение без сървър, абстрахирайки структурите от данни и задълженията за съхранение на диска, за да доставят цялата информация чрез TCP / IP порт. Firebase довежда тази абстракция до крайност, като добавя и JavaScript код и съобщения, за да направи почти всичко, което може да искате да направите с инфраструктурата от страна на сървъра, включително удостоверяване. Технически това е просто база данни, но тя може да се справи с голяма част от бизнес логиката и съобщенията за вашия стек. Наистина можете да се измъкнете с малко клиентски HTML, CSS, JavaScript и Firebase.

Може да се изкушите да наречете JavaScript слоевете на Firebase „съхранени процедури“, точно както Oracle, но това ще липсва по-голямата картина. Кодът на Firebase е написан на JavaScript, така че ще работи в локална версия на Node.js. Можете да вградите голяма част от бизнес логиката в този слой, защото светът на Node вече е изпълнен с библиотеки за обработка на този работен поток. Освен това ще се насладите на удоволствията от изоморфния код, който работи на клиента, сървъра и сега на базата данни.

Частта, която привлече вниманието ми, беше синхронизиращият слой, вграден във Firebase. Той ще синхронизира копия на обекти от базата данни в цялата мрежа. Номерът е, че можете да настроите вашето клиентско приложение като просто друг възел на базата данни, който се абонира за всички промени за съответните данни (и само за съответните данни). Ако данните се променят на едно място, те се променят навсякъде. Можете да избегнете всички неприятности при изпращането на съобщения и да се съсредоточите само върху записването на информацията във Firebase, защото Firebase ще я репликира там, където трябва.

Не е нужно да се фокусирате само върху Firebase. По-основните функции на Google Cloud са по-опростен подход за вграждане на персонализиран код в облака на Google. Понастоящем Cloud Functions е до голяма степен само опция за писане на Node.js код, който ще работи в предварително конфигурирана среда на Node. Докато останалата част от Google Cloud Platform поддържа голямо разнообразие от езици - от Java и C # до Go, Python и PHP, функциите в облака са строго ограничени до JavaScript и Node. Имаше намеци, че идват други езикови опции и не бих се изненадал, ако се появят скоро.

Google Cloud Functions не достига толкова дълбоко в Google Cloud, колкото AWS Lambda достига до AWS, поне на този етап. Когато се пооправих, разглеждайки изграждането на функция за взаимодействие с Google Docs, установих, че вероятно ще трябва да използвам REST API и да напиша кода в нещо, наречено Apps Script. С други думи, светът на Google Docs има свой собствен REST API, който е бил без сървъри много преди модата да бъде измислена.

Струва си да се отбележи, че Google App Engine продължава да работи силно. В началото то просто предлагаше да завърти приложения на Python, за да отговори на търсенето на всеки, който идва на уебсайта, но беше разширено през годините, за да се справи с много различни езикови изпълнения. След като обедините кода си в изпълним файл, App Engine обработва процеса на стартиране на достатъчно възли за обработка на трафика ви, мащабиране нагоре или надолу, докато вашите потребители изпращат заявки.

Продължава да има няколко препятствия, които да имате предвид. Както при облачните функции, вашият код трябва да бъде написан по относително без гражданство и трябва да завършва всяка заявка за ограничен период от време. Но App Engine не изхвърля всички скелета и не забравя всичко между заявките. App Engine беше голяма част от безсървърната революция и остава най-достъпният за онези, които държат крак назад в стария училищен метод за изграждане на собствен стек в Python, PHP, Java, C # или Go.

Функции на Microsoft Azure

Microsoft, разбира се, работи също толкова усърдно, колкото и останалите, за да се увери, че хората могат да правят всички тези умни неща без сървъри и с облака Azure. Компанията е създала свои собствени основни функции за жонглиране на събития - Azure Functions - и е изградила някои сложни инструменти, които са дори по-достъпни за полупрограмистите.

Най-голямото предимство, което може да има Microsoft, може да бъде колекцията от приложения на Office, бившите изпълними файлове на работния плот, които бавно, но сигурно мигрират в облака. Всъщност едно отчитане на облачните приходи постави Microsoft пред Amazon, отчасти като натрупа част от приходите си от Office в ефимерната рубрика „облак“.

Един от най-добрите примери от документацията на Azure Functions показва как може да се задейства облачна функция, когато някой запише електронна таблица в OneDrive. Изведнъж малките елфи в облака оживяват и правят неща с електронната таблица. Това непременно ще бъде божи дар за ИТ магазините, подкрепящи екипи, които обичат своите електронни таблици на Excel (или други документи на Office). Те могат да пишат Azure Functions, за да правят практически всичко. Често смятаме, че HTML и мрежата са единственият интерфейс към облака, но няма причина да не може да бъде чрез формати на документи като Microsoft Word или Excel.