Jeszcze nie tak dawno na DevOps Days Warsaw 2016 przewijały się przepowiednie o konteneryzacji i Dockerze jako technologii, która jest przyszłością. Każdy kto wówczas zainwestował swój czas w naukę Dockera z pewnością dziś tego nie żałuje. W TTPSC uważamy, że konteneryzacja nie jest ostatnim etapem ewolucji i zdecydowanie stawiamy na rozwiązania serverless jako ostateczny wynik technologicznej rewolucji w dobie rozwiązań chmurowych. Nie jesteśmy w tej opinii osamotnieni, ponieważ w podobnym tonie wypowiadali się eksperci chmurowi w Polsce już w 2017 roku. Początkowo również byłem sceptyczny, jednak z czasem dałem się przekonać i dzisiaj sam jestem wielkim entuzjastą, nie tylko samej chmury publicznej, ale właśnie rozwiązań serverless.
Jaka jest przewaga rozwiązania serverless nad serwerem, maszyną wirtualną i kontenerem?
Odpowiedź na to pytanie jest prosta. Nieważne czy jest to fizyczny sprzęt w naszej serwerowni, instancja czy kontener w chmurze. Zawsze wymaga to od nas uwagi. Czasem mniej, a czasem więcej ale ktoś zawsze musi nad infrastrukturą czuwać i administrować nasze urządzenia. Dodatkowo, jeżeli chcemy nasz projekt zamienić w produkt i wypuścić go na rynek, to dochodzą nam zmartwienia takie jak High Availability, skalowalność czy bezpieczeństwo (o kosztach nie wspominam celowo, gdyż sprawą oczywistą jest fakt, że są one spore). Te wszystkie komplikacje nas ominą jeżeli zdecydujemy się na rozwiązanie serverless. Jak sama nazwa wskazuje, nie mamy tutaj serwerów, do których wypada zatrudnić przynajmniej jednego administratora. Stąd też koszt początkowy infrastruktury wymaganej do startu projektu jest bliski zeru. Korzystamy z gotowych serwisów i rozwiązań oferowanych przez dostawcę chmury publicznej – do nas należy jedynie decyzja, kogo wybrać. W moim zespole, składającym się głównie ze specjalistów DevOps, korzystamy z AWS, ale Azure i Google Cloud Platform mają swoje odpowiedniki Lambdy – odpowiednio Azure Functions i Google Functions. Oprócz Lambdy, czyli funkcji, która wykona dla nas kod, potrzebujemy oczywiście innych serwisów – naszą aplikację budujemy używając usług chmurowych jak klocków lego. Jakie to będą klocki i jak je połączymy jest tylko i wyłącznie naszą decyzją i wynika głównie z tego, jakiego rodzaju aplikacje i produkt tworzymy i o jakim zasięgu myślimy (lokalny czy globalny). Najważniejsze jest to, że skoro nie mamy żadnych instancji, kontenerów w chmurze i serwerów po swojej stronie, to cała odpowiedzialność za bezpieczeństwo, dostępność oraz skalowalność spoczywa na naszym dostawcy. Dodatkowo koszt początkowy (a często też końcowy) jest znacznie niższy od klasycznych rozwiązań serwerowych.
Brzmi zbyt pięknie? Czy to naprawdę działa?
Owszem, brzmi jak bajka ale tylko dlatego, że mnóstwo rozwiązań starszych, czyli aplikacji monolitycznych lub częściowo monolitycznych typu Enteprise, nie da się łatwo i tanio przerobić na mikroserwisy i zastosować w pełni rozwiązania typu serverless. Lecz jeżeli macie własny startup lub po prostu projekt, który planujecie rozpocząć, lub niedawno wystartował, to naprawdę polecam przemyśleć ten model i zastanowić się nad tym co oferuje serverless. Aby nie być gołosłownym. Niedawno w naszej firmie odbył się 24 godzinny maraton innowacji, gdzie każdy mógł zgłosić swój projekt i realizować go w ramach zebranego na ten czas zespołu. Jednym z pomysłów był najprostszy możliwy portal do sharowania dużych plików (mowa o wirtualnych maszynach wielkości 100-200gb lub więcej), między pracownikami naszej firmy, partnerami oraz klientami, a także globalnie. Od razu przychodzi na myśl wykorzystanie chmury publicznej oraz rozwiązania serverless. Działające demo projektu zostało ukończone w niecałe 2 dni i łączny koszt, uwzględniający wykorzystanie AWS S3, wyniósł niecałe 3 dolary! Mamy gotowy portal przy minimalnym koszcie i zero czasu poświęconego na infrastrukturę. Koszty samego S3 storage będą oczywiście w przyszłości większe, ale podałem ten przykład aby pokazać jak łatwo i tanio można zrealizować prosty projekt stosując sto procent serverless.
Podsumowanie
Czas pokaże, czy Serverless okaże się nowym standardem, wykorzystywanym przez kolejną dekadę lub nawet dwie. Jednak z pewnością na tą chwilę jest to optymalne wykorzystanie oferty chmury publicznej, bo jest to w stu procentach model Pay As You Go. Nie ma ryzyka, że zapomnieliśmy wyłączyć nieużywaną instancję i zapłacimy za coś co jest nam nie potrzebne. Nie zadzwoni do nas nasz administrator w panice, że nasza wersja Apache ma krytyczną lukę bezpieczeństwa i trzeba natomiast przeprowadzić update. Nie padnie nam serwer, bo nagle milion osób wcisnęło refresh na naszej stronie. Dodatkowo sama idea Lambdy wymusza poniekąd na developerach optymalizację kodu, ponieważ maksymalny czas wykonania pojedynczej funkcji to 300 sekund. Sam fakt optymalnego wykorzystania chmury powinien was zachęcić do poznania i używania rozwiązania serverless, do czego ja ze swojej strony gorąco zachęcam!
