• Akademia
  • Blog
  • O Serverless
  • O stronie

6 zalet serverless dla Twojego biznesu


6 zalet serverless dla Twojego biznesu
Ka偶dy buzzword w 艣wiecie nowych technologii owiany jest mgie艂k膮 tajemnicy, za kt贸r膮 pod膮偶a ekscytacja developer贸w, kt贸rzy pracuj膮 w艂a艣nie z t膮 najnowsz膮 technologi膮. Cz臋sto utrudnia to zrozumienie sedna nowego rozwi膮zania i oddzielenie konkret贸w od marketingowego mydlenia oczu. Na og贸艂 osoby z wieloletnim do艣wiadczeniem w bran偶y sceptycznie podchodz膮 do szumu medialnego i buzzoword贸w, niestety taka zachowawcza postawa znakomicie u艂atwia przegapienie warto艣ciowych rozwi膮za艅 dla Twojej firmy.

Serverless to przyk艂ad takiego buzzword, jest o nim bardzo g艂o艣nio ostatnimi czasu. Wszystko zacz臋艂o si臋 w 2014 roku, kiedy to Amazon Web Services przedstawi艂 now膮 us艂ug臋 w swojej chmurze: AWS Lambda. Scharakteryzowa艂 j膮, jako us艂ug臋 obliczeniow膮 (podobnie jak uprzednio maszyny wirtualne) wskazuj膮c jej zalety:

  • Brak serwer贸w do zarz膮dzania
  • Ci膮g艂e skalowanie i balansowanie obci膮偶enia
  • Automatyczne prze艂膮czanie awaryjne
  • Op艂aty tylko za zu偶yty czas dzia艂ania 鈥 brak op艂at za bezczynno艣膰 systemu.

Je艣li nie jeste艣 osob膮 znaj膮c膮 si臋 na in偶ynierii oprogramowania lub pr贸bujesz wyt艂umaczy膰, co to jest serverless osobie nietechnicznej, powy偶sza lista mo偶e brzmie膰 jak nerdowski be艂kot. I nawet fakt, 偶e koszty Lambdy by艂y rozliczane, co do 100 milisekund w czasie, gdy EC2 (serwery wirtualne) w 2014r. by艂y rozliczane z dok艂adno艣ci膮, co do godziny (PRZE艁OM!) niewiele Ci powie o realnych zaletach tego rozwi膮zania dla Twojego biznesu.

Zatem co oznacza serverless dla biznesu i jakie korzy艣ci mo偶e przynie艣膰 Twojej firmie?

  1. Kr贸tszy czas wej艣cia na rynek (time-to-market)
  2. Zwi臋kszona efektywno艣膰 (wi臋cej za mniej)
  3. Twoje koszty sta艂e sta艂y si臋 kosztami operacyjnymi
  4. Mniej marnotrawstwa
  5. Wi臋ksza elastyczno艣膰
  6. Efektywniejszy proces rozwoju i testowania

Wyja艣nijmy.

1. Kr贸tszy czas wej艣cia na rynek (time-to-market)

Dla wielu firm 艣cie偶ka dostarczania aplikacji na rynek jest d艂uga. Wraz z planowaniem produktu, projektowaniem i rozwojem, musisz tak偶e pomy艣le膰 o potrzebnej infrastrukturze, konfiguracji, dost臋pno艣ci zasob贸w oraz skalowalno艣ci na wypadek nieprzewidzianych skok贸w obci膮偶enia, kt贸re mog膮 si臋 pojawi膰 znienacka w dobie virali i marketingu wirusowego.

W 艣wiecie serverless nie musisz si臋 ju偶 martwi膰 o wynajem i zakup infrastruktury, jej konfiguracj臋 i planowanie dost臋pno艣ci zasob贸w. Kroki te zosta艂y usuni臋te z procesu rozwoju produktu i s膮 teraz obowi膮zkiem dostawcy platformy serverless. Od teraz musisz 鈥漷ylko鈥 my艣le膰 o tym, jak prawid艂owo zaprojektowa膰, zbudowa膰 i wdro偶y膰 swoj膮 aplikacj膮 na platformie dostawcy. To znacznie skraca czas wej艣cia na rynek, poniewa偶 cykl rozwoju jest kr贸tszy.

