Pojawienie się usług chmurowych bardzo mocno zaburzyło tworzenie i projektowanie systemów. Z jednej strony wraz za chmurowymi rozwiązaniami istnieje rzesza fanów, którzy każdy projekt by w nich tworzyli. Jednak po drugiej stronie barykady mocno działa duża ilość osób, które uważają chmury za błąd i tymczasowy trend, który NIGDY się nie sprawdza.
W tym artykule chciałbym pokazać zastosowania obu rozwiązań. Szczególnie mocne uwidocznić zalety jak i wady. Mam nadzieję wystarczająco podkreślić, że każde z rozwiązań wpisuje się w mantrę dobrego konsultanta „TO ZALEŻY”. Zapraszam więc do lektury.
Każdy z wdrażanych systemów, jeszcze przed powstaniem powinien mieć wyklarowane drivery architektoniczne. To dzięki nim wiadomo na czym można się skupić i o czym trzeba pamiętać przy realizacji projektu. Powinny paść pytania czy system ma być skalowany? Czy może system ma być tani? Czy może system ma być zawsze dostępny? Czy mamy doświadczony zespół? To właśnie one są drogowskazem do tego co będziemy wykorzystywać w trakcie ich projektowania. Jak i w ostatecznym upublicznieniu dla grona klientów. Abstrahując czy wykorzystujemy sposób iteracyjny czy może coś bliższego modelu kaskadowemu.
Dlaczego chmury?
Właśnie tutaj sama idea chmur miała wspomóc i rozwiązać problemy, które często są powiązane z pewną grupą systemów.
Jednym z kluczowych elementów, jest umożliwienie skalowalności przy dużej ilości użytkownik, bez utrzymywania całego działu devopsów/sysopsów… Dokładnie dla takich problemów chmura jest często dobrym wyborem. Sama idea podejścia, żeby każdy deweloper w prosty sposób mógł wrzucić w chmurę projekt jest motorem napędzającym nowych klientów. Znam firmy, gdzie dzięki takiemu podejściu zespół 3-4 devopsów jest w stanie obsługiwać 100-600 mikroserwisów. W chmurze nie jest to aż straszne. Gdzie mimo skali, ilość problemów jest skupiona na rozwiązaniach, a nie męczeniem się ze sprzętem i infrastrukturą. Jeśli ktoś uważa, że można osiągnąć podobny rezultat w On-Premise, w podobnym czasie i nie mając wyjadaczy, to zapraszam do dyskusji.
Co zrobić, żeby uzyskać taki sam efekt na własnych serwerach?
Pierwsze co mi przychodzi na myśl to, że jest niezbędny jest dobry zespół osób, z dużym doświadczeniem i wiedzą.
Oczywiście może to być outsourcing, jednak doświadczenie może być mocno negatywne. Znalezienie dobrej firmy outsourcingowej, może być bardzo bolesne i kosztowne.
Kolejnym krokiem to wypada znaleźć serwerownie godne zaufania, takie, z którymi można w prosty sposób się skontaktować.
Warto wspomnieć, że przez zespół jest wymagana do stworzenia cała infrastruktura.
Pamiętajmy, że zrobienie i zaprojektowanie infrastruktury wymaga czasu i testów.
Utrzymanie, żeby to działało i było sprawne 24/7 wymaga także nakładu zasobów.
Częste audyty bezpieczeństwa i bezpieczeństwa danych są kluczowe dla niektórych instytucji.
I wiele innych czynności, które generują koszta.
W przypadku niektórych problemów może być to bardzo opłacalne i może powodować, że mamy dużą kontrolę nad narzędziami. Przez to koszta się zaczną zwracać. Plusem dużym jest to, że zespół IT decyduje nad czym trzeba popracować i w jakim kierunku rozwiązania mają ewoluować. Istotnym przykładem problemów z cloudem jest usługa IoT na GCP, którą Google niespodziewanie zamyka. I wszyscy użytkownicy muszą szybko migrować na inne rozwiązania. W przypadku własnych rozwiązań takich problemów nie ma.
Przy rozwijaniu infrastruktury oczywiście większość etapów można zlecać, lecz finalnym punktem takiej delegacji zasobów jest chmura lub inny rodzaj jak np. platform as a service.
W tym całym procesie trade-offów kryje się zawsze wiele zależności. Jeśli się zaczynamy zastana nad wyborem chmury czy prywatnego serwera, więc niezbędna jest dobra analiza potrzeb.
Warto zwrócić uwagę na fakt, że w chmurach jeśli ktoś nie ma doświadczenia to pojawia się istotny problem. Kwoty chmury mogą osiągnąć zatrważające wartości. Co zdarza się, że powoduje wpisy na blogach „Mieliśmy chmurę, ale rachunek nas zaskoczył”, lub „Uciekamy z chmury na coś lepszego”.
W projektach, które miałem okazję współtworzyć za dużą ilość ruchu w skali Europy, rachunek wynosił $120. Jednak zdarzały się projekty, gdzie dobra infrastruktura na własnych serwerach minimalizowała koszt nawet rzędu 70%. Tutaj problemy, które można było spotkać opierały się na danych real-time i uczeniu maszynowym.
Dlaczego lubię hybrydę/multicloud?
Obecnie jestem fanem albo podejścia multi-cloud lub hybrydy.
Oznacza to, że rozbija się usługi w taki sposób by wynieść jak największą korzyść. Przykładowo jeśli mamy aplikację związaną z ML, uczymy modele na własnych serwerach, które to potem wrzucamy na bucketa S3 i wywołujemy przez API za pomocą lambd, może być lepszym rozwiązaniem niż trzymanie wszystkiego w chmurze czy na własnym serwerze. Lub ucząc model na GCP, gdzie mamy specjalne jednostki TPU, możemy go wykorzystywać na chmurze Azure w swojej aplikacji.
Wnioski
Mając świadomość o wielu aspektach rozwiązań, nie można powiedzieć, że któreś rozwiązanie będzie zawsze gorsze lub lepsze. Każdy problem powinien być rozważany indywidualnie i w zależności od driverów architektonicznych kalkulowany. Jedynie to co bym zaczął doradzić to brać pod uwagę więcej niż jednego vendora.