Na bazie własnego doświadczenia oraz lektury wielu blogów, wysłuchania podcastów i prezentacji mogę śmiało powiedzieć, że istnieją dwie najpopularniejsze drogi do użycia serverless w każdej organizacji.
Pierwsza to greenfield. Powstaje nowy projekt i ktoś (może to byłeś Ty 😃🤝 ) zadecydował, że zostanie on dostarczony w chmurze zgodnie z architekturą serverless.
Druga ścieżka wiedzie przez scenariusz niskiego ryzyka. Innymi słowy, Ty i/lub Twoja organizacja, widzi potencjał, ale nie chce od razu skakać na głęboką wodę. Najpierw trzeba się obwąchać z tą całą Lambdą, a dopiero gdy się ją lepiej pozna wkroczyć w świat serverless.
Będę z Tobą szczery, jeśli jesteś szczęściarzem to trafi Ci się nowiuśki projekt w serverless. Twoje szanse są jak jeden do czterech. Bazuję tutaj na danych z publikacji Cloud Programming Simplified: A Berkeley View on Serverless Computing, która mówi „recent surveys found that about 24% of serverless users were new to cloud computing”. W podobnym tonie ostatnio się wypowiedział Austen Collins, twórca Serverless Framework i CEO Serverless Inc. Zapytany o najpopularniejszą chmurę wśród użytkowników Serverless Framework powiedział, że dominuje AWS oraz dodał „about 25% of our users have never even used AWS before”. Czyli 1/4 firm, nawet bez doświadczenia w chmurze, startuje od serverless. Osobiście mnie to nie dziwi, bo dzięki serverless mnóstwo rzeczy przestaje być naszym problemem.
Jeśli natomiast należysz do pozostałej grupy osób to musisz walczyć o swoje! Przekonywać szefa, architekta, admina oraz kolegów z zespołu, że ta cała Lambda i serverless mają sens. Najprościej będzie to zrobić dysponując gotowym przykładem. Najlepiej z wewnątrz organizacji. Ale skąd go wziąć skoro nikt jeszcze nie zrobił takiego projektu? 🤔
Odpowiedź jest prosta: samemu musisz go stworzyć! To jest właśnie druga ścieżka.
Bierne czekanie na super projekt to kiepska strategia. Bądź niepokorny! Nie zgadzaj się na status quo. Stąd rodzi się, tak pożądana w obecnych czasach, innowacyjność.
Znajdź jakiś problem, który można rozwiązać używając AWS Lambda. Na początku to nie musi być pełnoprawne rozwiązanie serverless. Możliwe, że prosta funkcja Lambda może automatyzować pewne zadania w tradycyjnym, serwerowym rozwiązaniu. To właśnie może być Twoja szansa na pierwsze wdrożenie!
👉 Aby Ci pomóc zidentyfikować takie obszary, przygotowałem listę popularnych zastosowań Lambdy:
- wszelkie zadania cronowe (wywoływane, co pewien czas). np. kopiowanie plików, prasowanie ich i inne transformacje.
- cykliczne odpytywanie usług wewnętrznych albo firm trzecich i np. zapisywanie zwróconych danych do bazy.
- tworzenie raportów lub przynajmniej uruchamiane z odpowiednimi parametrami usługi, która te raporty generuje
- automatyzacja zadań administratorskich w chmurze (cloud operations). Funkcja Lambda za pomocą AWS SDK może zrobić to samo, co człowiek klikając w konsole webową AWS. Tylko szybciej i pewniej.
- (prze)konfigurowanie usług AWS w odpowiedzi na zdarzenie np. w odpowiedzi na uruchomienie nowego serwera EC2 funkcja Lambda modyfikuje rekord DNS w Route53 (przydatne, gdy z jakiegoś powodu nie chcesz używać load balancerów)
- jako custom resource w Cloud Formation, w sumie konieczne do stosowania w bardziej zaawansowanych wdrożeniach
- gdy masz w chmurze na serwerach “starodawne” aplikacje serwerowe firm trzecich, którym musisz podać licencje. Lambda może okazać się świetnym rozwiązaniem do automatyzacji takiego procesu. Szczególnie, jeśli te serwery są w Auto Scaling Group.
- wymuszanie procedur bezpieczeństwa np. automatyzacja wymiany, co 90 dni, kluczy dostępowych do AWS (IAM access keys)
- disaster recovery, oczywiście nie całe, ale Lambda może być użyta, jako narzędzie monitorujące stan aplikacji i w razie potrzeby może uruchomić cały proces. Może być też użyta do tego, aby zbudować zastępcze środowisko (jeśli mamy infrastrukturę opisaną jako kod np. w CloudFormation). Na pewno się przyda w tańszych podejściach DR takich jak „Backup & Restore” lub „Pilot light”
- automatyzacja pewnych kroków w procesie CI/CD
- automatyzacja testów np. można uruchamiać Chroma w lambdzie, aby testował nasze aplikacje webowe
- scraping stron WWW
- customowa autentykacja w Cognito
- boty, które np. wysyłają informacje na firmowego Slacka, na bazie zdarzeń w chmurze
- chatboty dla biznesu
- transcoding plików wideo i audio
- zamiana tekstu na mowę (wraz z AWS Polly)
To tylko klika pomysłów prosto z mojej głowy, które nadają się na pierwszy mini projekcik niskiego ryzyka z AWS Lambda w roli głównej. Każdy z nich pozwoli Tobie zademonstrować w praktyce zalety tego podejścia przed szefem i kolegami z zespołu. To nie musi robić wielkiego wrażenia, raczej to ma być taki „but w drzwi” pozwalający na dalszą, organiczną ekspansję Lambdy w Twoje firmie. Pamiętaj „jeden mały krok dla człowieka…” i tak dalej 🙂
Jeśli nasuwają Ci się jakieś pytania lub pomysły to napisz do mnie lub rozpocznij dyskusję na naszym forum internetowym tutaj https://forum.serverlesspolska.pl/