2. Zwi臋kszona efektywno艣膰 (wi臋cej za mniej)

Klasyczne rozwi膮zania (czyli nie serverless) dzia艂aj膮 non-stop. Czy ich u偶ywasz czy nie, musz膮 by膰 w艂膮czone. Nigdy nie wiesz, kiedy Twojego klienta najdzie ochota, aby wej艣膰 do Twojego sklepu internetowego i zakupi膰 Tw贸j ekstra produkt, prawda? Je艣li nie masz sklepu internetowego 鈥 niewa偶ne, ten przyk艂ad jest w miar臋 uniwersalny, wi臋c na chwil臋 wyobra藕 sobie, 偶e masz taki sklep 馃槈

Ob艂o偶enie Twojego serwera, na kt贸rym dzia艂a Tw贸j sklep (w praktyce to jest zawsze kilka maszyn a nie jedna, ale tutaj upraszczamy) mo偶na przedstawi膰 na wykresie w czasie. 艢rednie wykorzystanie serwera, czyli jego efektywno艣膰 w ci膮gu dnia mo偶e wygl膮da膰 jak na poni偶szym rysunku.

Jest 艣wietnie, widzia艂e艣 zapewne wiele takich diagram贸w. W ci膮gu dnia jest du偶y ruch a w nocy mniejszy bo ludzie 艣pi膮.

U偶ycie serwera w czasie

U偶ycie serwera w czasie

W czym zatem problem?
Bez wzgl臋du na to czy Twoje serwery w艂a艣nie zarabiaj膮 dla Ciebie pieni膮dze (klienci kupuj膮) czy stoj膮 w艂膮czone bezczynnie (brak klient贸w) p艂acisz za nie tyle samo! (Je艣li masz w艂asn膮 serwerownie to p艂acisz mniej za pr膮d, gdy stoj膮 bezczynnie, ale to s艂abe pocieszenie). Przedstawmy te same dane z powy偶szego diagramu troch臋 inaczej. Odwr贸膰my perspektyw臋 i skupmy si臋 na stratach, jakie generuje serwer w czasie.

Strata serwera w czasie

Wykres zachodz膮cego s艂o艅ca. Straty tego samego serwera w czasie

Obecnie, niezale偶nie od tego, czy wynajmujesz serwery wirtualne, czy jeste艣 w艂a艣cicielem serwerowni, marnujesz zasoby. P艂acisz za zarezerwowany czas bez wzgl臋du na to, czy Twoje aplikacje s膮 u偶ywane, czy nie. P艂acisz za ca艂膮 czarn膮 ramk臋 symbolizuj膮c膮 jeden serwer. No oko Twoja strata (偶贸艂topomara艅czowy obszar) to jakie艣 50%.

Serverless zmienia zasady 鈥瀏ry鈥. Od teraz p艂acisz tylko za czas, w kt贸rym Twoja aplikacja by艂a aktywnie u偶ywana przez Twoich klient贸w! Efektywno艣膰 wzrasta do 100%.

Efektywno艣膰 serverless

Efektywno艣膰 serverless to 100%

Znikn臋艂a ramka z g贸ry, poniewa偶 AWS Lambda jest automatycznie skalowalna przez dostawc臋. Dostosuje si臋 samodzielnie do ruchu w danym momencie. W ramach potrzeby przeskaluje si臋 powy偶ej mo偶liwo艣ci jednego serwera (ramka symbolizowa艂a w艂a艣nie jeden serwer).

Szczerze m贸wi膮c, ten diagram troch臋 traci sens, poniewa偶 bez r贸偶nicy czy mamy jedno 偶膮danie czy 10 milion贸w, zawsze efektywno艣膰 kosztowa wynosi 100%. 馃

