Czym jest Cloud native?

Ostatnio z Piotrkiem Tomaszewskim na Clubhouse prowadziliśmy ciekawą dyskusję na temat Cloud native, agnostic, multi-cloud. Jedną z ciekawych rzeczy z tej dyskusji jest to, jak szeroko rozumiemy pojęcie Cloud native. Jeżeli chodzi o mnie, to pod pojęciem Cloud native rozumiem dwie rzeczy.

Jeżeli chcesz zobaczyć notatkę z dyskusji w pełnym rozmiarze to znajdziesz ją tu

Cloud native rozumiany jako wykorzystanie natywnych usług dostawcy, czyli korzystamy z PaaS, SaaS (czy jak to woli serverless) do budowy aplikacji. Sam jestem za tą definicją.

Jeżeli używamy paradygmatów danego dostawcy do budowy, to w wielu przypadkach powinno udać się to zrobić poprawnie, szybko itp. Niektórzy mówią, że to vendor native, albo vendor lock, tylko często Ci sami ludzie w kluczowych rozwiązaniach są zapięci do Oracle, Sapów, rozwiązań IBM i jakoś pogłębiają często miłość do tego dalej.

Czy jest to złe? Jeżeli wiesz, co robisz, to nie ma sensu walczyć z tym. Jednym ze sposobów jest niestawianie wszystkiego u jednego dostawcy, czyli tak zwane dual-vendor strategy. Najprostszym sposobem jest to, że 65-70% (patrząc po kosztach) aplikacji, stoi u jednego dostawcy chmury, a reszta u drugiego.

Drugim typem narzekających na vendor lock i natywność chmury są ludzie zakochani w Kubernetes i CNCF. W tym momencie pojawia się druga definicja, czyli Cloud native by CNCF.

Tutaj rozumiemy to, że budujemy aplikację z wykorzystaniem rozwiązań, które pojawiają się w ekosystemie Cloud Native Computing Foundation, albo w okolicach (na przykład hype po KubeCon).

W teorii Kubernetes i wszystkie zabawki wokół adresują dużo rzeczy, pomagają, a nawet w jakiś sposób dają obietnicę, że aplikacja może być cloud-agnostic czy multi-cloud.

W praktyce rozwiązania te na pozór połączone, przy bardziej rozbudowanych architekturach tracą ten magiczny klej i potrzeba mieć w zespole magików od tego, a to tylko strona „infrastruktury”. Po stronie samego kodu ludzie też muszą co nieco wiedzieć. Oczywiście podeście z rozwiązaniami CNCF w mojej opinii mają rację bytu, wszystko zależy od skali i potrzeb. Co do skali to nie będę teraz wchodził na temat, co rozumiem przez duży projekt ;-).

Co do potrzeb to bywa różnie – dobry przykład w Polsce to regulacje dla banków w rozumieniu KNF i testowanego, wykonywalnego planu wyjścia z chmury (szczególnie awaryjnego).

Inne podejście do Cloud native by CNCF, z którym miałem styczności i daje radę to przykład, gdzie zespół platformowy udostępnia np. namespaces w Kubernetes i zespół aplikacyjny może sobie wybrać: może PaaS, może serverless, a może jednak K8s pasuje lepiej.