"Co właściwie da mi przejście na chmurę?" --- to pytanie można usłyszeć bardzo często, czy to w kontekście dużej organizacji, która staje przed wyborem dostawcy clouda, czy też w niewielkiej firmie, której proponujemy nowe rozwiązanie, niejako z jej perspektywy rewolucyjne i być może nieco przerażające. Bo jak to tak --- od tego momentu nie potrzebujemy maszyn, nie musimy nic utrzymywać? Co z kosztami, bezpieczeństwem oraz wsparciem jeśli coś przestanie działać? Rzeczywistość okazuje się z jednej strony nie tak kolorowa jak dostawcy chmury ją pokazują, z drugiej strony nie jest też tak straszna, jak sami ją widzimy.
Jakie firmy najbardziej skorzystają na chmurze?
Mnie osobiście nurtowało jednak jeszcze jedne, dość elementarne pytanie --- czy w przypadku chmury "rozmiar ma znaczenie"? Czy zachęcając mojego klienta (niewielki start-up) do wybrania np. Azure, kręcę na siebie bicz czy raczej otwieram przed nim nowe perspektywy? Okazuje się, że jak zwykle prawda leży gdzieś po środku.
Historia wygląda mniej więcej następująco --- mamy dwie firmy, jedna to duża korporacja związana z urządzeniami medycznymi, druga to niewielka działalność, która produkuje własne urządzenia IoT i zarabia dostarczając swoim klientom raporty na podstawie danych z tychże urządzeń. Nie ma sensu tutaj porównywać skali, gdyż ani nakłady finansowe, ani regulacje prawne nie będą współmierne w wymienionych przypadkach. Okazuje się jednak, że w codziennej pracy problemy, na jakie napotykamy projektując chmurowe serwisy, są jak najbardziej zbliżone. Zanim jednak przejdę do podobieństw, chciałbym poświęcić chwilę na pokazanie gdzie mimo wszystko oba tematy podążają w całkowicie innym kierunku.
Chmura w małej firmie
Bez zbędnych poszukiwań pierwszą rzeczą, która przychodzi mi do głowy, są koszty. Nie chodzi tu jednak o miesięczną fakturę (która jak wiadomo będzie się zapewne różniła kilkoma zerami) a raczej sposób, w jaki firma przelicza pieniądze wydane na chmurę na realny zysk. Jeśli mamy np. 10000 urządzeń i każde urządzenie daje nam 1 PLN, łatwo obliczyć, że miesięczny przychód to równe 10000 PLN. Teraz pojawia się pytanie --- jaki procent przychodu możemy poświęcić na utrzymanie rozwiązania w chmurze i dlaczego mamy się na takowe zdecydować, jeśli obecne (tradycyjne on-premises) jest dwa razy tańsze? Jeśli jest to jednoosobowa działalność gospodarcza, liczy się każda złotówka. Takiego klienta nie jest łatwo przekonać, że chmura to rozwiązanie dla niego --- bo czy warto inwestować dodatkowe pieniądze jeśli profity są niewidoczne?
Odpowiedź jest prosta --- oczywiście, że tak! Przecież zostawiając w tyle staromodne maszyny wirtualne i przechodząc na model PaaS, zyskujemy coś znacznie bardziej wartościowego --- czas. Nie musimy zajmować się obsługą, kontrolą i aktualizacją naszych maszyn i oprogramowania. Nie musimy ich administrować, zarządzać dostępami i zabezpieczać samodzielnie. Jeśli tygodniowo poświęcaliśmy na to 1h, w skali miesiąca może okazać się, że dodatkowe pieniądze zainwestowane w clouda zwrócą się po kilku tygodniach --- reszta to czysty zysk. To są oczywiście tylko zgrubne kalkulacje, nie są mimo wszystko całkowicie oderwane od rzeczywistości. Szczerze mówiąc całkiem niedawno sam postawiłem siebie w roli sprzedawcy, kiedy to postanowiłem przepisać przestarzały system mojego klienta, oparty całkowicie o PHP, MySQL, kilkanaście CRONowych jobów --- wszystko to na jednej maszynie wirtualnej --- na nowoczesną aplikację bazującą całkowicie na komponentach PaaS oraz serverless w chmurze Microsoftu. Cel był prosty --- zaproponować rozwiązanie o identycznej funkcjonalności, usuwając jednocześnie wszelkie problematyczne miejsca starego softu (wysycanie połączeń sieciowych, wadliwa architektura gdzie jeden element blokował inne, pogarszający się performance) oraz dotychczasowego dostawcy infrastruktury (niespodziewane downtime'y serwera, kiepski support, zerowa skalowalność). Kosztowało mnie to sporo czasu i było dość ciekawym ćwiczeniem umysłowym, koniec końców skończyłem jednak z propozycją rozwiązania, która szacunkowo mieści się w granicach 200zł --- tyle ile dotychczasowy serwis. Jest to niewiele mając na uwadze następujące kryteria:
- obsługujemy ponad 100 mln zdarzeń z urządzeń i z łatwością obsłużymy dwa razy więcej,
- poszczególne komponenty są odseparowane dzięki czemu np. problem przy zapisie nie rzutuje na odczyt,
- jednym suwakiem w portalu chmurowym wyskalowujemy wybraną usługę przy zerowym downtime jeśli brakuje nam mocy obliczeniowej,
- nie martwimy się aktualizacją składowych infrastruktury i ich monitorowaniem --- jest to odpowiedzialnością naszego dostawcy,
- z łatwością możemy automatyzować wdrożenia, m.in. dzięki wielu wbudowanym integracjom.
Przykłady można by mnożyć i mnożyć. Ćwiczenie to jednak pokazuje, że chmura ani nie musi być droższa, ani nie musi komplikować pracy, co więcej --- nawet ją ułatwia.
Korzyści z chmury w dużej organizacji
Sprawa wygląda nieco inaczej w dużej firmie. Tutaj nikt nie będzie się kłócił o to, czy jest zasadność płacenia 500 PLN czy 1500 PLN za jedno bądź drugie rozwiązanie, jeśli dostarcza wartość biznesową jaka była oczekiwana. Można się tutaj kłócić, że nie jest zasadne płacenie 3x za podobnie działającą aplikację, z drugiej strony w korporacjach nie ma aż tak dużego nacisku na optymalizację kosztów od samego początku. To jest ta różnica w kosztach o których wspominałem --- całkowicie inaczej patrzymy na wydatki jeśli dane rozwiązanie pochłania 10% naszego przychodu a inaczej, kiedy jest to niemalże niezauważalne (a przynajmniej niewidoczne na pierwszy rzut oka). Co więcej chmura w dużych firmach to nie tylko development. Tutaj często dochodzą usługi SaaS (PowerBI, Office 365 i inne), premium support, integracja z Active Directory i inne, których wartości nie da się często tak łatwo policzyć.
Drugą rzecz, która według mnie różni małe i duże przedsiębiorstwo jeśli chodzi o chmurę, to sposób w jaki podchodzi się do optymalizacji rozwiązania. Przytoczę tutaj kolejny przykład klienta, u którego zdecydowaliśmy się na całkowitą rezygnację z tradycyjnej, relacyjnej bazy danych i przenieśliśmy całość do Azure Table Storage. Dla osób, które niezbyt się orientują w usługach chmury Microsoftu --- Table Storage to usługa służącą do magazynowania danych (nierelacyjna baza danych), gdzie są one umieszczane w tabelach, które optymalnie może odpytywać tylko po dwóch predefiniowanych kolumnach (tzw. Partition Key oraz Row Key). Powodów dla rezygnacji z bazy SQL było kilka:
- potrzeba przemodelowania domen biznesowych pod kątem nowego rozwiązania, w którym wiele elementów nie było naturalnie połączonych,
- obniżenie kosztów związanych z utrzymaniem i obsługą bazy danych,
- lepsza integracja z innymi komponentami systemu (zaczęliśmy wykorzystywać m.in. Azure Functions),
- nacisk na pojemność magazynu a nie jego performance,
- niewielka różnorodność zapytań do bazy.
W powyższym rozwiązaniu był jeden główny problem --- ponieważ Table Storage nie ma możliwości utworzenia relacji pomiędzy tabelami, a jakiekolwiek zapytanie bez Partition Key bądź Row Key jest niesamowicie kosztowne, sporo czasu poświęciliśmy na zarówno poprawne zamodelowanie poszczególnych tabel, jak i ich poprawne odpytywanie. W ruch poszło tu wiele wzorców jeśli chodzi o zapis i odczyt danych w optymalny sposób. Wszytko to aby utrzymać koszty rozwiązania na odpowiednim poziomie (a jednocześnie obronić koncepcję). W przypadku dużej firmy taka sytuacja rzadko ma miejsce --- albo wybieramy najprostsze rozwiązanie płacąc odpowiednio więcej (w opisywanym przypadku teoretycznie można było przejść po prostu na Azure SQL --- było to jednak zarówno droższe jak i mniej "dopasowane" rozwiązanie patrząc na charakter danych składowanych w bazie), albo czekamy z optymalizacjami do momentu, aż będą nieuniknione. Nie mówię tutaj oczywiście o poważnych niedopatrzeniach, które automatycznie zabijają rozwiązanie na produkcji. Chodzi bardziej o sytuacje, kiedy to unikamy płacenia za coś, czego można by uniknąć (jak np. odczytywania całej partycji w Table Storage przy źle skonstruowanym zapytaniu --- ważne jest, że w tej usłudze płacimy za przeczytanie KAŻDEGO rekordu).
Typowe wady i zalety rozwiązań chmurowych --- niezależne od skali organizacji
Jak jednak wygląda sprawa podobieństw, o której mówiłem na samym początku? Warto tutaj zacząć od dość wysokiego progu wejścia w chmurę, który dotyka zarówno mały startup jak i wielką korporację. Zrezygnowanie z tradycyjnego modelu on-premises gdzie kontrolujemy i zarządzamy wszystkim oraz niejako danie kredytu zaufania dostawcy chmury to często spore wyzwanie. Duże firmy mogą tutaj mieć z górki (większe pieniądze oznaczają często dodatkowy support i dedykowanych specjalistów), mimo to nie jest to przedsięwzięcie na jeden tydzień. Gdy wprowadzałem chmurę u mojego klienta, pojawiało się mnóstwo pytań o to jakie są gwarancje, że dana usługa będzie działać. Ta gwarancja to SLA czyli Service Level Agreement zdefiniowane dla każdego komponentu clouda --- jest ono niezmienne bez względu na to, jaką miesięczną fakturą możemy się pochwalić.
Należy zauważyć tutaj jeszcze jedną rzecz --- niezależnie od tego ile osób zatrudniamy, chmura publiczna nie gwarantuje nam żadnej rekompensaty (poza tą wynikającą z SLA) jeśli podczas downtime'u krytycznej dla nas usługi stracimy pieniądze. Innymi słowy --- możemy odzyskać tylko i wyłącznie pieniądze zainwestowane w daną część infrastruktury chmurowej --- zyski wynikające z prowadzonej przez nas działalności się niejako od tego odcięte. Bez względu na wielkość naszego projektu, zawsze musimy liczyć się z tym, że może zaistnieć sytuacja losowa, która go "uziemi". Bardzo ważne jest odpowiednie zaprojektowanie takiego systemu z uwzględnieniem wszystkim wrażliwych elementów. Przykładowo --- wracając na chwilę do opisywanej wczesnej firmy z urządzeniami IoT, podczas projektowania rozwiązania zadaliśmy sobie pytania na ile dane zgromadzone z urządzeń (na podstawie których budowane są raporty dla klientów) decydują o losie całego przedsiębiorstwa. Doszliśmy do wniosku, że model LRS (Locally Redundant Storage --- 3 repliki danych w ramach jednego datacenter) wybranego magazynu będzie niewystarczający z punktu widzenia bezpieczeństwa firmy i wygody klientów, dlatego też wybraliśmy model RA-GRS (3 kopie lokalnie + 3 kopie w całkowicie innym regionie z dostępem Read Only). Można tutaj zadać pytanie co jeśli stracimy dane także w drugim regionie --- myślę, że jednak zawsze warto kierować się zdrowym rozsądkiem i nie komplikować rozwiązania jeśli nie ma ku temu solidnych podstaw. Nie należy także mylić tego z backupem, który powinien być integralną częścią naszego systemu, jednak sam w sobie nie gwarantuje wysokiej dostępności aplikacji.
Ostatnim elementem wspólnym, o którym chciałbym wspomnieć w tym wpisie, jest bardzo pozytywny aspekt chmury, który być może wynika z mojego deweloperskiego backgroundu, osobiście stawia ją jednak powyżej starym rozwiązaniom opartym o IaaS --- skupienie się na faktycznym developmencie a nie walce i konfiguracji infrastruktury. Obecnie z sentymentem wspominam początki mojej kariery, kiedy to za każdym razem, gdy zaczynaliśmy projekt, musieliśmy organizować maszyny, instalować odpowiednie oprogramowanie, dbać o odpowiednie ustawienia. Dochodził także element zapewnienia bezpieczeństwa jak kontrolowanie otwartych portów, zapewnianie połączenia VPN dla klienta. To wszystko nie ograniczało się tylko to lokalnej pracy --- to samo trzeba było wykonać na produkcyjnych maszynach a potem je utrzymywać. Patrząc z perspektywy czasu mnóstwo czasu było poświęcanego na czynności, które chmura rozwiązuje od razu. Obecnie pracując zarówno nad tymi wielkimi jak i drobnymi projektami mam poczucie, że skupiam się na dowiezieniu jakościowego rozwiązania i budowie własnych umiejętności, unikając jednocześnie powtarzalnych i unikalnych czynności, które skutecznie odbierają przyjemność z pracy. Budujące jest to, jak np. mój obecny zespół ma czas na zrobienie kilku prototypów architektury budowanego systemu szukając optymalnego rozwiązania. Wszystko to dzięki temu, że nie tracimy czasu na zastanawianie się jak uruchomić i połączyć poszczególne elementy, PaaS robi to za nas.
O chmurze w organizacjach różnej wielkości można by zapewne mówić jeszcze długo, mam jednak nadzieję, że udało mi się przedstawić te podstawowe elementy, na które ja najbardziej zwróciłem uwagę. Czy więc w przypadku chmury "rozmiar ma znaczenie"? Koniec końców wydaje mi się, że nie. Mogą pojawiać się różnice na poziomie kompetencji (dużej firmie łatwiej zatrudnić wielu świetnych specjalistów), wsparcia technicznego (większe organizacje mogą się pochwalić różnymi dodatkowymi umowami z dostawcą, które mogą zapewniać dodatkowe benefity) czy możliwości, jednak koniec końców i w start-upie i w korporacji najbardziej wartościowe jest to samo. Chmura przyśpiesza development, bierze na siebie część odpowiedzialności (jak np. utrzymanie i konfigurowanie infrastruktury), pozwala zredukować niepotrzebne koszty i zaoszczędzone pieniądze zainwestować gdzie indziej. Co więcej cała obecna rewolucja chmurowa to coś, co nie zatrzyma się za rok. Opóźniając (bądź unikając) przejście na clouda niejako sprawiamy, że nasza konkurencyjność będzie niższa. Wszystkie te wartości są tak samo ważne u mniejszych oraz większych graczy, dlatego też nie należy się bać bujania w obłokach, jeśli jednocześnie będziemy stać twardo na ziemi.