Pomy艣l, jak膮 by艣 mia艂 strat臋 buduj膮c system dla miliona u偶ytkownik贸w a obs艂ugiwa艂 tylko jednego?

3. Twoje koszty sta艂e sta艂y si臋 kosztami operacyjnymi

Wyobra藕 sobie, 偶e Twoja firma ma 10 milion贸w 偶膮da艅 u偶ytkownik贸w dziennie. Ka偶de 偶膮danie u偶ytkownika wykonuje r贸wnie偶 kilka po艂膮cze艅 wewn臋trznych, 艂膮cznie do 30 milion贸w 偶膮da艅.

Aby obs艂u偶y膰 ten wolumen, obecnie musisz wynaj膮膰 flot臋 wirtualnych serwer贸w w chmurze lub zbudowa膰 w艂asne centrum danych (serwerownia). Przyjmijmy, 偶e koszty infrastruktury wynosz膮 miesi臋cznie kilkadziesi膮t tysi臋cy z艂oty. Je艣li doliczymy do tego koszty zespo艂u in偶ynier贸w do konfiguracji i obs艂ugi infrastruktury, koszt贸w centrum danych, konserwacji itd., to b臋d膮 one znacznie wi臋ksze.

Jak zawsze polecam poczyta膰 o Total Cost of Ownership u Gartnera. Koszty obs艂ugi i administracji serwerami s膮 znacz膮ce. Oczywi艣cie Twoi in偶ynierzy powiedz膮 Ci, 偶e wszystko mo偶na zautomatyzowa膰 i to wcale nie jest tak du偶o roboty. Bynajmniej, z serwerami jest zawsze mn贸stwo roboty (wiem, bo mam ich 4500 u jednego klienta). Nawet jak wszystko zautomatyzujesz i ogarniesz (co nie zrobi si臋 za darmo oczywi艣cie) to i tak mo偶e na Ciebie spa艣膰 jaka艣 g贸wnoburza w postaci dziury bezpiecze艅stwa w procesorach Intela czy inna podobna niespodzianka zapewniaj膮ca zabaw臋 na kilka dni. Administracja to tylko jeden z obszar贸w gdzie serwery generuj膮 koszty.

W 艣wiecie serverless koszty zosta艂y powi膮zane z realnie wykonan膮 prac膮, tak zwanymi 偶膮daniami. Ka偶de dzia艂anie Twojego klienta tworzy jakie艣 techniczne 偶膮dania np. pobierz dane z bazy danych, wygeneruj raport itp. wszystkie obs艂ugiwane s膮 przez Lambd臋.

艢rednia cena AWS Lambda to nieca艂e 20 cent贸w na milion 偶膮da艅 (uproszczenie). Wydaje si臋 to by膰 wyj膮tkowo tanio, ale AWS Lambda jest tylko us艂ug膮 obliczeniow膮 (wykonuje kod i nic poza tym), wi臋c b臋dziesz r贸wnie偶 potrzebowa艂 przechowywania danych, us艂ug powiadamiania i tak dalej. Dodatkowo architektury serverless r贸偶ni膮 si臋 do klasycznych, co powoduje wzrost liczby wewn臋trznych po艂膮cze艅. W sumie serverlessowy odpowiednik Twojego systemu mo偶e generowa膰 oko艂o 60 milion贸w 偶膮da艅 dziennie. To du偶o, ale koszt us艂ug obliczeniowych wraz z przechowywaniem danych i innymi us艂ugami, kt贸re mog膮 by膰 potrzebne, spadnie do tysi臋cy z艂oty miesi臋cznie, czyli jeden rz膮d mniej.

