Chociaż technologie serverless szybko zyskały popularność w ostatnich latach, nadal istnieje wiele nieporozumień i obaw z nimi związanych. Zależność od dostawcy, narzędzia, zarządzanie kosztami, zimny start, monitorowanie i cykl rozwojowy to gorące tematy, jeśli chodzi o technologie bezserwerowe. W tym artykule omówimy niektóre z wymienionych tematów, a także udostępnimy wskazówki i łącza do przydatnych źródeł informacji, aby pomóc początkującym w tworzeniu wydajnych, elastycznych i ekonomicznych aplikacji bezserwerowych.
Błędne przekonania na temat technologii bezserwerowych
Wiele osób uważa, że przetwarzanie bezserwerowe i bezserwerowe (, FaaS) to prawie to samo. Oznacza to, że różnica nie jest zbyt duża i warto wprowadzić nowość. Chociaż AWS Lambda była jedną z gwiazd rozkwitu serverless i jednym z najpopularniejszych elementów architektury serverless, to jednak ta architektura to znacznie więcej niż FaaS.
Podstawową zasadą technologii bezserwerowych jest to, że nie musisz martwić się o zarządzanie i skalowanie swojej infrastruktury, płacisz tylko za to, czego używasz. Wiele usług spełnia te kryteria - AWS DynamoDB, S3, SNS lub SQS, Graphcool, Auth0, Now, Netlify, Firebase i wiele innych. Ogólnie rzecz biorąc, serverless oznacza wykorzystanie pełnej mocy chmury obliczeniowej bez konieczności zarządzania infrastrukturą i optymalizowania jej pod kątem skalowania. Oznacza to również, że bezpieczeństwo na poziomie infrastruktury nie jest już twoim zmartwieniem, co jest ogromną korzyścią, biorąc pod uwagę trudność i złożoność spełnienia standardów bezpieczeństwa. Wreszcie, nie musisz kupować dostarczonej infrastruktury.
Serverless można uznać za „stan umysłu”: pewną mentalność przy projektowaniu rozwiązań. Unikaj podejść, które wymagają konserwacji jakiejkolwiek infrastruktury. Dzięki podejściu bezserwerowemu poświęcamy czas na rozwiązywanie zadań, które bezpośrednio wpływają na projekt i przynoszą korzyści naszym użytkownikom: tworzymy zrównoważoną logikę biznesową, opracowujemy interfejsy użytkownika oraz opracowujemy adaptacyjne i niezawodne interfejsy API.
Na przykład, jeśli możliwe jest uniknięcie zarządzania i utrzymywania platformy wyszukiwania swobodnego tekstu, to właśnie to zrobimy. Takie podejście do tworzenia aplikacji może znacznie przyspieszyć wprowadzanie ich na rynek, ponieważ nie trzeba już myśleć o zarządzaniu złożoną infrastrukturą. Wyeliminuj obowiązki i koszty zarządzania infrastrukturą i skup się na tworzeniu aplikacji i usług, których potrzebują Twoi klienci. Patrick Debois nazwał to podejście , termin ten został przyjęty w społeczności bezserwerowej. Funkcje powinny być traktowane jako łącza do usług jako moduły do wdrożenia (zamiast wdrażania całej biblioteki lub aplikacji internetowej). Zapewnia to niesamowitą szczegółowość zarządzania wdrażaniem i zmianami w aplikacji. Jeśli nie możesz wdrożyć funkcji w ten sposób, może to oznaczać, że funkcje wykonują zbyt wiele zadań i wymagają refaktoryzacji.
Niektórzy są zdezorientowani zależnością od dostawcy podczas opracowywania aplikacji w chmurze. To samo dotyczy technologii bezserwerowych i nie jest to błędne przekonanie. Z naszego doświadczenia wynika, że budowanie aplikacji bezserwerowych w AWS w połączeniu ze zdolnością AWS Lambda do łączenia innych usług AWS jest częścią siły architektur bezserwerowych. To dobry przykład synergii, kiedy wynik połączenia jest czymś więcej niż tylko sumą warunków. Próba uniknięcia zależności od dostawcy może napotkać jeszcze więcej problemów. Podczas pracy z kontenerami łatwiej jest zarządzać własną warstwą abstrakcji między dostawcami chmury. Ale jeśli chodzi o rozwiązania bezserwerowe, wysiłek się nie opłaci, zwłaszcza jeśli od samego początku weźmie się pod uwagę opłacalność. Pamiętaj, aby dowiedzieć się, w jaki sposób dostawcy świadczą usługi. Niektóre wyspecjalizowane usługi opierają się na punktach integracji z innymi dostawcami i mogą zapewniać natychmiastową łączność plug-and-play. Łatwiej jest dostarczyć wywołanie Lambda z punktu końcowego interfejsu API bramy niż przekazać żądanie do jakiegoś kontenera lub instancji EC2. Graphcool zapewnia łatwą konfigurację za pomocą Auth0, co jest łatwiejsze niż przy użyciu narzędzi uwierzytelniających innych firm.
Wybór odpowiedniego dostawcy aplikacji bezserwerowej to decyzja dotycząca architektury. Tworząc aplikację, nie spodziewasz się, że pewnego dnia wrócisz do zarządzania serwerami. Wybór dostawcy chmury nie różni się niczym od wyboru kontenerów, bazy danych czy nawet języka programowania.
Rozważać:
- Jakich usług potrzebujesz i dlaczego.
- Jakie usługi zapewniają dostawcy chmury i jak możesz je połączyć z wybranym rozwiązaniem FaaS.
- Jakie języki programowania są obsługiwane (z dynamicznym lub statycznym typowaniem, kompilowane lub interpretowane, jakie są testy porównawcze, jaka jest wydajność przy zimnym starcie, jaki jest ekosystem open source itp.).
- Jakie są Twoje wymagania dotyczące bezpieczeństwa (SLA, 2FA, OAuth, HTTPS, SSL itp.).
- Jak zarządzać cyklami CI/CD i tworzenia oprogramowania.
- Które rozwiązania infrastruktury jako kodu możesz wykorzystać.
Jeśli rozszerzysz istniejącą aplikację i stopniowo dodasz funkcjonalność bezserwerową, może to nieco ograniczyć dostępne możliwości. Jednak prawie wszystkie technologie bezserwerowe zapewniają pewnego rodzaju API (poprzez REST lub kolejki komunikatów), które pozwala tworzyć rozszerzenia niezależne od rdzenia aplikacji i z łatwą integracją. Szukaj usług z przejrzystymi interfejsami API, dobrą dokumentacją i silną społecznością, a nie możesz się pomylić. Łatwość integracji często może być kluczowym wskaźnikiem i jest prawdopodobnie jednym z głównych powodów, dla których AWS odniósł taki sukces od czasu wydania Lambdy w 2015 roku.
Kiedy Serverless jest dobry
Technologie bezserwerowe można zastosować niemal wszędzie. Jednak ich zalety nie ograniczają się tylko do jednego sposobu aplikacji. Bariera wejścia na rynek przetwarzania w chmurze jest dziś tak niska dzięki technologiom bezserwerowym. Jeśli programiści mają pomysł, ale nie wiedzą, jak zarządzać infrastrukturą chmurową i optymalizować koszty, to nie muszą szukać jakiegoś inżyniera, który to zrobi. Jeśli startup chce zbudować platformę, ale obawia się, że koszty mogą wymknąć się spod kontroli, może łatwo przejść na rozwiązania bezserwerowe.
Ze względu na oszczędności kosztów i łatwość skalowania, rozwiązania bezserwerowe mają takie samo zastosowanie zarówno w systemach wewnętrznych, jak i zewnętrznych, aż po aplikację internetową z wielomilionową publicznością. Rachunki są mierzone nie w euro, ale w centach. Wypożyczenie najprostszej instancji AWS EC2 (t1.micro) na miesiąc kosztuje 15 €, nawet jeśli nic z nią nie robisz (kto nigdy nie zapomniał jej wyłączyć?!). Dla porównania, aby osiągnąć ten poziom wydatków w tym samym okresie, musiałbyś uruchomić 512 MB Lambda na 1 sekundę około 3 milionów razy. A jeśli nie korzystasz z tej funkcji, nic nie płacisz.
Ponieważ bezserwerowe jest przede wszystkim sterowane zdarzeniami, dość łatwo jest dodać infrastrukturę bezserwerową do starszych systemów. Na przykład, korzystając z AWS S3, Lambda i Kinesis, możesz utworzyć usługę analityczną dla starego systemu sprzedaży detalicznej, który może odbierać dane za pośrednictwem interfejsu API.
Większość platform bezserwerowych obsługuje wiele języków. Najczęściej jest to Python, JavaScript, C#, Java i Go. Zwykle nie ma ograniczeń w korzystaniu z bibliotek we wszystkich językach, więc możesz korzystać z ulubionych bibliotek open source. Jednak wskazane jest, aby nie nadużywać zależności, aby Twoje funkcje działały optymalnie i nie negowały korzyści płynących z ogromnej skalowalności Twoich aplikacji serverless. Im więcej paczek trzeba załadować do kontenera, tym dłużej będzie trwał zimny start.
Zimny start ma miejsce, gdy najpierw trzeba zainicjować kontener, środowisko uruchomieniowe i procedurę obsługi błędów przed ich użyciem. Z tego powodu opóźnienie w wykonaniu funkcji może sięgać nawet 3 sekund, a to nie jest najlepsza opcja dla niecierpliwych użytkowników. Jednak zimne starty zdarzają się przy pierwszym wezwaniu po kilku minutach bezczynności. Tak wielu uważa to za drobną irytację, którą można obejść, regularnie pingując funkcję, aby utrzymać ją w stanie bezczynności. Lub całkowicie ignorują ten aspekt.
Chociaż AWS wydanyJednak bazy danych SQL nie są idealne dla tej aplikacji, ponieważ są zależne od połączeń do wykonywania transakcji, co może szybko stać się wąskim gardłem przy dużym ruchu na AWS Lambda. Tak, programiści stale ulepszają Serverless Aurora i powinieneś z nią eksperymentować, ale dzisiaj rozwiązania NoSQL takie jak. Nie ulega jednak wątpliwości, że ta sytuacja bardzo szybko ulegnie zmianie.
Zestaw narzędzi nakłada również wiele ograniczeń, szczególnie w zakresie testów lokalnych. Chociaż istnieją rozwiązania takie jak Docker-Lambda, DynamoDB Local i LocalStack, wymagają one ciężkiej pracy i znacznej ilości konfiguracji. Jednak wszystkie te projekty są aktywnie rozwijane, więc to tylko kwestia czasu, zanim zestaw narzędzi osiągnie potrzebny nam poziom.
Wpływ technologii serverless na cykl rozwojowy
Ponieważ Twoja infrastruktura to tylko konfiguracja, możesz definiować i wdrażać kod za pomocą skryptów, takich jak skrypty powłoki. Lub możesz skorzystać z rozwiązań klasy konfiguracji jako kodu, takich jak . Chociaż ta usługa nie zapewnia konfiguracji dla wszystkich obszarów, umożliwia zdefiniowanie określonych zasobów do wykorzystania jako funkcje Lambda. Oznacza to, że tam, gdzie zawiedzie CloudFormation, możesz napisać własny zasób (funkcja Lambda), który wypełni tę lukę. W ten sposób możesz zrobić wszystko, nawet skonfigurować zależności poza środowiskiem AWS.
Ponieważ to wszystko to tylko konfiguracja, możesz dostosować skrypty wdrożeniowe do określonych środowisk, regionów i użytkowników, zwłaszcza jeśli korzystasz z rozwiązań infrastruktury jako kodu, takich jak CloudFormation. Na przykład możesz wdrożyć kopię infrastruktury dla każdej gałęzi w repozytorium, aby móc przetestować je całkowicie w izolacji podczas opracowywania. To drastycznie przyspiesza przesyłanie informacji zwrotnych dla programistów, gdy chcą zrozumieć, czy ich kod działa odpowiednio w środowisku na żywo. Menedżerowie nie muszą martwić się kosztami wdrażania wielu środowisk, ponieważ płacą tylko za faktyczne wykorzystanie.
DevOps mają mniej zmartwień, ponieważ muszą tylko upewnić się, że programiści mają poprawną konfigurację. Nie musisz już zarządzać instancjami, modułami równoważącymi ani grupami zabezpieczeń. Dlatego coraz częściej używa się terminu NoOps, choć nadal ważna jest umiejętność konfigurowania infrastruktury, zwłaszcza jeśli chodzi o konfigurację IAM i optymalizację zasobów chmury.
Istnieją bardzo wydajne narzędzia do monitorowania i wizualizacji, takie jak Epsagon, Thundra, Dashbird i IOPipe. Umożliwiają monitorowanie bieżącego stanu aplikacji bezserwerowych, rejestrowanie i śledzenie, przechwytywanie wskaźników wydajności i wąskich gardeł w architekturze, przeprowadzanie analiz i prognoz kosztów oraz nie tylko. Dają one nie tylko inżynierom DevOps, programistom i architektom kompleksowy wgląd w wydajność aplikacji, ale także pozwalają menedżerom monitorować sytuację w czasie rzeczywistym, z kosztami zasobów na sekundę i prognozowaniem kosztów. Znacznie trudniej jest to zorganizować przy zarządzanej infrastrukturze.
Projektowanie aplikacji bezserwerowych jest znacznie łatwiejsze, ponieważ nie trzeba wdrażać serwerów sieciowych, zarządzać maszynami wirtualnymi lub kontenerami, serwerami poprawek, systemami operacyjnymi, bramami internetowymi itp. Abstrahując wszystkie te obowiązki, architektura bezserwerowa może skupić się na rdzeniu — rozwiązanie potrzeby biznesowe i klientów.
Chociaż zestaw narzędzi mógłby być lepszy (z każdym dniem jest coraz lepszy), programiści mogą skupić się na implementacji logiki biznesowej i jak najlepszym rozłożeniu złożoności aplikacji na różne usługi w ramach architektury. Bezserwerowe zarządzanie aplikacjami jest oparte na zdarzeniach i abstrakcyjne przez dostawcę chmury (np. zdarzenia SQS, S3 lub strumienie DynamoDB). Dlatego programiści muszą tylko napisać logikę biznesową, aby reagować na określone zdarzenia i nie muszą się martwić, jak najlepiej zaimplementować bazy danych i kolejki komunikatów, ani jak zorganizować optymalną pracę z danymi w określonych magazynach sprzętowych.
Kod można uruchamiać i debugować lokalnie, tak jak w przypadku każdego procesu programowania. Testy jednostkowe pozostają takie same. Możliwość wdrożenia całej infrastruktury aplikacji z niestandardową konfiguracją stosu pozwala programistom szybko uzyskać ważne informacje zwrotne bez myślenia o kosztach testowania lub wpływie na drogie środowiska zarządzane.
Narzędzia i techniki budowania aplikacji bezserwerowych
Nie ma określonego sposobu tworzenia aplikacji bezserwerowych. Jak również zestaw usług do tego zadania. AWS jest dziś liderem wśród potężnych rozwiązań serverless, ale spójrz też na , и . Jeśli używasz AWS, zalecanym podejściem do zbierania aplikacji jest (SAM), zwłaszcza w przypadku korzystania z języka C#, ponieważ program Visual Studio ma doskonałe narzędzia. SAM CLI może zrobić wszystko, co potrafi Visual Studio, więc nic nie stracisz, jeśli przełączysz się na inne IDE lub edytor tekstu. Oczywiście SAM współpracuje również z innymi językami.
Jeśli piszesz w innych językach, Serverless Framework to doskonałe narzędzie typu open source, które pozwala skonfigurować wszystko za pomocą bardzo wydajnych plików konfiguracyjnych YAML. Serverless Framework obsługuje również różne usługi w chmurze, dlatego polecamy je tym, którzy szukają rozwiązania wielochmurowego. Ma ogromną społeczność, która stworzyła wiele wtyczek na każdą potrzebę.
Do testowania lokalnego dobrze nadają się narzędzia open source Docker-Lambda, Serverless Local, DynamoDB Local i LocalStack. Technologie bezserwerowe są wciąż na wczesnym etapie rozwoju, podobnie jak narzędzia do nich, więc podczas konfigurowania złożonych scenariuszy testowych będziesz musiał ciężko pracować. Jednak samo wdrożenie stosu w środowisku i przetestowanie go jest niewiarygodnie tanie. I nie musisz tworzyć dokładnej lokalnej kopii środowisk chmurowych.
Użyj AWS Lambda Layers, aby zmniejszyć rozmiar wdrożonych pakietów i przyspieszyć pobieranie.
Używaj odpowiednich języków programowania do konkretnych zadań. Różne języki mają swoje zalety i wady. Istnieje wiele testów porównawczych, ale JavaScript, Python i C# (.NET Core 2.1+) są liderami pod względem wydajności AWS Lambda. AWS Lambda niedawno wprowadziła Runtime API, które pozwala określić żądany język i środowisko wykonawcze, więc eksperymentuj.
Zachowaj małe rozmiary pakietów do wdrożenia. Im są mniejsze, tym szybciej się ładują. Unikaj używania dużych bibliotek, zwłaszcza jeśli korzystasz z kilku funkcji z nich. Jeśli programujesz w JavaScript, użyj narzędzia do budowania, takiego jak Webpack, aby zoptymalizować swoją kompilację i dołączyć tylko to, czego naprawdę potrzebujesz. .NET Core 3.0 ma QuickJit i Tiered Compilation, które poprawiają wydajność i bardzo pomagają przy zimnych startach.
Zależność funkcji bezserwerowych od zdarzeń może początkowo utrudniać koordynację logiki biznesowej. Pod tym względem kolejki komunikatów i maszyny stanowe mogą być niezwykle przydatne. Funkcje lambda mogą wywoływać się nawzajem, ale rób to tylko wtedy, gdy nie oczekujesz odpowiedzi („odpal i zapomnij”) — nie chcesz płacić za czekanie na zakończenie innej funkcji. Kolejki komunikatów są przydatne do izolowania części logiki biznesowej, zarządzania wąskimi gardłami aplikacji i przetwarzania transakcji (przy użyciu kolejek FIFO). Funkcje AWS Lambda można przypisać do kolejek SQS jako zablokowanych kolejek komunikatów, które śledzą komunikaty zakończone niepowodzeniem do późniejszej analizy. Funkcje krokowe AWS (maszyny stanowe) są bardzo przydatne do zarządzania złożonymi procesami, które wymagają łączenia funkcji w łańcuchy. Zamiast funkcji Lambda wywołującej inną funkcję, funkcje krokowe mogą koordynować przejścia między stanami, przekazywać dane między funkcjami i zarządzać globalnym stanem funkcji. Pozwala to na zdefiniowanie warunków ponawiania prób lub tego, co zrobić, gdy wystąpi określony błąd - bardzo potężne narzędzie w określonych warunkach.
wniosek
W ostatnich latach technologie serverless rozwijają się w niespotykanym dotąd tempie. Z tą zmianą paradygmatu wiążą się pewne nieporozumienia. Dzięki abstrakcji infrastruktury i skalowaniu zarządzania rozwiązania bezserwerowe oferują znaczne korzyści, od uproszczenia procesów programistycznych i DevOps po ogromne redukcje kosztów operacyjnych.
Chociaż podejście bezserwerowe nie jest pozbawione wad, istnieją solidne wzorce projektowe, które można wykorzystać do tworzenia niezawodnych aplikacji bezserwerowych lub integrowania elementów bezserwerowych z istniejącymi architekturami.
Źródło: www.habr.com