re:Invent 2022, coroczna konferencja AWS w Las Vegas, już za nami. Nie uczestniczyłem w niej osobiście, ale dzięki mogłem przygotować listę najważniejszych nowości serverless, gdy wszyscy inni odsypiają te intensywne 5 dni konferencji. I tylko trochę im zazdroszczę.
Ten artykuł został oryginalnie opublikowany w języku angielskim na BetterDev.blog.
pre:Invent
“pre:Invent” to okres kilku tygodni przed samą konferencją. W tym czasie zawsze obserwujemy wzmożoną ilość ogłoszeń nowych funkcjonalności i ulepszeń.
Oto zestawienie moich ulubionych.
🔑 Dodawanie wielu urządzeń MFA w IAM
W końcu.
Już wcześniej mogliśmy ustawić uwierzytelnienie wieloskładnikowe (MFA, Multi-Factor Authentication) dla użytkowników IAM oraz konta root. Ale dotychczas mogło to być tylko 1 urządzenie do uwierzytelniania naraz. W przypadku zgubienia lub zniszczenia urządzenia, mogliśmy zostać pozbawieni dostępu do konta AWS.
Na szczęście to już przeszłość. Teraz możemy dodać do 8 urządzeń MFA, którymi mogą być:
- urządzenia wirtualne - takie jak aplikacja Authy
- klucze FIDO - takie jak YubiKey
- urządzenia generujące tokeny TOTP
Jeśli nie masz ustawionego uwierzytelniania wieloskładnikowego na AWS, zwłaszcza dla konta root - najwyższa pora to zmienić. MFA z urządzeniem wirtualnym (aplikacją) jest darmowe i proste do skonfigurowania. Z drugiej strony, klucze FIDO zapewniają jeszcze większe bezpieczeństwo, aczkolwiek wymagają zakupu fizycznego klucza. Użytkownicy AWS ze Stanów Zjednoczonych mogą dostać YubiKey od AWS za darmo, lecz niestety oferta ta nie obowiązuje w Polsce.
Owszem, zmiana ta nie dotyczy stricte serverless, lecz jest zbyt ważna aby ją pominąć.
🏃♂️ Node.js 18 w Lambdach
18.x to obecna wersja LTS Node.js. Jak każda wersja, zawiera ona szereg nowości i ulepszeń. Jednym z najważniejszych jest dostępność Fetch API, czyli przeniesienie dobrze znanej z przeglądarek funkcji fetch() do backendu, co pozwala na łatwe wykonywanie zapytań HTTP bez instalacji dodatkowych bibliotek. Mimo że jest to funkcjonalność nadal eksperymentalna, Fetch API jest domyślnie dostępne w Node 18.
Ale może nawet ważniejsze jest to, środowisko wykonawcze Node.js 18.x dla funkcji Lambda zawiera AWS SDK v3. Zastępuje ono AWS SDK v2, dostępne w poprzednich wersjach środowiska. Teraz, używając nowego SDK v3, możesz nie dodawać go do paczki kodu (bundle) dla funkcji Lambda, skoro SDK jest i tak dostępne w runtime. Nie jest to metoda którą ja sam stosuję, ale wiem, że robi tak wiele osób.
Warto jednak zwrócić uwagę, że pierwsi użytkownicy zgłaszają większy zimny start dla środowiska Node 18 w porównaniu z Node 16. Miejmy nadzieję, że wkrótce zostanie to poprawione.
Jeśli używasz AWS JS SDK v3, najlepszym (i oficjalnie polecanym) sposobem na mockowanie go na potrzeby testów jednostkowych jest moja biblioteka aws-sdk-client-mock.
⏰ EventBridge Scheduler
Nowa funkcjonalność EventBridge pozwala na planowanie zdarzeń do wykonania w przyszłości. Ale moment, przecież mieliśmy już CloudWatch Events, potem przekształcone na zaplanowane reguły (scheduled rules) w EventBridge.
Tak, ale nowy EventBridge Scheduler ma znacznie większe możliwości. Na przykład integruje się z setkami serwisów AWS, pozwalając na bezpośrednie wykonywanie na nich metod API, bez potrzeby użycia funkcji Lambda.
Ale najbardziej wyróżniającą cechą są zadania jednorazowe (one-time schedules). Do tej pory zaplanowanie akcji, która miałaby się jednorazowo wykonać w przyszłości, sprowadzało się do użycia TTL (time to live) w DynamoDB lub okresowego sprawdzania statusu. Teraz można to osiągnąć dzięki EventBridge.
Nowy Scheduler ma miękki limit 1 miliona zaplanowanych zadań, wysoką przepustowość oraz konfigurowalne okna czasowe do dystrybucji obciążenia. Jedyną wadą jest to, że zadania jednorazowe nie są automatycznie usuwane po wykonaniu i nadal wliczają się do limitu zaplanowanych zadań. Ale odpowiedni zespół pracuje już nad rozwiązaniem.
📨 Rozszerzone reguły filtrowania w EventBridge
Pozostając przy EventBridge, mamy teraz nowe możliwości filtrowanie zdarzeń. Przede wszystkim możemy filtrować na podstawie sufiksu (suffix) - była to bardzo pożądana funkcja, pozwalająca filtrować zdarzenia z obiektów w S3 na podstawie rozszerzenia pliku. Oprócz tego doszedł nowy filtr equals-ignore-case do porównywania wartości ignorując wielkość znaków oraz dyrektywa $or pozwalająca na podanie kilku filtrów, z których co najmniej jeden musi być spełniony.
Szczegóły działania wszystkich filtrów możesz znaleźć w dokumentacji.
🚀 AppSync JavaScript Resolvers
To była długo oczekiwana i najbardziej pożądana funkcjonalność w AppSync.
Resolwery to kawałki kodu integrujące AppSync z innymi serwisami. Służą one budowie zapytań i przetwarzaniu odpowiedzi. Do tej pory musieliśmy pisać je w VTL (Apache Velocity Templates) - formacie wręcz uwielbianym przez programistów. Bo gdyby go tak nie lubili, nie spędzaliby tyle czasu na jego pisaniu, prawda? 😉
JavaScript jest teraz domyślnym językiem dla resolwerów w AppSync. Warto jednak wiedzieć, że mamy tu kilka ograniczeń:
- nie cała składnia JavaScript jest dostępna,
- operacje asynchroniczne są niedozwolone,
- nie ma połączenia z internetem,
- kod musi zawierać się w pojedynczym pliku do 32 KB wielkości.
Zatem, mimo że pisane w JavaScripcie, to nadal tylko (i aż) resolwery AppSync. Ich zadaniem jest przygotowanie wiadomości, które AppSync wyśle do innych serwisów. Nie zastępują one funkcji Lambda dla bardziej złożonych operacji.
Lecz nadal jest to ogromne usprawnienie. Używając JavaScriptu, pisanie i testowanie resolwerów będzie znacznie prostsze i szybsze. No i oczywiście możemy używać TypeScriptu i transpilować go do JS!
🧩 Operacje na innych kontach ze Step Functions
Task w Step Functions może teraz przyjmować podaną rolę IAM i bezpośrednio uzyskiwać dostęp do zasobów na innych kontach AWS.
Do tej pory, aby uzyskać dostęp do innego konta, potrzebowaliśmy funkcji Lambda, która przyjęłaby (assume) podaną rolę z dostępem do innego konta (cross-account role). Teraz wystarczy podać ARN roli w definicji kroku, a Step Functions same ją przyjmie. W ten sposób możesz wywoływać dowolne operacje API dowolnych usług na innych kontach (rzecz jasna, mając rolę z pozwalającymi na to uprawnieniami).
re:Invent
Oczywiście, największe nowości zostały ogłoszone na samym re:Invent.
🚰 EventBridge Pipes
EventBridge Pipes sprawiają, że funkcje Lambda stają się przeżytkiem.
Potoki (pipes) są wyzwalane przez zdarzenia z różnych źródeł, podobnie jak funkcje Lambda. Następnie możemy filtrować, wzbogacać i modyfikować nadchodzące zdarzenia. Na koniec wysyłamy je do celu.
Ten przepływ opisuje funkcjonalność wiele funkcji Lambda, które napisałem w przeszłości. Z potokami EventBridge, jest to proste, niezawodne i skuteczne, z niewielką ilością kodu.
Na ten moment, jako źródła zdarzeń potoki obsługują DynamoDB Streams, Kinesis Streams, SQS, MSK oraz MQ. Do wzbogacania zdarzeń możemy użyć funkcji Lambda, Step Functions lub wywołań API. Potoki mogą wysłać zdarzenia do 15 różnych celów, takich jak EventBridge, endpointy API, Kinesis Streams, Kinesis Firehose, SNS, SQS, Step Functions i Lambda.
A wszystkie te funkcjonalności dostajemy za zaledwie 0.40 USD za milion wywołań (i to po filtrowaniu!). Dla porównania, jest to ta sama cena jaką płacimy za wywołania SQS. Ponadto możemy to zoptymalizować, konfigurując grupowanie (batching) przychodzących zdarzeń.
🪣 Step Functions Distributed Map
Step Functions idealnie nadają się do przetwarzania danych. Ale ilość danych, które możesz przekazać pomiędzy kolejnymi krokami jest ograniczona. Tak samo ograniczona jest równoległość zadań w ramach pojedynczego wykonania, co negatywnie wpływa na wydajność większych zadań. Przez to przetwarzanie plików opiera się na wykorzystaniu funkcji Lambda.
Cóż, aż do teraz.
Nowa odmiana stanu Map, Distributed Map, służy orkiestracji przetwarzania na dużą skalę bezpośrednio w Step Functions, skupiając się głównie na plikach w S3. Stan Distributed Map może czytać pliki JSON oraz CSV z S3 i iterować po kolejnych rekordach. Lub nawet lepiej - samodzielnie listować pliki z S3 i iterować po nich. Następnie, w celu przetwarzania rekordów lub plików, uruchamia oddzielne, podrzędne wywołania Step Functions, z nawet 10,000 równoległych wykonań. Co więcej, aby zoptymalizować wykonania, dane mogą być przetwarzane partiami (z podrzędnym wykonaniem Step Functions otrzymującym wiele rekordów/plików naraz jako dane wejściowe).
🫰 Lambda SnapStart dla Javy
Java jest niechlubnie znana z długich “zimnych startów” (cold start) w Lambdach. I mimo że zwykle mówię, że zimne starty nie mają znaczenia, mam to myśli w przypadku inicjalizacji zajmującej 0.5-1 sekundy. W przypadku Javy często jest to powyżej 5 sekund, co stanowi zupełnie inny problemem.
Prawdopodobnie właśnie dlatego AWS postanowił rozwiązać ten problem, zaczynając właśnie od Javy. Dzięki nowej funkcji SnapStart inicjalizacja odbywa się podczas tworzenia (deploymentu) funkcji. Następnie stan dysku oraz pamięci zainicjalizowanej funkcji jest zapisywany. Kiedy funkcja jest wywoływana, środowisko jest przywracane z tego zapisanego stanu w mniej niż 200 ms.
Jest mało prawdopodobne, abym napisał jakąkolwiek funkcję Lambda w Javie. Mam jednak nadzieję, że w przyszłości SnapStart będzie dostępny również dla innych środowisk. Jeżeli (lub kiedy) stanie się dostępny dla Pythona i Dockera, będzie to przełom dla serverlessowych rozwiązań Machine Learning, które także cierpią z powodu długich zimnych startów.
🕵️♂️ Obsługa Lambd przez Inspectora
Amazon Inspector to serwis skanujący używane biblioteki (dependencies) pod kątem znanych luk w zabezpieczeniach. Nie wymaga instalacji żadnych dodatkowych zależności lub agentów. A teraz, oprócz EC2 i ECR, obsługuje także funkcje Lambda.
Aby go użyć, wystarczy włączyć opcję w ustawieniach Inspectora w konsoli AWS. Od tego momentu automatycznie i w sposób ciągły będzie on skanował wszystkie funkcje Lambda na koncie.
Ile kosztuje bezpieczeństwo? 0.30 USD za każdą funkcję Lambda miesięcznie.
Czy powinieneś od razu uruchomić skanowanie, przynajmniej na koncie produkcyjnym? Prawdopodobnie tak, chyba że masz już wdrożone skanowanie zagrożeń w bibliotekach (np. przy użyciu GitHub Dependabot lub Snyk).
no:Invent
Niestety, nie obyło się bez rozczarowań.
💸 OpenSearch “Serverless”
Jedną z obietnic serverless jest brak opłat przy braku wykorzystania. AWS sam wielokrotnie mówił o tym w przeszłości.
Ale w tym roku AWS postanowił złamać tę obietnicę. Moim zdaniem - wyłącznie w celach marketingowych, ponieważ “serverless” jest teraz w modzie.
Tak więc po MSK “Serverless”, Aurora “Serverless” v2, oraz Neptune “Serverless”, teraz dostaliśmy OpenSearch “Serverless”.
Co łączy je wszystkie? Nie skalują się do zera. Co za tym idzie, używając ich zapłacisz stawkę minimalną za stworzone instancje, nawet jeśli ich nie używasz.
Jak dużo? Prawie 700 USD miesięcznie za OpenSearch “Serverless”.
Dlaczego jest to taki problem? Cieszę się, że pytasz. Odpowiedziałem na to pytanie po ogłoszeniu Aurory “Serverless” v2.
Nie zrozum mnie źle. Automatyczne skalowanie wszystkich tych serwisów to wspaniała rzecz. Rozumiem też, że nie jest łatwo stworzyć bazę danych, która skaluje się do zera, a następnie błyskawicznie wybudza, aby obsłużyć przychodzące żądania bez dodatkowych opóźnień. Moim jedynym problemem jest mylące nazewnictwo.
🏅 Brak certyfikatu Serverless Specialty
Pomimo całego marketingu wokół tematyki serverless, nadal nie ma certyfikatu AWS Serverless Specialty. Owszem, rozwiązania serverless są częścią egzaminów na certyfikaty Associate oraz Professional, ale stanowią tylko około 10% wszystkich pytań. A certyfikat potwierdzający znajomość nowoczesnych, serverlessowych architektur i rozwiązań, bez EC2 i skomplikowanego routingu sieciowego, to coś, na co społeczność niecierpliwie czeka.
Ale dostaliśmy nagrodę pocieszenia - ścieżkę nauki serverless w AWS Skill Builder. Jest to bezpłatny kurs online, który można przejść we własnym tempie, i na koniec zdobyć odznakę.
Warte uwagi
Na re:Invent ogłoszone wiele, wiele więcej nowości, zarówno dotyczących serverless jak i nie.
- Możesz teraz zarządzać Organizacją AWS poprzez CloudFormation, w tym tworzyć konta, jednostki organizacyjne (Organizational Units) i zasady (policies). To jedna z tych rzeczy, przy których dziwisz się, że nie była możliwa wcześniej. Ja jednak póki co pozostanę przy OrgFormation do zarządzania moimi kontami, jako że oferuje ono przydatne dodatkowe funkcjonalności.
- AWS Glue, serwis, którego osobiście nie jestem wielkim fanem, jest teraz dostępny w wersji 4.0. Oprócz tego dostał kilka nowych możliwości.
- SageMaker, i tak już przeładowany funkcjonalnościami, otrzymał co najmniej tuzin nowych.
- Application Composer to nowe narzędzie do wizualnego projektowania aplikacji serverless. Po Step Functions Workflow Studio jest to kolejne rozwiązanie drag-and-drop sugerujące, że AWS chce ulepszyć swoje Developer Experience. Wątpię jednak, abym ja sam z niego skorzystał. Nie do końca wierzę w projektowanie aplikacji metodą “przeciągnij i upuść”. Poza tym, Application Composer integruje się z SAM jako narzędzie do Infrastructure as Code, podczas gdy ja korzystam z CDK.
- Nie mogę się jednak doczekać, aby dowiedzieć się więcej o Amazon Verified Permissions, obecnie jeszcze niedostępnym publicznie. Z tego co rozumiem, pozwoli ono scedować zarządzanie uprawnieniami i dostępem użytkowników aplikacji na AWS. Na pewno to wypróbuję.
Przyszłość serverless
AWS Lambda nie jest już niezbędnym elementem aplikacji serverless. Coraz więcej rozwiązań możemy zbudować korzystając wyłącznie z usług typu “low-code”, takich jak AppSync z jego bezpośrednimi integracjami z innymi serwisami (teraz przy użyciu JavaScript), EventBridge (teraz z Pipes) czy Step Functions (teraz z wbudowanym przetwarzaniem plików). Jeśli funkcje Lambda są w ogóle używane, ich role się zmniejsza.
I to jest świetne.
Kod jest obciążeniem.
Przenosząc standardowe i powtarzalne operacje na platformę, możemy szybciej budować nasze aplikacje. Jest mniej kodu do napisania, przetestowania i utrzymania. Mniej kodu oznacza też mniejsze ryzyko błędów.
I to jest właśnie idea serverless. Mniej rzeczy do zarządzania dla nas, programistów. Więcej czasu na skupienie się na tym, co jest ważne z punktu widzenia biznesu.
Nagrania wystąpień
AWS re:Invent to nie tylko ekscytujące nowości. To też wiele prezentacji technicznych.
Jasne, część z nich to tylko firmy i ich autoreklama. Ale wiele prezentacji technicznych prowadzą najlepsi specjaliści w swoich dziedzinach, którzy zbudowali serwisy, z których korzystasz. I są to wystąpienia na różnych poziomach zaawansowania.
Ich nagrania są dostępne na tej długiej liście (ponad 750 filmów na ten moment): AWS re:Invent 2022 sessions
