fbpx

6 ARGUMENTÓW ZA ZASTOSOWANIEM SERVERLESS ZAMIAST KONTENERÓW

Podejście serverless jest świeżą metodyką, zastępującą długo działające maszyny wirtualne i kontenery Docker, na rzecz szybko uruchamianych i krótko żyjących funkcji. Rozwiązanie to szturmem zdobyło chmury obliczeniowe (cloud computing) i jest oferowane przez wszystkich głównych graczy.

Ale serverless to nie tylko funkcje, będące najpowszechniejszym przedstawicielem nurtu usług nie administrowanych. To również inne serwisy typu bazy danych, których przykładem jest Amazon Aurora Serverless. W jej przypadku nie ustawiamy żadnych serwerów, a jej mechanizm sam uruchamia się i zatrzymuje. 

W przeciwieństwie do kontenerów, które trzeba administrować i konfigurować, serverless to działanie wykonuje automatycznie, bez naszego udziału. 
Mocnymi stronami techniki serverless są:

Mocnymi stronami techniki serverless są:

Skalowalność

Architektura oparta na podejściu bez serwerowym potrafi automatycznie zwiększać lub zmniejszać używane zasoby, aby zaspokoić popyt wraz ze zmieniającym się ruchem wywołanym działaniami użytkowników. Pobierane opłaty rosną wraz ze wzrostem użycia, ale nie wpływa to na działanie systemu.

Opłaty są wprost proporcjonalne do ilości wywołań, co przekłada się również na rentowność naszego biznesu, gdzie jesteśmy zależni od płacących użytkowników i im ich liczba jest większa tym możemy więcej płacić za infrastrukturę.

W przypadku nagłego zapotrzebowania wirtualne maszyny lub Docker w celu zwiększenia liczby wdrożonych kontenerów potrzebują więcej czasu na aktualizację niż niezwłocznie dostępne funkcje.

Brak fizycznych maszyn

W każdej usłudze bez serwerowej gdzieś pod spodem znajduje się serwer. Jednak jest on zależny od dostawcy, którego zadaniem jest zadbanie o to, aby moc i konfiguracja maszyny zapewniła nam nieprzerwaną dostępność naszych aplikacji.

Na dostawcy ciąży odpowiedzialność za ciągłość działania oraz bezpieczeństwo środowiska. Pozwala to nam skupić się na naszym biznesie i funkcjonalności naszych systemów.

Koszt

Należy zauważyć, że często kontenery są uruchomione cały czas, dlatego dostawcy usług w chmurze naliczają opłaty za działanie lub miejsce na serwerze, niezależnie od tego, czy aplikacja jest w użyciu, czy też nie. W przypadku architektury bez serwerowej nie ma ciągłych wydatków, ponieważ kod aplikacji jest uruchamiany, gdy zostanie wywołany. Opłata jest naliczana od ilości wywołań, a nie czasu działania lub zajętego miejsca.

6 argumentów za zastosowaniem serverless zamiast kontenerów

Utrzymanie

Po stronie usług chmurowych obsługujących kontenery leży odpowiedzialność za aktualizację tylko systemów infrastruktury. Nie mają oni dostępu do naszego kontenera. Za aktualizację bibliotek, kolejnych wersji języka jest odpowiedzialny programista tworzący kontener.

Z punktu widzenia dewelopera lub projektanta architektura bezserwerowa nie wymaga zarządzania zapleczem. Dostawca zajmuje się wszystkimi aktualizacjami administracyjnymi i aktualizacjami oprogramowania dla serwerów, na których działa kod.

Czas wdrożenia

Początkowy czas konfigurowania kontenerów jest znacznie dłuższy niż użycie funkcji. Wymagana jest konfiguracja systemu, ustawień i bibliotek. Dlatego wdrożenie kontenerów jest bardziej pracochłonne. Z drugiej strony wdrożenie funkcji serverless zajmuje sekundy, ponieważ nie wymaga konfiguracji a projekty działają od razu po przesłaniu ich na serwer.

Testowanie

Testowanie rozwiązań serverless było bardziej uciążliwe w porównaniu do testowania kontenerów. Dzięki postępowi technologii zdalnego debugowania oraz możliwościom tworzenia środowisk lokalnie, programista może szybko zidentyfikować problem. Ułatwia to testowanie i usprawnia proces rozwoju aplikacji.

Wniosek

Zarówno serverless jak i kontenery są technologiami szeroko wykorzystywanymi w chmurze. Z tego powodu zmniejszyły się wydatki na infrastrukturę sprzętową. Ta zmiana paradygmatu wprowadza innowacyjne podejście do pisania aplikacji, umożliwiające programistom skupienie się na kodzie. Istnieje trend znacząco poprawiający jakość oprogramowania poprzez zmniejszenia złożoności systemów i cięcia kosztów zakupu urządzeń.

Szafrański Michał
Jako Architekt IT, nie tylko projektuję systemy informatyczne, ale również moje życie jest zaprojektowane w taki sposób, aby działać jak dobrze zaprojektowany system - jestem zawsze gotowy na wszelkie wyzwania i problemy. Podobnie jak każdy system, który projektuję, staram się być skalowalny i elastyczny, a czasem trudno przewidzieć, kiedy potrzebna będzie aktualizacja. Często słyszę pytanie: "Kiedy zostanie wydany update twojego życia?" A ja odpowiadam: "Kiedyś, ale zanim to nastąpi, muszę zebrać więcej danych i przeprowadzić odpowiednie testy." Moje życie to nie tylko kodowanie i projektowanie, ale również ciągłe doskonalenie i uczenie się nowych technologii. Nieustannie próbuję wprowadzać ulepszenia, zarówno w moim życiu osobistym, jak i zawodowym. A jeśli coś nie działa, nie boję się eksperymentować i próbować różnych rozwiązań, aby znaleźć najlepsze rozwiązanie. Nie jestem tylko architektem IT - jestem również architektem swojego życia, zaprojektowanym w taki sposób, aby działał jak dobrze zaprojektowany system.

Leave a Reply Text