Pokud vás někdy probudili ve 3 hodiny ráno, protože server pokazil, pochopíte přitažlivost módního slova jako „bez serveru“. Konfigurace strojů může trvat hodiny, dny nebo někdy i týdny a poté je nutné je neustále aktualizovat, aby opravily chyby a bezpečnostní díry. Tyto aktualizace obvykle přinášejí vlastní potíže, protože nové aktualizace způsobují nekompatibilitu, která nutí další aktualizace, nebo to vypadá ad infinitum.
Nekonečný řetězec bolestí hlavy při běhu serveru je jedním z důvodů, proč hlavní cloudové společnosti přijaly architekturu „bez serveru“. Vědí, že šéf zaslechl výmluvy - server to, server tam - příliš dlouho. Kdybychom se těchto serverů mohli jen zbavit, šéf si musí myslet.
Je to skvělý prodejní termín, jediným problémem je, že to není úplně pravda. Tyto aplikace jsou bez serverů stejným způsobem jako restaurace bez kuchyní. Pokud je v nabídce to, co chcete, a máte rádi, jak to kuchař připravuje, je skvělé sedět v restauraci. Ale pokud chcete jiné jídlo, chcete-li jiné koření, měli byste si pořídit vlastní kuchyň.
Amazon, Google a Microsoft jsou tři z větších společností, které bojují o hostování aplikací budoucnosti, které doufají, že budou zapsány do jejich API bez serveru a spravovány prostřednictvím jejich automatizační vrstvy. Pokud si platformy dělají, co chcete - a nové modely jsou docela obecné -, mohou to být nejjednodušší a nejrychlejší způsob, jak vytvořit vlastní webovou aplikaci jednorožec s jednobarevným objemem několika miliard dolarů. Píšete pouze rozhodující kousky logiky a platforma zpracovává všechny podrobnosti.
Funkce bez serveru se stávají lepidlem nebo skriptovacím jazykem, který spojuje všechny funkce cloudu. Mapovací nebo AI nástroje, které byly kdysi docela nezávislé, jsou nyní propojeny prostřednictvím funkcí bez serveru řízených událostmi. Nyní lze více vaší práce vyřešit pomocí požadavků, které se vlní a odrážejí se v různých rozích každého cloudu, spouštění a spouštění tokem událostí. Pokud chcete prozkoumat strojové učení a použít ho k analýze dat, jedním z nejrychlejších způsobů, jak to udělat, je vytvořit aplikaci bez serveru a začít odesílat události do rohu strojového učení cloudu.
Implicitním slibem je, že krájení všeho tenčího usnadňuje sdílení zdrojů v cloudu. V minulosti by všichni zběsile vytvářeli nové instance, například se serverem Ubuntu běžícím na jeho vlastním virtuálním stroji. Každý používal stejný operační systém a byl duplikován několikrát na stejné skutečné krabici, která předstírala, že je tucet nebo více virtuálních krabic Ubuntu. Operace bez serveru zabraňují celé této duplikaci, což cloudové výpočty dramaticky zlevňuje, zejména pro úlohy, které běží sporadicky a nikdy nezaseknou starou krabici ve vaší klimatizované serverovně.
Samozřejmě všechny tyto výhody mají skryté náklady. Pokud byste někdy chtěli opustit nebo přesunout svůj kód na jiný web, pravděpodobně vás zasekne přepis většiny zásobníku. Rozhraní API se liší a přestože kolem populárních jazyků, jako je JavaScript, existuje určitá standardizace, jsou docela podobné proprietárním. Existuje spousta příležitostí k uzamčení.
Abych pochopil přitažlivost možností bez serveru, strávil jsem nějaký čas sestavováním několika funkcí a procházením hromádek. Nenapsal jsem moc kódu, ale o to šlo. Strávil jsem více času klikáním na tlačítka a zadáváním do webových formulářů, abych vše nakonfiguroval. Pamatujete si, když jsme vše nakonfigurovali pomocí XML a poté JSON? Nyní vyplňujeme webový formulář a cloud to dělá za nás. Stále musíte myslet jako programátor, abyste pochopili, co se děje v zákulisí a mimo vaši kontrolu.
AWS Lambda
AWS Lambda roste do vrstvy shell skriptu pro celý cloud Amazonu. Je to základní systém, který vám umožní vložit funkce, které reagují na události, které mohou být generovány téměř jakoukoli částí rozsáhlé cloudové infrastruktury Amazon. Pokud je na S3 nahrán nový soubor, můžete jej nechat spustit funkci, která s ním udělá něco zajímavého. Pokud je některé video překódováno pomocí Amazon Elastic Transcoder, můžete mít funkci Lambda, která čeká na spuštění, až skončí. Tyto funkce zase mohou spouštět další operace Lambda nebo možná jen někomu poslat aktualizaci.
Funkce Lambda můžete psát v JavaScriptu (Node.js), Pythonu, Javě, C # a Go. Vzhledem k tomu, že tyto jazyky mohou obsahovat mnoho dalších jazyků, je docela možné spustit další kód, jako je Haskell, Lisp nebo dokonce C ++. (Podívejte se na tento příběh o kompilaci starších C ++ do knihovny pro použití s AWS Lambda.)
Psaní funkcí Lambda se často cítí mnohem složitější, než očekáváte, protože Amazon nabízí tolik možností konfigurace a optimalizace. I když je technicky pravda, že můžete napsat jen pár řádků kódu a dosáhnout skvělých věcí, měl jsem pocit, že jsem pak musel věnovat více času konfiguraci způsobu, jakým kód běží. Většiny toho lze dosáhnout vyplněním formulářů v prohlížeči místo psaní do textových souborů. Někdy se zdá, že jsme právě vyměnili textový editor za formulář prohlížeče, ale to je cena za zachování veškeré flexibility, kterou Amazon rozšiřuje na uživatele Lambda.
Některé z dalších kroků jsou způsobeny tím, že Amazon vystavuje uživateli více možností a očekává více od prvního spisovatele funkcí. Jakmile jsem dokončil psaní funkce na Googlu nebo Microsoftu, mohl jsem svůj prohlížeč nasměrovat na správnou adresu URL a okamžitě ji otestovat. Amazon mě nechal kliknout, abych nakonfiguroval bránu API a otevřel správnou díru ve firewallu.
Nakonec toto kliknutí přidá vrstvu držení, díky níž je práce o něco jednodušší než začít s textovým souborem. Když jsem vytvářel jednu funkci, prohlížeč měl varování: „Tato funkce obsahuje externí knihovny.“ V dobách čistého uzlu to bylo něco, od čeho bych se měl jen dozvědět, nebo bych se to naučil Googlováním chybové zprávy, zatímco mi přejížděl prsty a doufal, že odpověď bude venku. Nyní se mrak vrhá na pomoc.
Amazon má řadu dalších možností, které jsou téměř stejně „bez serveru“ jako AWS Lambda, pokud vás bez serveru znamená zbavit se práce se správou serveru. Má elastické nástroje, jako je Amazon EC2 Auto Scaling a AWS Fargate, které roztočí a vypnou servery, a AWS Elastic Beanstalk, který převezme váš nahraný kód, nasadí jej na webové servery a zvládne vyvažování zátěže a škálování. Samozřejmě s mnoha z těchto automatizačních nástrojů jste stále zodpovědní za vytvoření image serveru.
Jednou z užitečnějších nabídek je AWS Step Functions, jakýsi nástroj pro vývojový diagram bez kódu pro vytváření stavových strojů pro modelování toho, co softwaroví architekti nazývají workflow. Část problému spočívá v tom, že všechny funkce bez serveru mají být zcela bez stavu, něco, co funguje, když vynucujete docela základní obchodní logiku, ale to může být trochu noční můra, když procházíte nějakým klientem kontrolní seznam nebo vývojový diagram. Neustále chodíte do databáze a znovu načítáte informace o klientovi. Krokové funkce lepí dohromady Lambda funkce se stavem.
Google Cloud Functions a Firebase
Pokud je vaším cílem zbavit se potíží s konfigurací serverů, Google Cloud má řadu služeb, které nabízejí různé úrovně svobody od věcí, jako je potřeba hesla root nebo dokonce vůbec použití příkazového řádku.
Počínaje aplikací Google App Engine v roce 2008 Google pomalu přidává různé možnosti „bez serveru“ s různými kombinacemi zpráv a transparentnosti dat. Jeden s názvem Google Cloud Pub / Sub před vámi skrývá frontu zpráv, takže stačí napsat kód pro producenta dat a spotřebitele. Google Cloud Functions nabízí výpočty založené na událostech pro mnoho hlavních produktů, včetně některých nástrojů a rozhraní API. A pak je tu Google Firebase, databáze steroidů, která vám umožní mixovat JavaScriptový kód do vrstvy pro ukládání dat, která poskytuje data vašemu klientovi.
Z nich je pro mě Firebase nejzajímavější. Někteří naznačují, že databáze byly původní aplikací bez serveru, která oddělovala datové struktury a práce na diskových úložištích a poskytovala všechny informace prostřednictvím portu TCP / IP. Firebase bere tuto abstrakci do extrému také přidáním kódu JavaScriptu a zasílání zpráv, takže můžete dělat téměř vše, co byste chtěli dělat s infrastrukturou na straně serveru, včetně ověřování. Technicky jde pouze o databázi, ale dokáže zpracovat většinu obchodní logiky a zasílání zpráv pro váš zásobník. Opravdu se můžete dostat pryč s trochou klientských HTML, CSS, JavaScript a Firebase.
Možná vás bude lákat nazývat vrstvy JavaScriptu Firebase „uloženými procedurami“, stejně jako to udělala společnost Oracle, ale to by chybělo v širším kontextu. Kód Firebase je napsán v JavaScriptu, takže se bude spouštět v místní verzi Node.js. Do této vrstvy můžete vložit většinu obchodní logiky, protože svět Node je již naplněn knihovnami pro zpracování tohoto pracovního toku. Navíc si budete užívat potěšení z izomorfního kódu, který běží na klientovi, serveru a nyní v databázi.
Část, která mě zaujala, byla synchronizační vrstva zabudovaná do Firebase. Bude synchronizovat kopie objektů z databáze v celé síti. Trik spočívá v tom, že můžete klientskou aplikaci nastavit jako jen další databázový uzel, který se přihlásí k odběru všech změn pro relevantní data (a pouze relevantní data). Pokud se data změní na jednom místě, změní se všude. Můžete se vyhnout všem potížím se zasíláním zpráv a soustředit se pouze na psaní informací do Firebase, protože Firebase je bude replikovat tam, kde je to nutné.
Nemusíte se soustředit jen na Firebase. Základní funkce Google Cloud Functions jsou jednodušší přístup k vkládání přizpůsobeného kódu do celého cloudu Google. V tuto chvíli jsou cloudové funkce do značné míry jen možností pro psaní kódu Node.js, který bude spuštěn v předkonfigurovaném prostředí Node. Zatímco zbytek platformy Google Cloud Platform podporuje širokou škálu jazyků - od prostředí Java a C # po Go, Python a PHP - funkce cloudu jsou přísně omezeny na JavaScript a uzel. Objevily se náznaky, že přicházejí další jazykové možnosti, a nebyl bych překvapen, kdyby se brzy objevily.
Google Cloud Functions nedosahuje tak hluboko do Google Cloud, jak AWS Lambda dosahuje do AWS, alespoň v tomto okamžiku. Když jsem se rozhlédl po pohledu na budování funkce pro interakci s Dokumenty Google, zjistil jsem, že bych pravděpodobně musel použít REST API a napsat kód do něčeho, co se jmenuje Apps Script. Jinými slovy, svět Dokumentů Google má své vlastní REST API, které bylo bez serveru dlouho před vytvořením módního slova.
Stojí za zmínku, že Google App Engine je stále silný. Na začátku to jen nabídlo roztočení aplikací v Pythonu, aby uspokojilo poptávku každého, kdo přijde na web, ale v průběhu let byl rozšířen, aby zvládl mnoho různých jazykových modulů. Jakmile svůj kód seskupíte do spustitelného souboru, App Engine zpracovává proces spouštění dostatečného počtu uzlů pro zpracování vašeho provozu, škálování nahoru nebo dolů, jak vaši uživatelé odesílají žádosti.
Stále je třeba mít na paměti několik překážek. Stejně jako u cloudových funkcí musí být váš kód napsán relativně bezstavovým způsobem a musí každou žádost dokončit v omezeném čase. Ale App Engine neodkládá všechna lešení ani nezapomíná na všechno mezi požadavky. App Engine byl velkou součástí revoluce bez serveru a zůstává nejdostupnější pro ty, kteří drží jednu nohu zpět ve staré školní metodě budování vlastního zásobníku v Pythonu, PHP, Javě, C # nebo Go.
Funkce Microsoft Azure
Microsoft samozřejmě pracuje stejně tvrdě jako ostatní, aby zajistil, že lidé mohou všechny tyto chytré věci bez serveru dělat i s cloudem Azure. Společnost vytvořila své vlastní základní funkce pro žonglování s událostmi - funkce Azure Functions - a vytvořila několik sofistikovaných nástrojů, které jsou pro programátory ještě přístupnější.
Největší výhodou, kterou Microsoft může mít, může být jeho sbírka aplikací Office, bývalých spustitelných souborů pro stolní počítače, které pomalu, ale jistě migrují do cloudu. Jedno účtování výnosů z cloudu skutečně dalo společnosti Microsoft náskok před Amazonem, zčásti tím, že některé z jejích výnosů z Office přidal do pomíjivé rubriky „cloud“.
Jeden z nejlepších příkladů z dokumentace Azure Functions ukazuje, jak lze spustit cloudovou funkci, když někdo uloží tabulku na OneDrive. Najednou ožívají malí elfové v oblaku a dělají věci do tabulky. Určitě to bude dar z nebes pro IT obchody podporující týmy, které milují své tabulky Excel (nebo jiné dokumenty Office). Mohou psát Azure Functions a dělat prakticky cokoli. Často si myslíme, že HTML a web jsou jediným rozhraním cloudu, ale není důvod, proč to nemůže být ve formátech dokumentů, jako jsou Microsoft Word nebo Excel.
