Cloud Native computing przede wszystkim nie jest technologią, nie jest narzędziem. Cloud native to jest podejście do tworzenia rozwiązań cyfrowych. Podejście, które z założenia wykorzystuje wszystkie możliwe benefity płynące z infrastruktury cloudowej i tego, że nasza aplikacja, nasz system jest w tej infrastrukturze osadzony. Jest taka organizacja CNCF – Cloud Native Computing Foundation, która definiuje cloud native jako “zestaw technologii, narzędzi i procesów, które mają służyć organizacjom do tworzenia skalowalnych aplikacji w nowoczesnych infrastrukturach cloudowych czy to publicznych czy prywatnych czy hybrydowych”.
Możemy sobie całą infrastrukturę cloud native podzielić na cztery warstwy. Pierwsza to jest warstwa aplikacyjna, czyli ta, w której programista pracuje bezpośrednio na aplikacji. Rozmawiamy tutaj o bazach danych, o obrazach kontenerów, o rozwiązaniach przesyłu informacji, wiadomości, o pipeline’ach CICD.
Drugą warstwą jest warstwa zaopatrzenia – warstwa środowiskowa. Tutaj rozmawiamy o środowisku, w jakim warstwa aplikacyjna jest osadzona. Tutaj pojawiają się takie pojęcia jak Infrastructure as a Code, repozytorium, rozmawiamy o kwestiach bezpieczeństwa.
Trzecią warstwą jest warstwa uruchomieniowa. Czyli to w jaki sposób nasza infrastruktura rozmawia z naszą aplikacją. Wszystkie punkty styku. Tam gdzie potrzebujemy uruchomić daną funkcję, wywołać daną komendę.
I ostatnią warstwą jest już taka głęboka warstwa infrastrukturalna, warstwa orkiestracji. Czyli to jak my w ogóle podchodzimy do zarządzania naszą infrastrukturą cloudową i w jaki sposób ona się integruje z innymi, trzecimi aplikacjami, na przykład poprzez API.
Zalety Cloud Native
Jakie są zalety tworzenia rozwiązania cyfrowego z podejściem cloud native? No to w zasadzie taka aplikacja, taki system korzysta przede wszystkim ze wszystkich benefitów chmury.
Porównując cloud do rozwiązania on-premise, które jest aktualizowane na przykład raz do roku, a jak się nic nie dzieje to czasem w ogóle, cloud native oferuje stałe aktualizacje komponentów naszego systemu. Korzystamy z gotowych elementów dostarczanych nam przez producentów rozwiązań chmurowych, takich jak AWS, Microsoft Azure czy Google. Więc cały komponent, na przykład ekran logowania jest nam dostarczany przez tego producenta. Co znaczy, że jest on aktualizowany i rozwijany w sposób ciągły. My nie musimy zajmować się aktualizacją, utrzymaniem i rozwojem tego konkretnego elementu, więc mamy trochę mniej pracy. Ponadto te firmy bardzo dużo energii wkładają w to, żeby utrzymywane, dostarczane przez nich produkty, rozwiązania były wysokiej jakości. Więc najprawdopodobniej rzeczywiście będą wyższej niż te, które są aktualizowane i rozwijane in house, u nas w infrastrukturze on premise.
High Availability – HA, czyli wysoka dostępność. Dostawca rozwiązań chmurowych dba o to, zapewnia takie procesy infrastrukturalne, takie procesy backupowe, że choćby nie wiem co się działo, to rozwiązanie jest dla nas dostępne. To z kolei przekłada się na mniejszy downtime aplikacji i wyższe zadowolenie użytkowników.
Bezpieczeństwo. Dostawcy rozwiązań chmurowych zatrudniają ekspertów od cybersecurity czy w ogóle od bezpieczeństwa całej infrastruktury, którzy bardzo często są topowymi specjalistami w branży. Dbają o to, żeby nasze rozwiązanie w warstwie infrastruktury było bezpieczne.
Skalowalność. To znaczy, jeżeli nasz biznes doświadcza pewnego typu sezonowości i wiemy, że w tych miesiącach potrzebujemy więcej zasobów, potrzebujemy dodatkowych serwerów, node’ów, no to nie ma w ogóle problemu, żeby takie środowisko zeskalować. To zwykle trwa od kilkudziesięciu minut do kilku dni, zależy od tego jak skomplikowaną operację chcemy przeprowadzić, natomiast porównując to do infrastruktury on premise, czas przeskalowania takiego systemu jest wielokrotnie krótszy. Wyobraźcie sobie domawianie od zewnętrznego dostawcy dodatkowych serwerów, konfigurację ich itd. To są nieporównywalne czasy reakcji. Dalej pojawia się kwestia kosztów przy skalowaniu infrastruktury. Płacimy rzeczywiście za to, z czego korzystamy. Więc jeżeli mamy wzmożony ruch w naszej aplikacji, na przykład jesteśmy rozwiązaniem typu e-commerce i jest black friday, no to bardzo łatwo jest tę infrastrukturę zeskalować w górę, ale też w dół. Bo jeżeli z kolei mamy przestój i nie potrzebujemy tak obszernej infrastruktury, no to możemy bardzo łatwo zrezygnować z części kupowanych usług i po prostu mniej w tym okresie płacić.
Multitenancy. Chyba nie ma polskiego odpowiednika. Po prostu chodzi o to, że poszczególne elementy aplikacji, które przetrzymujemy w infrastrukturze cloudowej mogą funkcjonować na tych samych zasobach, co inne elementy tej aplikacji, tego rozwiązania. Co zwykle w świecie on premise jest problematyczne.
Downtime aplikacji. Czyli ze względu na to, że korzystamy z centralnych rozwiązań, które są dostarczane nie tylko dla nas, ale dla wielu, dla setek, dla tysięcy firm na świecie możemy liczyć na to, że dobre praktyki, procesy w ramach których poukładana jest ta infrastruktura i usługi, z których korzystamy, zapewnią nam najkrótszy możliwy downtime. Czyli można powiedzieć, że takie rozwiązanie tworzone w ramach podejścia cloud native jest po prostu bardziej stabilne.
Możliwości automatyzacji. Czyli jeżeli tworzymy oprogramowanie z podejściem cloud native, mamy do dyspozycji więcej narzędzi, które ułatwią nam pracę, które ograniczą zasoby, z których potrzebujemy korzystać, żeby dostarczać to rozwiązanie do użytkowników. W ogóle świat przestawia się na podejście cloud native, w związku z czym rynek też patrzy w tą stronę. No i mamy tutaj więcej narzędzi, rozwiązań, produktów wspierających właśnie tego typu podejście.
Wady Cloud Native
To też nie jest tak, że Cloud Native jest bez wad. Minusy tych rozwiązań są, ale najczęściej będą dotyczyły długu technologicznego. Czyli kiedy organizacja ma jakąś aplikację, jakiś system postawiony w ramach on premise i będzie chciała zmigrować takie rozwiązanie do chmury. Będzie to bardzo trudne. Bardzo często sprowadza się do ogromnej inwestycji i stworzenia całego rozwiązania od nowa w podejściu cloud native. Dlatego że to jak prowadzone były procesy, jak budowane było to rozwiązanie w on premise jest jednak dalekie od tego, co jest potrzebne w chmurze, aby aplikacja korzystała z benefitów chmurowych w pełni. Więc w zasadzie największą wadą podejścia cloud native jest to, że trudno przerzucić do tego frameworku aplikację, która powstawała “w starym stylu”. I to jest poważny problem dla dużych organizacji, które przez lata inwestowały w rozwiązanie zbudowane na infrastrukturze on-premise. W wielu takich przypadkach zmiana podejścia dla kluczowego systemu na cloud native nie będzie miała sensu.
Obejrzyj film:
