Mój blog jak wiele innych oparty jest, a właściwie to był o platformę WordPress. Środowisko stało sobie gdzieś w AWS, na serwerze wraz z całą paczką wordpress, bazą, apache itp. Wiadomo wszystko as low cost as possible.
Jednak z tym wszystkim wiązał się jeszcze jeden fakt, razem z prowadzeniem samego bloga było kilka innych kwestii, o które musiałem się troszczyć. Chodzi oczywiście o utrzymywanie infrastruktury, na której było to zainstalowane. Mam na myśli aktualizacje serwerów, dbanie o backup platformy blogowej, bazy danych itp. Do tego oczywiście dochodzą jeszcze koszty wirtualnych maszyn i pozostałych komponentów.
Zacząłem szukać innego pomysłu na prowadzenie bloga. Oczywiście internet jest pełen ofert bardziej bądź mniej komercyjnych. Można za kilkanaście złotych miesięcznie kupić sobie wordpress’a as a service. Pamiętając jednak o różnych zasłyszanych przypadkach, gdy dostawca coś tam z upgradował, klientowi przestało działać, proszę sobie znaleść informatyka i naprawić itp. Pomyślałem, że wolę jednak zachować większą niezależność i kontrolę nad środowiskiem.
Serverless
To hasło, które tak jak kontenery i dockery robi teraz furorę na wielu meetupach, konferencjach i spotkaniach branży IT. Ogólnie chodzi oto, że jest to model aplikacji która działa na rozwiązaniach “Backend as a Service” lub “Function as a Service”. Mowa tu o usługach typu AWS Lambda czy Azure Functions.
W dużym skrócie, w modelu serverless chodzi o możliwość zrealizowania pewnego zestawu operacji bez troszczenia się o zasoby znajdujące się pod spodem.
Bez serwerów, bez apache, bez bazy danych
Jakiś czas temu wpadłem na Hexo, jest to framework pozwalający zbudować platformę blogową nie wymagającą żadnego serwera czy bazy danych. Framework ten generuje bloga w modelu statycznej strony, którą wystarczy umiejscowić na dowolnym storage dostępnym publicznie (np. AWS S3, Github Pages). Zaciekawiłem się tym rozwiązaniem i postanowiłem zgłębić nieco bardziej.
Produkt w tej chwili oferuje sporą paletę funkcjonalności. Jest dość łatwy w instalacji, oraz posiada całkiem czytelną dokumentacje. Dostępne są różne gotowe motywy graficzne, które można szybko dostosować do własnych potrzeb. Ja zastosowałem template clean-blog ponieważ posiada już kilka wbudowanych funkcjonalności jak Google Analytics, Disqus itp. Poza tym i to wg mnie jest dość kluczowe, bardzo łatwo można ogarnąć budowę takiego templatu. Dzięki temu dalsza modyfikacja wg własnych potrzeb staje się bardzo prosta. Widać to dobrze na przykładzie mojej strony, która dość mocno różni się od oryginalnej wersji szablonu. W tym miejscu od razu wyjaśnię, że nie jestem programistą. Tzn. miałem styczność z programowanie i z grubsza rozumiem o co w nim “kaman”, ale tylko na tyle aby być w stanie po pewnym czasie ogarnąć kod i go zmodyfikować na swoje potrzeby. Jak widać to wystarczyło.
Dodatkowo do dyspozycji mamy sporą ilość gotowych pluginów, którymi możemy rozszerzyć funkcjonalność naszego bloga. Do dyspozycji jest np. portal administracyjny do graficznej edycji i pisania. Gotowe pluginy do zaimportowania dotychczasowego bloga hostowanego np. na wordpress czy joomla. Dzięki temu w kilka minut miałem przeniesione wszystkie dotychczasowe posty. Jedyną rzeczą wymagającą modyfikacji były linki do grafik, które wskazywały na te z wordpress’a.
Na koniec jedną komendą generuje się całą strukturę bloga, którą następnie wystarczy umieścić na publicznym storage. Ja do tego celu użyłem AWS S3. Potem tylko zmiana rekordu w DNS i “vuala”.
Taaa daaammmm!
Dzięki tym zabiegom, to co czytasz w tej chwili, serwowane jest dla Ciebie w modelu serverless. Zero serwerów, zero kłopotów, 100% fokusu na treści!
Potrzebowałem jeszcze trochę “dynamiki” czyli formularz kontaktowy. Ale dzięki API Gateway i AWS Lambda szybko udało się tą funkcjonalność zrealizować. Kolejne dwie usługi w których nie martwimy się o serwery i całą otoczkę. Tylko szybka implementacja API Gateway z funkcją Lambda wysyłającą wiadomości po AWS SNS i “vuala”.
Koszty, koszty, koszty!
To co jest jednym z największych “driverów” modelu serverless, to redukcja kosztów. Do nich zaliczają się między innymi dużo niższe koszty utrzymania. Nie zajmujemy się już instalacją utrzymaniem serwerów, sieci, baz danych itp.
W klasycznej architekturze mamy flotę maszyn wirtualnych, które ciągle są “na chodzie” bez względu na to czy ktoś aktualnie korzysta z naszego systemu czy nie. I za to “na chodzie” trzeba w chmurze płacić. W modelu serverless, płacimy tylko gdy ktoś korzysta z naszej witryny (oczywiście są też stałe koszty jak np przestrzeń dyskowa) i to generuje spore oszczędności względem klasycznego podejścia.
Dla porównania, przyjmijmy, że mamy świeżą dość strone www “jak najtaniej”, jedna instancja t2.micro. Z palca 8GB dysk, 1GB danych przesłanych w każdą stronę. Koszt miesięczny takiej konfiguracji to około $14. Nie wspominając o kosztach operacyjnych…
W modelu serverless opłacie podlega przestrzeń dyskowa na S3 plus transfer. Do tego koszty wykonywania funkcji Lambda dla formularza, to wszystko z grubsza daje koszt około $5,5.
I choć wyliczenie są mocno ogólne, jednak dość dobrze pokazują znaczącą różnice.
Co jeszcze zyskałem?
Przede wszystkim wysoką dostępność przy bardzo niskim koszcie. Chcąc osiągnąć to przy poprzedniej architekturze, trzeba by ją trochę zmodyfikować, co oczywiście wpłynęłoby też na koszt.
Tutaj od razu mam kopie moich plików w miniumum 3 niezależnych DC i jedenaście dziewiątek dla Data Durability.
Mało? Jeśli tak, to można zrobić replikację do innych regionów i zaprząc logikę rozrzucania ruchu i detekcji awarii na poziomie DNS. Wciąż mało?
Do tego można zwiększyć sobie responsywność poprzez użycie CDN (np. AWS CloudFront). Pamiętajmy, że nasza strona to statyczne pliki czyli to co CDN lubi najbardziej 🙂
Czy potrzebujesz coś więcej do prowadzenia bloga, czy prostej promującej swój biznes strony? Nie sądzę 🙂
Na koniec
Rozwiązania serwerless robią coraz większą furorę, ponieważ pozwalają skupić się na tym co najważniejsze, na realizacji logiki biznesowej, a nie dopieszczaniu konfiguracji infrastruktury. W internecie pojawią się coraz więcej ciekawych Customer Success Stories (jak np. 30K Page Views for $0.21: A Serverless Story) opisujących migracje czy implementację dość zaawansowanych systemów w modelu serverless.
Myślę, że tego typu rozwiązanie może się świetnie sprawdzić w kilku scenariuszach.
Twoja główna strona ma charakter promocyjny, w modelu serverlessowym może być tańsza i prostsza w utrzymaniu.
Masz problemy, że gdy w wyniku awarii w DataCenter jednocześnie “znikasz” w Internecie. To świetne rozwiązanie aby zrobić sobie taką “backupową” stronę poza własnym DC i w razie awarii przerzucić tam ruch. Z Route53 możesz to zrobić w pełni automatycznie.
Jeśli masz inne ciekawe pomysły podziel się proszę w komentarzu, a jeśli masz jakieś pomysły, bądź szukasz pomocy, napisz do mnie.
Zbuduje swoje bezpieczne środowisko AWS.
