Choć technologie serverless w ostatnich latach szybko zyskują na popularności, to wciąż wiąże się z nimi wiele mitów i obaw. Zależność od dostawcy, narzędzia, zarządzanie kosztami, zimny start, monitoring i cykl życia rozwoju — to wszystko tematy często poruszane przy omawianiu technologii serverless. W tym artykule przyjrzymy się niektórym z wymienionych tematów oraz podzielimy się wskazówkami i linkami do użytecznych źródeł informacji, które pomogą nowicjuszom w stworzeniu potężnych, elastycznych i ekonomicznych aplikacji serverless.
Mity dotyczące technologii serverless
Wielu ludzi uważa, że serverless i przetwarzanie danych poza serwerem (, FaaS) to niemal to samo. Oznacza to, że różnica nie jest zbyt duża i warto wdrożyć nowość. Chociaż AWS Lambda była jednym z „gwiazd” rozkwitu technologii serverless i jednym z najpopularniejszych elementów architektury serverless, to ta architektura to coś więcej niż FaaS.
Podstawowa zasada technologii serverless polega na tym, że nie musisz martwić się o zarządzanie i skalowanie infrastruktury; płacisz tylko za to, co wykorzystujesz. Wiele usług spełnia te kryteria — AWS DynamoDB, S3, SNS czy SQS, Graphcool, Auth0, Now, Netlify, Firebase i wiele innych. Generalnie serverless oznacza korzystanie ze wszystkich możliwości obliczeń w chmurze bez potrzeby zarządzania infrastrukturą i jej optymalizacji w celu skalowania. Oznacza to również, że bezpieczeństwo na poziomie infrastruktury przestaje być twoim problemem, co jest ogromną zaletą, biorąc pod uwagę trudności i złożoność przestrzegania standardów bezpieczeństwa. Wreszcie, nie musisz kupować infrastruktury, która jest ci udostępniana.
Serverless można uznać za „stan umysłu”: określoną mentalność w projektowaniu rozwiązań. Unikaj podejść, które wymagają utrzymania jakiejkolwiek infrastruktury. Podejście serverless pozwala nam skupić się na zadaniach, które mają bezpośredni wpływ na projekt i przynoszą korzyści naszym użytkownikom: tworzymy solidną logikę biznesową, rozwijamy interfejsy użytkownika oraz opracowujemy elastyczne i niezawodne API.
Na przykład, jeśli można uniknąć zarządzania i wsparcia platformy wyszukiwania pełnotekstowego, tak właśnie zrobimy. Takie podejście do budowania aplikacji może znacznie przyspieszyć wprowadzenie produktu na rynek, ponieważ nie trzeba już myśleć o zarządzaniu skomplikowaną infrastrukturą. Uwolnij się od obowiązków i kosztów związanych z zarządzaniem infrastrukturą i skup się na tworzeniu aplikacji i usług, które są potrzebne Twoim klientom. Patrick Debois nazwał to podejście , ten termin jest przyjęty w społeczności serverless. Funkcje powinny być postrzegane jako pomost dla usług w postaci wdrażanych modułów (zamiast wdrażania całej biblioteki lub aplikacji internetowej). Zapewnia to niesamowitą granularność zarządzania wdrożeniami i zmianami w aplikacji. Jeśli nie możesz w ten sposób wdrażać funkcji, może to sugerować, że funkcje wykonują zbyt wiele zadań i powinny zostać zrefaktoryzowane.
Niektórych niepokoi zależność od dostawcy podczas tworzenia aplikacji w chmurze. Podobnie jest w przypadku technologii serverless, i mało prawdopodobne, że jest to wynik błędnego przekonania. Z naszych doświadczeń wynika, że tworzenie aplikacji serverless na AWS w połączeniu z możliwością AWS Lambda integracji z innymi usługami AWS to częściowo to, co tworzy zalety architektur serverless. To dobry przykład synergii, gdzie efekt z połączenia jest większy niż suma składników. Starając się unikać zależności od dostawcy, można napotkać jeszcze większe problemy. Pracując z kontenerami, łatwiej jest zarządzać własnym poziomem abstrakcji między dostawcami chmury. Ale w przypadku rozwiązań serverless wysiłki nie będą się opłacać, szczególnie jeśli od samego początku uwzględnia się opłacalność. Ważne jest, aby dowiedzieć się, jak dostawcy zapewniają świadczenie usług. Niektóre specjalistyczne usługi zależą od punktów integracji z innymi dostawcami i mogą z pudełka oferować możliwość podłączenia w stylu plug-and-play. Łatwiej jest wywołać Lambdę z końcowego punktu API gateway niż zarejestrować żądanie do jakiegoś kontenera lub instancji EC2. Graphcool zapewnia prostą konfigurację za pomocą Auth0, co jest prostsze niż użycie zewnętrznych środków autoryzacji.
Wybór odpowiedniego dostawcy dla Twojej aplikacji serverless to decyzja na poziomie architektury. Tworząc aplikację, nie zakładasz, że kiedykolwiek wrócisz do zarządzania serwerami. Wybór dostawcy chmurowego nie różni się od wyboru używania kontenerów, baz danych, czy nawet języka programowania.
Przemyśl:
- Jakie usługi są Ci potrzebne i dlaczego.
- Jakie usługi oferują dostawcy chmur i jak można je zintegrować za pomocą wybranego rozwiązania FaaS.
- Jakie języki programowania są wspierane (z dynamicznym lub statycznym typowaniem, kompilowane lub interpretowane, jakie są benchmarki, jaka wydajność przy zimnym starcie, jaka jest ekosystem open source itp.).
- Jakie są Twoje wymagania dotyczące bezpieczeństwa (SLA, 2FA, OAuth, HTTPS, SSL itd.).
- Jak zarządzać swoim CI/CD i cyklami rozwoju oprogramowania.
- Z jakich rozwiązań klasy infrastructure-as-code możesz skorzystać.
Jeśli rozwijasz istniejącą aplikację i stopniowo dodajesz funkcje bezserwerowe, może to nieco ograniczyć dostępne możliwości. Jednak prawie wszystkie technologie bezserwerowe zapewniają jakieś API (przez REST lub kolejki komunikatów), które umożliwiają rozszerzanie niezależnie od rdzenia aplikacji i z łatwą integracją. Szukaj usług z zrozumiałymi API, dobrą dokumentacją i silną społecznością, a na pewno się nie pomylisz. Łatwość integracji często może być kluczową metryką i prawdopodobnie jest to jeden z głównych powodów sukcesu AWS od momentu wydania Lambda w 2015 roku.
Kiedy bezserwerowość jest przydatna
Technologie bezserwerowe można zastosować praktycznie wszędzie. Jednak ich zalety nie ograniczają się tylko do sposobów zastosowania. Próg wejścia do chmur obliczeniowych jest dzisiaj tak niski właśnie dzięki technologiom bezserwerowym. Jeśli deweloperzy mają pomysł, ale nie wiedzą, jak zarządzać infrastrukturą chmurową i optymalizować koszty, nie muszą szukać inżyniera do tego zadania. Jeśli start-up chce stworzyć platformę, ale obawia się, że koszty mogą wymknąć się spod kontroli, może w łatwy sposób skorzystać z rozwiązań bezserwerowych.
Dzięki oszczędnościom kosztów i łatwości skalowania, rozwiązania bezserwerowe są równie użyteczne zarówno dla systemów wewnętrznych, jak i zewnętrznych, aż po aplikacje internetowe z milionami użytkowników. Koszty mierzone są raczej nie w euro, lecz w centach. Wynajem najprostszej instancji AWS EC2 (t1.micro) na miesiąc kosztuje 15 €, nawet jeśli nic z nią nie robisz (kto nigdy nie zapomniał wyłączyć?!). Dla porównania, aby osiągnąć taki poziom kosztów w tym samym okresie, musisz uruchomić Lambda o rozmiarze 512 MB przez 1 sekundę około 3 miliony razy. A jeśli nie korzystasz z tej funkcji, to nic nie płacisz.
Ponieważ technologia bezserwerowa zależy głównie od zdarzeń, można stosunkowo łatwo dodać infrastrukturę bezserwerową do starych systemów. Na przykład, za pomocą AWS S3, Lambda i Kinesis możesz stworzyć serwis analityczny dla starego systemu detalicznego, który będzie odbierać dane przez API.
Większość platform serverless obsługuje różne języki. Najczęściej są to Python, JavaScript, C#, Java i Go. Zazwyczaj we wszystkich językach nie ma żadnych ograniczeń dotyczących użycia bibliotek, więc możesz korzystać z ulubionych bibliotek open source. Należy jednak unikać nadmiernego użycia zależności, aby Twoje funkcje działały optymalnie i nie traciły korzyści z ogromnej skalowalności aplikacji serverless. Im więcej pakietów trzeba załadować do kontenera, tym dłużej trwa cold start.
Cold start to sytuacja, gdy najpierw trzeba zainicjować kontener, środowisko wykonawcze i obsługę błędów, zanim zaczniesz z nich korzystać. Z tego powodu opóźnienie w wykonywaniu funkcji może wynosić do 3 sekund, co nie jest najlepszą opcją dla niecierpliwych użytkowników. Jednak cold starty występują przy pierwszym wywołaniu po kilku minutach bezczynności funkcji. Wiele osób uznaje to za niewielką niedogodność, którą można obejść, regularnie pingując funkcję, aby utrzymać ją w trybie gotowości. Albo w ogóle ignorują ten aspekt.
Chociaż AWS wprowadziło, to jednak bazy danych SQL nie są idealne do tego zastosowania, ponieważ podczas realizacji transakcji polegają na połączeniach, które mogą szybko stać się wąskim gardłem przy dużym ruchu w AWS Lambda. Tak, deweloperzy ciągle poprawiają Serverless Aurora i warto ją przetestować, jednak obecnie dla systemów serverless znacznie lepiej nadają się rozwiązania NoSQL, takie jak. Niemniej jednak, sytuacja ta z pewnością wkrótce się zmieni.
Narzędzia także nakładają wiele ograniczeń, szczególnie w obszarze lokalnego testowania. Chociaż istnieją rozwiązania takie jak Docker-Lambda, DynamoDB Local i LocalStack, to wymagają one żmudnej pracy i znacznej konfiguracji. Niemniej jednak, wszystkie te projekty są aktywnie rozwijane, więc to tylko kwestia czasu, kiedy narzędzia osiągną potrzebny nam poziom.
Wpływ technologii serverless na cykl rozwoju
Ponieważ Twoja infrastruktura jest po prostu konfiguracją, możesz wdrożyć kod za pomocą skryptów, na przykład, skryptów shell. Możesz również skorzystać z rozwiązań klasy configuration-as-code, takich jak . Chociaż ta usługa nie oferuje konfiguracji we wszystkich dziedzinach, pozwala na definiowanie konkretnych zasobów do użycia jako funkcje Lambda. To znaczy, tam, gdzie CloudFormation może zawieść, możesz napisać własny zasób (funkcję Lambda), który wypełni tę lukę. Dzięki temu możesz zrobić cokolwiek, nawet skonfigurować zależności poza swoim środowiskiem AWS.
Ponieważ wszystko to jest po prostu konfiguracją, możesz parametryzować swoje skrypty wdrażania pod konkretne środowiska, regiony i użytkowników, szczególnie jeśli stosujesz rozwiązania typu infrastructure-as-code, takie jak CloudFormation. Na przykład możesz wdrożyć kopię infrastruktury dla każdej gałęzi w repozytorium, aby całkowicie izolowanie je testować w trakcie rozwoju. To radykalnie przyspiesza uzyskiwanie informacji zwrotnej od programistów, gdy chcą zrozumieć, czy ich kod działa poprawnie w środowisku produkcyjnym. Kierownicy nie muszą martwić się o koszty wdrożenia licznych środowisk, ponieważ płacą tylko za rzeczywiste zużycie.
DevOps ma mniej zmartwień, ponieważ muszą jedynie upewnić się, że programiści mają poprawną konfigurację. Nie muszą już zarządzać instancjami, load balancerami czy grupami bezpieczeństwa. Dlatego coraz częściej używa się terminu NoOps, chociaż wciąż ważne jest, aby umieć skonfigurować infrastrukturę, zwłaszcza gdy mowa o konfiguracji IAM i optymalizacji zasobów w chmurze.
Istnieje wiele potężnych narzędzi do monitorowania i wizualizacji, takich jak Epsagon, Thundra, Dashbird i IOPipe. Umożliwiają one śledzenie bieżącego stanu aplikacji bezserwerowych, dostarczają logi i ślady, rejestrują metryki wydajności oraz wąskie gardła architektury, przeprowadzają analizy i prognozowanie wydatków oraz wiele więcej. Nie tylko dostarczają inżynierom DevOps, programistom i architektom wyczerpujący wgląd w działanie aplikacji, ale także pozwalają kierownikom śledzić sytuację w czasie rzeczywistym, z sekundenowymi kosztami na zasoby i prognozowaniem wydatków. Organizacja czegoś takiego w zarządzanej infrastrukturze jest znacznie trudniejsza.
Projektowanie aplikacji bezserwerowych jest znacznie prostsze, ponieważ nie musisz wdrażać serwerów internetowych, zarządzać maszynami wirtualnymi ani kontenerami, naprawiać serwerów, systemów operacyjnych, bram internetowych itp. Abstrakcja od wszystkich tych obowiązków pozwala architekturze bezserwerowej skupić się na najważniejszym – na spełnianiu potrzeb biznesowych i klientów.
Chociaż narzędzia mogłyby być lepsze (są ulepszane z dnia na dzień), programiści mogą skoncentrować się na wdrażaniu logiki biznesowej i optymalnym rozdzielaniu złożoności aplikacji pomiędzy różnymi usługami w ramach architektury. Zarządzanie aplikacjami bezserwerowymi odbywa się w oparciu o zdarzenia i jest abstrahowane przez dostawcę chmurowego (na przykład, SQS, zdarzenia S3 lub strumienie DynamoDB). Dlatego wystarczy, że programiści napiszą logikę biznesową, aby zareagować na określone zdarzenia, a nie muszą się martwić o to, jak najlepiej wdrożyć bazy danych i kolejki wiadomości, ani jak zorganizować optymalne operacje z danymi w określonych fizycznych magazynach.
Kod można wykonywać i debugować lokalnie, tak jak w każdym procesie rozwoju. Testowanie modułowe pozostaje takie samo. Możliwość wdrażania całej infrastruktury aplikacji za pomocą konfigurowalnej konfiguracji stosu pozwala programistom szybko uzyskać ważne opinie, nie martwiąc się o koszty testowania lub wpływ na drogie zarządzane środowiska.
Narzędzia i metody budowy aplikacji bezserwerowych
Nie ma konkretnego sposobu na budowę aplikacji bezserwerowych. Również zestawu usług do tego zadania. Liderem wśród zaawansowanych rozwiązań bezserwerowych obecnie jest AWS, jednak warto również zwrócić uwagę na , i . Jeśli korzystasz z AWS, to jako podejście do budowy aplikacji można zarekomendować (SAM), zwłaszcza przy użyciu C#, ponieważ w Visual Studio dostępne są świetne narzędzia. SAM CLI może robić to samo, co Visual Studio, więc nic nie stracisz, jeśli przejdziesz na inny IDE lub edytor tekstu. Oczywiście, SAM działa również z innymi językami.
Jeśli piszesz w innych językach, to Serverless Framework to doskonałe narzędzie open source, które pozwala na konfigurację czegokolwiek przy użyciu bardzo potężnych plików konfiguracyjnych YAML. Serverless Framework obsługuje także różne usługi chmurowe, więc polecamy je tym, którzy szukają rozwiązania wielochmurowego. Ma ogromną społeczność, która stworzyła mnóstwo wtyczek do wszelkich potrzeb.
Do testowania lokalnego idealnie nadają się narzędzia open source takie jak Docker-Lambda, Serverless Local, DynamoDB Local i LocalStack. Technologie bezserwerowe są jeszcze w wczesnej fazie rozwoju, podobnie jak narzędzia do nich, więc przy konfigurowaniu skomplikowanych scenariuszy testowych będziesz musiał się natrudzić. Jednak uruchomienie stosu w środowisku i przetestowanie go jest niezwykle tanie. Nie musisz robić dokładnej lokalnej kopii środowisk chmurowych.
Aby zmniejszyć rozmiar wdrażanych paczek i przyspieszyć ładowanie, użyj AWS Lambda Layers.
Używaj odpowiednich języków programowania do konkretnych zadań. Różne języki mają swoje zalety i wady. Istnieje wiele benchmarków, ale JavaScript, Python i C# (.NET Core 2.1+) są liderami pod względem wydajności AWS Lambda. Niedawno w AWS Lambda pojawił się Runtime API, który pozwala na określenie preferowanego języka i środowiska wykonawczego, więc eksperymentuj.
Utrzymuj mały rozmiar paczek do wdrożenia. Im mniejsze, tym szybciej się ładują. Unikaj używania dużych bibliotek, zwłaszcza jeśli korzystasz tylko z kilku ich funkcji. Jeśli programujesz w JavaScript, używaj narzędzi do pakowania, takich jak Webpack, aby zoptymalizować budowę i uwzględnić tylko to, co jest naprawdę potrzebne. W .NET Core 3.0 wprowadzono QuickJit i Tiered Compilation, które poprawiają wydajność i znacznie pomagają przy zimnych uruchomieniach.
Zależność funkcji bezserwerowych od zdarzeń może na początku utrudniać koordynację logiki biznesowej. W tym kontekście niezwykle przydatne mogą być kolejki wiadomości oraz automaty stanów. Funkcje Lambda mogą wywoływać się nawzajem, ale rób to tylko wtedy, gdy nie oczekujesz odpowiedzi ("strzel i zapomnij") — nie chcesz przecież płacić za czekanie na zakończenie innej funkcji. Kolejki wiadomości są pomocne w oddzielaniu części logiki biznesowej, zarządzaniu wąskimi gardłami aplikacji oraz przetwarzaniu transakcji (przy pomocy kolejek FIFO). Funkcje AWS Lambda mogą być powiązane z kolejkami SQS jako kolejki "utkwionych" wiadomości, które śledzą błędne wiadomości do późniejszej analizy. Funkcje AWS Step Functions (automaty stanów) są bardzo pomocne w zarządzaniu złożonymi procesami wymagającymi tworzenia łańcuchów funkcji. Zamiast tego, aby funkcja Lambda wywoływała inną funkcję, Step Functions mogą koordynować przejścia stanów, przekazywać dane między funkcjami i zarządzać globalnym stanem funkcji. Umożliwia to określenie warunków ponownych prób lub tego, co należy zrobić w przypadku wystąpienia konkretnego błędu — w określonych warunkach bardzo potężne narzędzie.
Podsumowanie
W ostatnich latach technologie bezserwerowe rozwijają się w niewiarygodnym tempie. Z tą zmianą paradygmatu wiążą się pewne nieporozumienia. Dzięki abstrahowaniu infrastruktury i zarządzaniu skalowalnością, rozwiązania bezserwerowe oferują znaczne korzyści: od uproszczenia procesów rozwoju i DevOps, po znaczne obniżenie kosztów operacyjnych.
I chociaż podejście bezserwerowe nie jest pozbawione wad, istnieją niezawodne metody i wzorce projektowania, które pozwalają tworzyć odporne aplikacje bezserwerowe lub integrować elementy bezserwerowe z istniejącymi architekturami.
Źródło: habr.com
