Zacznijmy od tego, że serverless to jest model dostarczania usług w chmurze przez dostawców, takich jak Amazon Web Services, Microsoft Azure czy GCP – Google Cloud Platform. Nazwa mogłaby wskazywać, że w serverless nie ma serwerów, jednak nie jest to prawdą. Serwery są i pozostają zarządzane przez tych właśnie dostawców. Chodzi po prostu o to, że z punktu widzenia użytkownika w zasadzie nie musimy przejmować się infrastrukturą. Dlatego że jest ona zapewniona, jest zarządzana przez dostawców. Robione są przez nich aktualizacje systemów operacyjnych, zapewniona jest wysoka dostępność – HA, automatyczna skalowalność etc. Czyli my jako programista, jako zespół tworzący jakiś produkt w tym środowisku, możemy się skupić w stu procentach na logice biznesowej i tworzyć sam produkt cyfrowy bez przejmowania się tym, co leży pod spodem.
No i dochodzimy tutaj do takiego miejsca na starcie, gdzie myślę, że może być nieco mylące czym w takim razie różni się Serverless od Cloud-Native, o którym przeczytasz w artykule “Cloud Native Development & Computing – co to? Intro, warstwy, zalety i wady”? Różni się tym, że w przypadku cloud-native dostajemy od wspomnianych dostawców klocki, na których możemy nasze rozwiązanie budować. I to my jesteśmy odpowiedzialni za zarządzanie infrastrukturą, za budowanie i rozwijanie jej. W przypadku serverless to jest niejako krok dalej w stronę naszej relacji z dostawcą, bo to właśnie dostawca zajmuje się tym wszystkim. To on dla nas wykonuje kompleksowo usługę i pokrywa cały ten obszar swoją pracą, swoimi kompetencjami i swoimi ludźmi. Czyli dla nas, z punktu widzenia klienta, serverless to bardziej zaawansowana usługa i mniej kłopotów na głowie.
Zalety Serverless
Przede wszystkim, jeżeli nie musimy zajmować się warstwą infrastruktury, to nie musimy też zatrudniać ludzi w tym obszarze kompetencji. Nie musimy przejmować się tym tematem, dlatego że zabezpiecza go nasz partner, nasz dostawca. A my w pakiecie dostajemy wszystko, co powinniśmy mieć włącznie z dopasowaną infrastrukturą, która funkcjonuje dla nas w modelu pay as you go. Czyli infrastruktura dopasowuje się do naszego systemu, do naszej aplikacji tak, aby nie generować dodatkowych kosztów. Można powiedzieć, że ona podąża za tym, co my w warstwie biznesowej tworzymy.
Jeżeli tworzymy jakieś rozwiązanie, jakiś system, nie musimy przejmować się tematem infrastruktury, no to nie jest on częścią naszego backlogu. Czyli skupiając się na stworzeniu warstwy logicznej rozwiązania, tworzymy je po prostu dużo, dużo szybciej. Skupiamy się na rozwoju wewnętrznych kompetencji, które mają dla nas kluczowe znaczenie. Takie rozwiązanie jest zwyczajnie wygodne z punktu widzenia operacji.
Jako, że outsource’ujemy, oddajemy naszemu dostawcy odpowiedzialność za fundament naszego rozwiązania (o tym z jakich warstw składa się produkt cyfrowy przeczytasz w artykule “Jak zbudowany jest produkt cyfrowy? UI/UX, Front End, Back End” przenosimy też na partnera odpowiedzialność za część naszego produktu. Dużą jej część stanowi bezpieczeństwo naszej infrastruktury. A tu, jako że najczęściej firmy wybierają jednego z trzech wspomnianych, topowych dostawców, jakość i bezpieczeństwo ich usług będą na bardzo wysokim poziomie. Takie firmy jak AWS czy Microsoft zatrudniają topowych specjalistów w zakresie bezpieczeństwa czy dev-ops, dlatego możemy liczyć na solidność ich rozwiązań.
Wady Serverless
A czy serverless ma wady? No nie ma rozwiązań bez wad. W tym wypadku przede wszystkim będzie to tak zwany zimny start, czyli to, co zwykle działa na naszą korzyść. Jeżeli na przykład z danej funkcji nie korzystamy przez jakiś czas (możemy ustalić jaki jest to czas), to automat zacznie takie funkcje dla nas wyłączać. Właśnie po to, abyśmy nie musieli za nie niepotrzebnie płacić. Natomiast kiedy z kolei musimy z tej funkcji skorzystać, no to po prostu chwilę trwa jej uruchomienie, ponieważ nie jest już zapisana w cache. I wtedy narażamy się na to, że jakieś rozwiązanie nie jest dla nas od ręki dostępne. Są już też takie rozwiązania, które umożliwiają nam zabezpieczenie takiej sytuacji. Wybór tych funkcji, które powinny być dla nas cały czas dostępne. Czyli chcemy za nie potencjalnie nadmiernie płacić w okresie, w którym nie korzystamy z nich, ale są to funkcje krytyczne dla naszego rozwiązania. Dlatego wybieramy, aby one były cały czas w stanie gotowości.
Drugą wadą rozwiązania typu serverless jest nadmierne przywiązanie do danego dostawcy, czyli tak zwany vendor lock. Dlatego że jeżeli już tak bardzo wiążemy się z tym dostawcą i korzystamy z rozwiązań, które w zasadzie w praktycznie stu procentach wyręczają nas w warstwie infrastruktury. Które są tak bardzo mocno związane z naszym rozwiązaniem logicznym, biznesowym, no to później może się okazać, że jeżeli ten dostawca w niekorzystny sposób dla nas np. zmienia swój cennik, wycofuje jakąś usługę, no to może być dla nas bardzo trudne przestawić się na innego dostawcę.
Czy warto korzystać z rozwiązań Serverless?
Natomiast serverless znajduje się w ofercie wszystkich dużych vendorów. W przypadku Microsoftu i Google’a nazywa się Azure Functions i Google Cloud Functions. W przypadku AWS – Amazon Web Services nazywa się AWS Lambda. Serverless bardzo mocno zyskuje na popularności. W zasadzie już wszystkie większe firmy informatyczne, które jakieś oprogramowanie produkują, z rozwiązań typu serverless korzystają. Chodzi o to, że jest to po prostu bezpieczniejsze i wygodniejsze. Jeżeli potrafimy z tego korzystać, mamy już wiedzę odnośnie możliwości i kompetencje wewnętrzne, jeżeli mamy dobrą relację z dostawcą, jest to również rozwiązanie często tańsze. Pozwala nam na szybsze dostarczanie kolejnych iteracji oprogramowania. Pozwala nam pozbyć się warstwy, która często bywa problematyczna, której utrzymanie czy utrzymanie zespołu, który ją rozwija, bywa bardzo drogie. Znalezienie talentu na rynku bywa bardzo trudne. Więc w zasadzie pozbywamy się w ten sposób wielu problemów, a potencjalnie zyskujemy masę benefitów.
Obejrzyj film:
