Czym jest ten cały Cloud Native

Na pytanie czym jest ten cały Cloud Native zdarza mi się odpowiadać dość często. Nie ma jednej dobrej odpowiedzi. Pięć osób będzie miało 10 odpowiedzi na ten temat. A ja także czasem mam nowe przemyślenia na ten temat. Na to pytanie postaram się odpowiedzieć za chwilę. Na razie odpowiedzmy sobie na pytanie

Po co idziemy do chmury?

No właśnie. To pytanie powinno się zadać każdemu, kto się wybiera do AWS, GCP lub Azure. Czego oczekujesz? Co chcesz osiągnąć? To jest najważniejsze pytanie. Jakich ja bym szukał plusów w chmurze? Oto one:

1. Obniżenie kosztów
2. Nowe możliwości
3. Elastyczność
4. Szybkość, zwinność
5. Ograniczenie nakładu pracy

Oczywiście nie wszystko na raz. Przynajmniej nie zawsze. Ale po kolei.

Obniżenie kosztów

Tak. Pewnie. Da się. Można też zmigrować się do chmury i płacić spoooooro więcej. Przeliczanie jeden do jednego z tym co mamy w on-premises nie ma najmniejszego sensu. To nie działa tak, że 2CPU i 16 GB RAM w pokoju obok lub u jakiegoś dostawcy hostingu w typie nazwa.pl czy home.pl będzie ekwiwalentem tego co dostaniemy np. w AWS. To trzy różne światy. Nie przeliczajmy tak tego. Aspekt kosztów łączy się bardzo z punktami 3 i 5 na liście powyżej. O tym za chwilę.
Tu trzeba też dobrze sprofilować swoje usługi. Miałem ostatnio do czynienia z klientem, którego maszyny wirtualnie były wykorzystane w 7%. Czyli 93% kasy płaconej dostawcy chmury szło do śmietnika. Nie przynosiło żadnej wartości. OH MY GOD!!! (Kto tak mówił w serialu Przyjaciele?).

Nowe możliwości

No pewnie. Masz u siebie w serwerowni usługi kognitywne odróżniające jabłka od gruszek na zdjęciach? Twój soft potrafi przełożyć mowę na tekst i przy okazji rozpoznać Twoje emocje i zaraportować czy masz negatywne czy pozytywne podejście do KFC lub Burger Kinga? Szczerze wątpię. Potrafisz ogarnąć miliony zgłoszeń na minutę z urządzeń IoT podpiętych do Twojego oprogramowania? Analityka spływających danych w czasie rzeczywistym? Masz serwerownie rozsiane po świecie blisko swoich klientów? Jeżeli tak, to daj znać. Pozytywnie myśląc, będziesz w jednym promilu użytkowników rozwiązań IT.

Elastyczność

Bingo!!! To jest naprawdę fajna przewaga chmur publicznych. Potrzebujesz jednego serwera. Mówisz (klikasz, używasz CLI lub innych zaklęć) i masz. Potrzebujesz 50? Kilka chwil i masz. No dobrze, tu też zdarzają się problemy. Pod tym względem tylko AWS mnie nie zawiódł. Szczególnie w początkowym okresie Covidu. I do tego te wszystkie nasze zabawki możemy skalować automatycznie w ramach potrzeb. Pokażcie mi własną serwerownię, gdzie maszyny wjeżdżają i wyjeżdżają w ramach potrzeb. Co sekundę.
Projekt nie wypalił? KPI nie spełnione. Chwila i środowisko usunięte. Żadnych kosztów.

Szybkość, zwinność

Na początku przeczytaj punkt wyżej. Potrzebujesz czegoś? Klik, klik i masz. Czy to proste PoC, czy projekt produkcyjny, infrastrukturę dostaniesz ASAP. 😉 Bez przetargów, telefonów do przyjaciela i przelewania ciężko zarobionej gotówki za towar, którego nie da się łatwo pozbyć. Nawet na OLX i Allegro. Przynajmniej w rozsądnych cenach.

Ograniczenie czasu pracy

Kto chciałby spędzać czas na przeciąganiu kabli sieciowych pomiędzy dzielnicami wielkiego miasta czy kontynentami? Kto lubi uaktualniać maszyny wirtualne albo serwery baz danych? Ile czasu spędziłbyś na uruchamianiu infrastruktury na dwóch kontynentach? A znacie kogoś kto lubi za to wszystko płacić? Przecież to nic nie wnosi do zarobku na biznesie. Koszmar. W chmurze możemy się tego wszystkiego pozbyć. Tego, a nawet więcej. Chcesz więcej? Słowo kluczowe – Serverless. Drugie słowo klucz – Infrastructure as Code. Też oszczędza czas. Wbrew pierwszemu wrażeniu.

No to jeszcze raz, czym jest ten cały Cloud Native

Pisałem już o tym, że Cloud Native to podejście. I z tym się nadal zgadzam. Ale rozszerzając temat… Podejście do Cloud Native to korzystanie z chmury jak z kolejnej biblioteki lub frameworka. Dlaczego?

Jak rozwijały się chmury

Abstrahując od pierwszej usługi w AWS, na początku mieliśmy maszyny wirtualne. Tak mniej więcej około roku 2010 (nie łapcie mnie proszę za datę). Potem weszła automatyka. Powiedzmy 2015. No i teraźniejszość (gdy to piszę). Serverless i Platform as a Service rozpychają się już nawet nie łokciami, ale dają kopniaki starszym technologiom.
No to teraz popatrzmy

Jak rozwijał się świat HR w IT

Szukaliśmy .Net lub Java developerów? Jasne. Tak w okolicach 2010. Ktoś jeszcze pamięta ASP 3.0? Potem nastąpiła era Django i Rails.
Kogo szukamy dziś? Jesteś AWS developerem? Azure Developerem? AWS Dev-Opsem? Takim prawdziwym. Masz problemy ze znalezieniem pracy? Nie sądzę. Jeżeli tak, napisz do mnie, coś wymyślimy. 😉

Klocki

Producent klocków Lego korzysta z chmury. Więc coś jest na rzeczy. Ale ja podejdę do tego od drugiej strony. Chmura to zestaw usług, czyli klocków. Tak w przybliżeniu 200 różnych klocków.

I z tych klocków budujemy nasze rozwiązania. Mniej lub bardziej udane. To już zależy od nas.
W swoich ostatnich projektach nie zastanawiałem się czy użyć Pythona, Django, czy .Net. Myślałem o tym jak z eventów, kolejek, notyfikacji i funkcji Lambda zbudować działające i skalowalne rozwiązanie. W ogóle nie myślałem na początku o tym jakich technologii, języków, frameworków użyję. Rozrysowałem sobie na kartce usługi AWS. I potem je połączyłem.
Zmiana? Dla mnie na pewno.
Wśród wybranych klocków nie ma maszyn wirtualnych. Często nie było też Dockera i Kubernetesa. To nie znaczy, że konteneryzacja nie może współuczestniczyć w Cloud Native. Docker i Serverless już często się przenikają .To znaczy tyle, że nie powinniśmy, moim zdaniem, utożsamiać tych dwóch technologii z Cloud Native, A tak się niestety często dzieje.

Cloud Native – definicja

Nie ma jednej. Co prawda Cloud Native Computing Foundation (w sumie to trochę śmieszne, że podejście ma swoją fundację) ma taką. Ale czy oddaje ona całą prawdę? Nie sądzę.
Dla mnie Cloud Native jest sposobem na wykorzystanie chmury. Na takie wykorzystanie, żeby nasi klienci byli zadowoleni, żeby nasze rozwiązania działały z jak najmniejszym naszym udziałem i żebyśmy płacili za to wszystko jak najmniej.
Dla mnie chmura to framework, z którego za każdym razem korzystam, a przynajmniej staram się, tak, aby osiągnąć zakładany cel i żebym za to nie musiał płacić więcej niż potrzeba. Wybieram klocki i składam je w całość.