Twoje koszty sta艂e (CAPEX) sta艂y si臋 w艂a艣nie kosztami operacyjnymi (OPEX). Koszty sta艂e to te, kt贸re nie s膮 powi膮zane z wynikami. Serwerownie, budynki, ochrona, bezpiecze艅stwo, sprz臋t oraz ludzie.
R贸偶nica polega na tym, 偶e w pierwszym modelu bez wzgl臋du na to, jakie by艂o ob艂o偶enie systemu i wynik ko艅cowy, koszt sta艂e by艂y鈥 sta艂e. Serwery to zawsze koszty sta艂e. Nie wierzysz mi, to zastan贸w si臋 czy Twoja firma kupowa艂a Reserved Instances od AWS na 3 lata w przysz艂o艣膰?

W serverless koszty zale偶膮 od realnego u偶ycia (model pay-as-you-go - opisa艂em go dok艂adnie w innych artyku艂ach) i s膮 to zawsze koszty operacyjne.

Nie jestem ksi臋gowym, ale pos艂u偶臋 si臋 analogicznym przyk艂adem. Dla mnie leasing samochodu to koszt sta艂y, bo go ponosisz bez wzgl臋du na to czy korzystasz z auta czy nie. Taks贸wki to koszt operacyjny, uzale偶niony od realnego u偶ycia.

4. Mniej marnotrawstwa

Podczas opracowywania wielu produkt贸w niekt贸re funkcje s膮 wielokrotnie tworzone na nowo. Na przyk艂ad przetwarzanie p艂atno艣ci, uwierzytelnianie u偶ytkownika, zarz膮dzanie has艂ami, powiadomienia.
Korzystanie z us艂ug serverless i cloud native znacz膮co eliminuje potrzeby budowy 鈥瀗a nowo鈥 technicznych komponent贸w, kt贸re ju偶 lata temu zosta艂y zbudowane i nie wp艂ywaj膮 znacz膮co na nasz produkt ko艅cowy - takie utowarowienie w IT.

Utowarowienie jest to zjawisko, w kt贸rym produkty i us艂ugi trac膮 w oczach klient贸w swoj膮 wyj膮tkowo艣膰, a r贸偶nice mi臋dzy markami zacieraj膮 si臋. Jedyn膮 cech膮 umo偶liwiaj膮c膮 ich odr贸偶nienie jest cena.
呕r贸d艂o: http://www.mojsposobmyslenia.pl/utowarowienie-nie-taki-biznes-chcesz-prowadzic/

Odpowiedz szczerze: jakie znaczenie dla Twojego klienta ma to w jakiej bazie danych trzymasz jego dane? W jaki spos贸b zarz膮dzasz u偶ytkownikami? Czego u偶ywasz do wysy艂ania maili?
Moim zdaniem: 呕adne.

W nowym podej艣ciu, z jednej strony korzystamy z us艂ug oferowanych przez dostawc臋 chmury, a z drugiej strony serverless promuje ponowne wykorzystanie zbudowanych wewn膮trz w firmie komponent贸w-us艂ug poniewa偶 jest rozwijany w architekturze mikroserwis贸w. Komponent obs艂uguj膮cy produkt 鈥濧鈥, mo偶na wykorzysta膰 w linii produkt贸w 鈥濩鈥.

Podsumowuj膮c, nie marnujemy zasob贸w ludzkich na ponowne wymy艣lanie ko艂a i montowanie go w naszej biznesowej maszynie.

5. Wi臋ksza elastyczno艣膰

Przedsi臋biorstwa, a zw艂aszcza startupy, musz膮 zmienia膰 swoje produkty, pomys艂y i kierunek rozwoju, aby utrzyma膰 si臋 na rynku. Tego typu zmiany cz臋sto wymagaj膮 przebudowy system贸w IT i oferowanych us艂ug. Obecnie wiele aplikacji jest budowanych, jako tzw. monolity lub umieszczane w kontenerach i uruchamiane w chmurze. Taki spos贸b wytwarzania oprogramowania jest ma艂o elastyczny. Nawet niewielka zmiana oferowanego produktu mo偶e spowodowa膰 kosztowne restrukturyzacje lub wymaga膰 ca艂kowitego przepisania systemu.

Serverless zwi臋ksza elastyczno艣膰 Twojego biznesu. Systemy serverless natywnie wykorzystuj膮 architektur臋 mikrosystem贸w, kt贸ra zaleca rozdzielenie aplikacji na wiele ma艂ych niezale偶nych us艂ug (komponent贸w aplikacyjnych). W ten spos贸b zwi臋kszasz elastyczno艣膰 swojej firmy. W przypadku, gdy chcesz zmodyfikowa膰 sw贸j produkt, przestawi膰 firm臋 na inny rynek, to zmieniasz tylko wybrane mikroserwisy, a nie ca艂e monolity. Jest to du偶o ta艅sze, szybsze i bezpieczniejsze. Co wi臋cej, mo偶esz r贸wnocze艣nie wspiera膰 stary produkt i nowy. Wsp贸lne us艂ugi b臋d膮 si臋 same skalowa艂y tak, aby obs艂u偶y膰 zwi臋kszony ruchu wynikaj膮cy z dw贸ch linii produktowych.

Na poni偶szym rysunku, mikroserwis B obs艂uguje ruch zwi膮zany z dwoma produktami. Mikroserwisy D i E zosta艂y dodane p贸藕niej, aby obs艂ugiwa膰 drugi produkt (z贸艂te strza艂ki), ju偶 po tym jak produkt pierwszy by艂 uruchomiony (zielone strza艂ki). Pomimo tego, 偶e mikroserwis B obs艂uguje sum臋 ruchu z obu produkt贸w nie ma problemu z wydajno艣ci膮, poniewa偶 skaluje si臋 niezale偶nie od pozosta艂ych mikroserwis贸w. Jest to wielka zaleta optymalizuj膮ca koszty, niemo偶liwa do osi膮gni臋cia w 艣wiecie monolit贸w.

Ponowne wykorzystanie gotowych us艂ug

Ponowne wykorzystanie stworzonych wcze艣niej us艂ug. Mikroserwis B skaluje si臋 automatycznie aby obs艂u偶y膰 ruch z dw贸ch lini produktowych.

6. Efektywniejszy proces rozwoju i testowania

Budowanie aplikacji sk艂adaj膮cej si臋 z wielu niezale偶nych us艂ug pomo偶e Ci osi膮gn膮膰

  • 艁atwiejsze zarz膮dzanie projektami IT
  • 艁atwiejsze testowanie
  • Dostarczanie projekt贸w w czasie i bud偶ecie

艁atwiejsze zarz膮dzanie projektami IT

Rozwijanie aplikacji, jako zbioru niezale偶nych us艂ug u艂atwia prowadzenie projekt贸w. Funkcjonalno艣ci pozostaj膮 zamkni臋te w osobnych komponentach i nie przenikaj膮 si臋 nawzajem. Ograniczasz scope creep (pe艂zaj膮cy zakres) i chronisz si臋 przed nowymi b艂臋dami dodanymi w trakcie rozwoju. To jest standardowy problem w monolitach 鈥瀟u dodajesz, a tam przestaje dzia艂a膰鈥 鈥 zjawisko na tyle popularne, 偶e a偶 wymy艣lono testy regresyjne aby mu przeciwdzia艂a膰.

艁atwiejsze testowanie

Projektowanie aplikacji, jako zbioru wielu pojedynczych us艂ug-komponent贸w u艂atwia ich testowanie. Zwykle podczas programowania musisz tak偶e skonfigurowa膰 wiele 艣rodowisk (dev, test, prod) i zap艂aci膰 za nie. W serverless tworzenie wielu 艣rodowisk jest darmowe i 艂atwe, poniewa偶 p艂acisz tylko za realnie u偶yte zasoby (np. jak nie testujesz to nie p艂acisz). Serverless wykorzystuje podej艣cie infrastruktura-jako-kod, dzi臋ki czemu tworzenie (i kasowanie) 艣rodowisk jest szybkie i trywialnie proste.

Dostarczanie projekt贸w w czasie i bud偶ecie

Mniejsze komponenty 艂atwiej jest zaprojektowa膰 i oszacowa膰 ich pracoch艂onno艣膰. Twoje szacunki i estymaty s膮 bardziej pewne. Dzi臋ki czemu Twoje projekty staj膮 si臋 bardziej przewidywalne i s膮 dostarczane w czasie i bud偶ecie.

B膮d藕my szczerzy. Serverless to nie panaceum na ca艂e z艂o.

Zastan贸wmy si臋 jakie s膮 potencjalne skutki uboczne korzystania z serverless?

Serverless oferuje szereg korzy艣ci dla biznesu. Niemniej jednak nie ma jednego idealnego podej艣cia, technologii ani strategii, kt贸re by艂yby rozwi膮zaniem w ka偶dej sytuacji. Serverless ma r贸wnie偶 swoje wady i problemy, kt贸re mog膮 sprawi膰, 偶e b臋dzie on nieodpowiedni dla Twojej firmy lub konkretnego projektu.

1. Vendor lock-in

Uruchamianie aplikacji w modelu serverless mo偶e 艣ci艣le powi膮za膰 Twoj膮 aplikacj臋 z infrastruktur膮 dostawcy chmury. Popularnie z angielskiego ten problem nazywamy vendor lock-in. Nawet, je艣li logika biznesowa nie zale偶y od samej us艂ugi, to nadal wymaga bezpo艣redniego osadzenia na platformie dostawcy. Z powodu r贸偶nic pomi臋dzy rozwi膮zaniami serverless oferowanymi przez r贸偶nych dostawc贸w chmury, potencjalne przeniesienie aplikacji na inne platformy mo偶e wi膮za膰 si臋 ze znacznym kosztem i czasem potrzebnym na modyfikacj臋 kodu Twojego rozwi膮zania. Przed vendor lock-in mo偶na si臋 chroni膰 stosuj膮c odpowiednie zabiegi na etapie projektowania rozwi膮zania (architektura heksagonalna, domain driver design).

W tym miejscu nale偶y te偶 jasno powiedzie膰, 偶e vendor lock-in jest bardzo rozdmuchanym problemem. Za to stwierdzenie pewnie bardzo mi si臋 oberwie. Istniej膮 firmy, kt贸re przegapi艂y rozw贸j chmury, ich ca艂y biznes opiera si臋 na tradycyjnych rozwi膮zaniach, fizycznym sprz臋cie i serwerowniach. To najcz臋艣ciej pracownicy tych firm strasz膮 i przestrzegaj膮 przed z艂膮 chmur膮 i tr贸jk膮 krwiopijc贸w (Amazon, Google, Microsoft). Za艂o偶臋 si臋, 偶e Ci sami ludzie w swojej karierze doradzali wyb贸r baz Oracla i .Net 鈥 wtedy vendor lock-in im nie przeszkadza艂. 馃槨

Ja osobi艣cie nie zamierzam nikogo namawia膰 do adopcji chmury. Ka偶da organizacja musi podj膮膰 t臋 decyzj臋 samodzielnie, rozwa偶aj膮c za i przeciw. Natomiast jak ju偶 j膮 podejmie to nie powinna si臋 ci膮gle obraca膰 za siebie. Trzeba patrze膰 w przysz艂o艣膰 i planowa膰 jak najlepiej wykorzysta膰 mo偶liwo艣ci, kt贸re oferuje chmura w swoim biznesie.

I jeszcze na koniec. Z tego, co mi wiadomo, nie ma 偶adnych dowod贸w na jakiekolwiek dzia艂ania vendor lock-in ze strony dostawc贸w. Wr臋cz przeciwnie, przyk艂adowo w AWS, wirtualne serwery EC2, co roku s膮 od艣wie偶ane, to znaczy, 偶e nowe typy maszyn s膮 ta艅sze ni偶 ubieg艂oroczne i oferuj膮 艣rednio 20% wydajno艣ci wi臋cej za ni偶sz膮 cen臋! Jak do mnie to dobry deal a nie vendor lock-in. 馃憤

2. Utrzymanie wielu ma艂ych us艂ug mo偶e by膰 k艂opotliwe

Obs艂uga i projektowanie system贸w rozproszonych jest trudniejsza ni偶 system贸w monolitycznych. I nawet, je艣li to tylko subiektywna kwestia, to fakty s膮 takie, 偶e na rynku znajdziesz 20 razy wi臋cej ludzi z do艣wiadczeniem w monolitach ni偶 tych, kt贸rzy si臋 znaj膮 na systemach rozproszonych. Wynika to z tego gdzie, jako bran偶a byli艣my 10, 15, 20 lat temu.

Efektywnie, na pocz膮tku, mniej os贸b w Twojej firmie b臋dzie w stanie rozwik艂a膰 problemy w aplikacjach serverless, poniewa偶 nie dysponuj膮 odpowiednim do艣wiadczeniem. Mo偶na temu zarazi膰 po przez szkolenia oraz propagowanie rozwi膮za艅 serverless w systemach niekrytycznych, tak, aby kadra nabra艂a do艣wiadczenia bez nadmiernego stresu.

Nale偶y pami臋ta膰, 偶e pomimo tego i偶 serverless wydaje si臋 by膰 zupe艂nie innym podej艣ciem, nie pojawi艂 si臋 u nas z kosmosu. Opiera si臋 na rozwi膮zaniach, kt贸re istniej膮 w IT od lat (m.in. kontenery) i ka偶da do艣wiadczona osoba, ch臋tna do rozwoju, powinna szybko si臋 odnale藕膰 w tej klasie rozwi膮za艅.

3. Zimny start

Ostatni z najcz臋艣ciej wymienianych problem贸w w kontek艣cie serverless to zimny start. Poniewa偶 dostawca chmury jest odpowiedzialny za skalowanie aplikacji serverless i dostosowanie jej do dowolnie ma艂ego i du偶ego ruchu to mo偶e si臋 zdarzy膰, 偶e po pewnym okresie bezczynno艣ci (na og贸艂 kilkana艣cie minut) ponowne uruchomienie aplikacji b臋dzie obarczone paroma karnymi sekundami.

Dostawca chmury obs艂uguje r贸wnocze艣nie setki tysi臋cy klient贸w. To s膮 grube tysi膮ce miliard贸w obs艂u偶onych 偶膮da艅 dziennie. Je艣li akurat nikt nie korzysta z Twojego systemu, to dostawca optymalizuje swoje zasoby i usuwa z pami臋ci Twoj膮 aplikacje. Karny zimny start zwi膮zany jest z ponownym wgraniem kodu Twojego rozwi膮zania.

Podsumowanie

Jak wida膰 serverless to nie tylko buzzword ale konkretna kategoria rozwi膮za艅 oferuj膮ca realne benefity. Jest to bardzo 艣wie偶e podej艣cie do tworzenia oprogramowania, kt贸re jeszcze boryka si臋 z pewnymi problemami wieku m艂odzie艅czego. Najwi臋kszym z nich wydaje si臋 by膰 brak wiedzy i pod膮偶aj膮cy za nim brak zaufania ze strony in偶ynier贸w projektuj膮cych systemy.

Mimo tego, jak podaj膮 statystyki, 24% zupe艂nie nowych wdro偶e艅 w chmurze to rozwi膮zania serverless. Serverless na naszych oczach staje si臋 numerem jeden rozwi膮za艅 cloud native. (殴r贸d艂o: Cloud Programming Simplified: A Berkeley View on Serverless Computing). Wynika to zapewne z kr贸tszego czasu wdro偶enia i znaczych oszcz臋dno艣ci kosztowych w stosunku do r贸wnowa偶nych rozwi膮za艅 serwerowych.

Uwa偶am, 偶e zdecydowanie warto rozwa偶y膰 serverless jako rozwi膮zanie dla Twojego przysz艂ego projektu w chmurze.