Bardzo wiele istniejących aplikacji zostało stworzonych jako monolity. Oznacza to, że cały system jest obsługiwany przez jedną aplikację, która jest efektem pracy wszystkich osób współpracujących ze sobą. Ponieważ monolit jest jedną, spójną całością to czas, jaki jest potrzebny, na opublikowanie jej nowej wersji jest dłuższy, a skoordynowanie prac pomiędzy poszczególnymi zespołami programistycznymi, jest sporym wyzwaniem. Dlatego od kilku lat rekomendowane jest stworzenie swojego systemów w formie mikroserwisów, które ze sobą współpracują.
Co to jest Cloud native?
Cloud native, jest to elastyczna metoda tworzenia nowych aplikacji, które wykorzystują skalowalność, oraz elastyczność chmury. To właśnie dzięki podejściu cloud native, jesteśmy w stanie zbudować aplikację, która będzie w stanie okiełznać wszystkie dostępne możliwości chmury, oraz pomoże rozwiązać większość wyzwań związanych ze skalowaniem. Mikroserwisy, to zazwyczaj małe moduły, które mogą pracować niezależnie od siebie, natomiast, mogą one być zależne od innych mikroserwisów lub warstw dostępnych danych. Kluczem do sukcesu jest tutaj stosowanie luźnych powiązań. Aplikacje cloud native, tworzone są za pomocą wielu niezależnych elementów, tak zwanych mikrousług, które wdrażane są w środowiskach chmurowych. Pamiętaj o tym, że każda z Twoich aplikacji, obciążeń czy zbiorów danych ma swoje własne, wyjątkowe wymagania, dlatego musisz być otwarty na wiele rozwiązań.
Kluczowe atrybuty Cloud native.
Jedno jest pewne, przyjdzie taki moment, że cloud native będą dominować, według prognoz analityków rynkowych do roku 2020, a więc już teraz ruch chmurowy ma stanowić 92% całego ruchu, który jest tworzony przez centra danych. Dlatego przyjrzyjmy się bliżej zaletom, jakie oferuje nam cloud native:
- mikrousługi – są luźno powiązane między sobą i istnieją niezależnie od innych usług, dzięki czemu infrastruktura, oraz architektura aplikacji jest elastyczna. A jeżeli mikrousługi są poprawnie zintegrowane, to mogą bez trudu być skalowane w celu zwiększenia wydajności
- pakowane są jako kontenery – aplikacje natywne, są zbiorem niezależnych, oraz autonomicznych usług, które pakowane są w kontenery, dzięki czemu można je szybko migrować z jednego serweru na drugi bez konieczności zmiany ustawień
- opracowane są przy użyciu najlepszych języków oraz struktur – każda usługa w aplikacji jest opracowana przy użyciu takiego języka, oraz struktury, która jest najlepiej dopasowana do jej funkcjonalności. Aplikacje natywne w chmurze znają wiele języków, a co za tym idzie, usługi używają różnych języków, środowisk uruchomieniowych oraz struktur
- skoncentrowane są wokół interfejsów API do integracji oraz współpracy – usługi natywne używają w chmurze lekkich interfejsów API, które oparte są na protokołach, takich jak reprezentacyjny transfer stanu (REST), zdalne wywołanie procedur Google open source (gRPC) czy NATS
- izolowane są od zależności serwera, oraz co ważne systemu operacyjnego – cloud native, nie mają powinowactwa do żadnego konkretnego systemu operacyjnego, lub jednego komputera, co daje im niezależność
- wdrażane są w samoobsługowej, elastycznej infrastrukturze chmurowej – co oznacza, że aplikacje cloud native, wdrażane są w wirtualnej, współdzielonej, oraz elastycznej infrastrukturze, dzięki czemu mogą się dopasowywać do podstawowej infrastruktury, tak aby dynamicznie rosnąć, oraz kurczyć się, w zależności od zmiennych obciążeń
- zarządzane zgodne z metodyką DevOps – każda usługa aplikacji cloud native, przechodzi niezależny cykl życia, który jest zarządzany zgodnie z metodyką DevOps, co zwiększa jej automatyzację, oraz efektywność
- zautomatyzowane możliwości – aplikacje natywne dla chmury, mogą być bardzo mocno zautomatyzowane, dzięki czemu wszystko działa płynnie, oraz bezproblemowo
- alokacje zasobów oparte są na zdefiniowanych zasadach – aplikacje cloud native dostosowują się do modelu zarządzania zdefiniowanego za pomocą zestawu zasad. Przestrzegają zasad, takich jak jednostki centralne (CPU) i przydziały pamięci, a także zasad sieciowych, które przydzielają zasoby do usług
Kiedy warto przejść z monolitu na mikroserwery?
Kiedy jednak jest odpowiedni moment na zmianę mikroserwisy? Poniżej przedstawimy kilka punktów, które będą świadczyć o tym, że ten czas już nadszedł:
- rosnące zależności aplikacji – we wczesnych fazach rozwoju prace posuwają się do przodu bardzo szybko, a nowe funkcje dostarczane są klientom często. Nie ma problemu z tym, aby wprowadzać na przykład nowe wersje systemu kilka razy w miesiącu. Zespół programistyczny nie jest duży, wszyscy się znają i wspólnie pracują nad rozwojem aplikacji. Jednak z czasem, wraz ze wzrostem liczby klientów, wzrasta też proporcjonalnie złożoność aplikacji. Poza podstawowymi funkcjami dochodzą takie jak na przykład raportowanie, administrowanie systemu, logowanie zdarzeń czy wysyłanie maili. W konsekwencji mały, sprawny zespół zaczyna się dzielić na mniejsze podzespoły, które zaczynają się specjalizować w danych obszarach aplikacji
- tworzenie nowych funkcji postępuje znacznie wolniej – oczywiste jest, że wraz ze wzrostem złożoności wydłuża się czas implementacji nowych funkcji. Codzienne zadania programistyczne zaczynają zajmować coraz więcej czasu, a budowanie, ładowanie się oraz testowanie aplikacji z każdą kolejną zmianą trwają dłużej. Czas od implementacji nowej funkcji do jej uruchomienia wydłuża się, skutkiem czego jest znaczący spadek produktywności programistów. Aktualizacje, które kiedyś pojawiały się kilka razy w miesiącu, teraz pojawiają się raz na pół roku, albo jeszcze rzadziej
- czas potrzebny na wdrożenia nowych funkcji jest coraz dłuższy – im dłużej pracuje się nad monolitem, tym bardziej wydłuża się czas potrzebny do wdrożenia nowych funkcji w aplikacji. Ponieważ wiele osób modyfikuje ten sam kod źródłowy, aplikacja bardzo często znajduje się w stanie niestabilnym. Pomimo tego, że każdy podzespół pracuje na osobnych gałęziach kodu, to dochodzi do konfliktów podczas łączenia pracy zespołów programistycznych
- skalowanie aplikacji jest utrudnione – coraz większa aplikacja monolityczna, to jak łatwo się domyślić coraz większe problemy ze skalowalnością. Rosną wymagania na takie zasoby jak procesor, pamięć RAM czy miejsce na dysku, które z czasem jest coraz trudniej spełnić. Kolejne funkcje systemu mają inne potrzeby, co nie zawsze da się ze sobą łatwo pogodzić, przykładowo część analityczna będzie bardziej polegać na wydajnym procesorze, a wzrost liczby użytkowników będzie prowadzić do większego zapotrzebowania na pamięć RAM
- utrudnione jest utrzymywanie niezawodności aplikacji – tworzenie niezawodnych aplikacji jest trudne, jeszcze trudniejsze jest to w przypadku monolitu, gdzie nietrudno o dużą liczbę błędów, oraz przerw w działaniu na produkcji. Im większa jest aplikacja, tym bardziej skomplikowany jest jej kod, co sprawia, że programiści gubią się we wszystkich zależnościach, testowanie trwa coraz dłużej, a eliminacja 100% błędów staje się nieosiągalna
- przywiązanie się do starzejącego się stosu technologicznego – gdy na konferencjach czy spotkaniach lokalnych grup programistycznych zaczynają padać żarty z technologii, w których ty nadal pracujesz, to znak, że w Twojej głowie powinna zacząć palić się wielka, czerwona lampka ostrzegawcza
Jak widać cloud native, to nowoczesne i bardzo przyszłościowe rozwiązanie, dla każdej firmy, która chce się dostosować do obecnych trendów, chce być równowartościowym partnerem dla swoich klientów, oraz chce nadążać za zmianami technologicznymi. Cloud native to doskonałe narzędzie, które w rękach zdolnych informatyków, będzie jak magiczna różdżka, która spełnia każde życzenie.
Jeśli planujesz wdrożyć u siebie rozwiązanie Cloud Native dobrze jest skorzystać z pomocy specjalistów, którzy mają doświadczenie w tych kwestiach. Takich firm nie ma zbyt wiele. Ja mam dobre doświadczenia z Transition Technologies PSC (https://ttpsc.com/pl/cloud/serverless-i-cloud-native/)