Sukces firm i organizacji w 2020 roku, ale i w kolejnych latach, w coraz większym stopniu zależy i zależeć będzie od sposobu projektowania, budowania i użytkowania aplikacji. Coraz większa liczba zespołów IT zwraca się w stronę narzędzi programistycznych takich jak kontenery. W ten sposób można tworzyć aplikacje typu cloud-native, które działają spójnie działają w całej infrastrukturze chmury.

 REKLAMA 
 Baner srodtekstowy350x350 strona KSeF 
 
Skąd jednak czerpać wiedzę, które platformy kontenerowe są najbardziej odpowiednie dla naszej organizacji? Poniżej omówimy główne kwestie związane z wyborem platformy kontenerowej oraz przedstawimy porady dotyczące orkiestracji kontenerów w celu zarządzania cyklami ich życia. Wszystko to zapewni organizacji możliwość szybkiego skalowania i wprowadzania innowacji.

Jaki rodzaj kontenerów wybrać?

Skutecznie realizowana strategia rozwoju aplikacji w chmurze pozwala zapewnić firmom i organizacjom znaczącą przewagę konkurencyjną. Może ona zwiększyć szybkość rozwoju aplikacji, sprawić, że będą one bardziej elastyczne w stosunku do potrzeb organizacji, a także umożliwić skalowanie aplikacji w celu dopasowania ich do aktualnych potrzeb bez istotnych zmian w infrastrukturze. Kontenery są częścią tej strategii, ponieważ umożliwiają zaawansowaną automatyzację, która jest jedną z największych zalet rozwiązań chmurowych. Wynika z tego, że pełne wykorzystanie potencjału kontenerów jest jednym z kluczy do dobrze wdrożonej strategii chmury. Aby wszystkie działania przyniosły oczekiwany skutek, ważne jest to, jaki rodzaj kontenerów wybierzemy.

System operacyjny ma spore znaczenie

Jednym z częstszych błędów, których należy unikać podczas wdrażania kontenerów, jest wybór niewłaściwego systemu operacyjnego – być może nawet bardziej niż „tradycyjne” środowiska istotny jest właśnie jego rodzaj. Oczywiście możliwe jest uruchamianie kontenerów na wielu różnych systemach operacyjnych, to jednak Linux jest właśnie systemem pierwszego wyboru. Główny powód, dla którego większość kontenerów działa na hostach Linuksa to fakt, że same kontenery wykorzystują pewne kluczowe możliwości Linuksa, takie jak grupy kontrolne, przestrzenie nazw i SELinux w celu uruchamiania aplikacji wewnątrz nich. Ponadto, Kubernetes został zbudowany z wykorzystaniem koncepcji Linuksa, a do zarządzania kontenerami wykorzystuje także linuksowe narzędzia i API. Wszystko to oznacza, że dla efektywnego wykorzystania zasobów systemowych i czasu programisty Linux jest systemem bezkompromisowym jako system operacyjny dla platformy kontenerowej.

Wychodząc poza Kubernetes

Jedną z rzeczy, które są pomijane w rozmowach wokół kontenerów, to odpowiedź na pytanie, co robi Kubernetes? Często zbytnio upraszczamy Kubernetes, opisując go jako aplikację obsługującą kontenery. Jednak warto poznać jego dokładniejszy obraz, ponieważ tworzy go pakiet interfejsów API i narzędzi służących do orkiestracji i zarządzania zasobami. Niemniej jednak nie zapewnia on wszystkiego, co jest potrzebne dla platformy kontenerowej. Kompletna platforma kontenerowa wymaga także rejestracji kontenerów, sieci, pamięci masowej, dziennika zdarzeń (logi) i monitorowania. Wymaga on również podstawowego systemu operacyjnego oraz ścieżek integrujących mechanizmy ciągłej integracji i ciągłego dostarczania (CI/CD). W zależności od potrzeb organizacji można zbudować własne narzędzia do orkiestracji lub zainwestować w komercyjny framework. Przyjęcie komercyjnej platformy może zaoszczędzić wiele czasu i zasobów, które w przeciwnym razie zostałyby przeznaczone na jej rozwój i utrzymanie. Jest to również bezpieczniejsze, ponieważ platforma komercyjna wykonała już za nas niezwykle skomplikowaną pracę polegającą na prawidłowej instalacji i konfiguracji. Komercyjne frameworki często dostarczają organizacjom funkcje, które można wykorzystać natychmiast i które nie wymagają skomplikowanej konfiguracji. Jedną z najbardziej użytecznych funkcji typu „out of the box” jest niezależność chmurowa, która pozwala platformie kontenerowej działać w ten sam sposób i zapewnić takie same efekty u różnych dostawców chmury.

4 „c” platform kontenerowych (code, customer, cloud, comprehensive)

Potrzeby każdej organizacji różnią się od siebie. Oznacza to również, że idealna dla nas platforma kontenerowa może nie sprawdzić się u kogoś innego. Aby wybrać najlepszą dla nas opcję, jednym z pomysłów jest zbadanie tego, co nazywamy w języku angielskim zasadą „4 C” – kod, klient, chmura i wszechstronność. Pierwsze C to kod i sprawdzenie, jaki rodzaj kodu oraz jak wiele własnego kodu wnosi dostawca. Drugie to klienci i odpowiedź na pytanie, czy są już na rynku realni użytkownicy korzystający z danej platformy. Trzecie C to sama chmura i pytanie, gdzie działa platforma i u jakich dostawców chmury można z niej korzystać. Na koniec badamy, jak wszechstronna jest platforma i czy zapewnia ona kompletne portfolio produktów i rozwiązań, które odpowiadają potrzebom całego naszego zespołu (programistów i administratorów), zapewniając jednocześnie wymaganą skalowalność.

Inne elementy Cloud-Native

Jednym z elementów ryzyka – o którym zapominamy, tworząc strategię opartą na chmurze – jest fakt, że choć kontenery są dla niej kluczowe, to są one tylko jednym z elementów całego modelu. Obok nich musimy mieć na uwadze jeszcze trzy inne fundamenty. Pierwszym z nich jest przyjęcie architektury opartej na usługach. W niej działania biznesowe, które są w miarę samodzielne, są podzielone na moduły, które można łatwo aktualizować, zastępować i testować. Drugim jest automatyzacja DevOps, w której rozwój i operacje są realizowane w oparciu o wspólne i ujednolicone procesy i praktyki. Trzecim jest komunikacja oparta na API, która „widzi” procesy „rozmawiające ze sobą” poprzez czyste i oparte na umowach interfejsach sieciowych. To, w jaki sposób zabezpieczymy każdy z tych elementów, może wpłynąć na funkcjonowanie pozostałych elementów w naszej strategii chmury. Oznacza to, że zamiast rozpatrywać te elementy oddzielnie, udana strategia cloud-native oznacza całościowe spojrzenie na kontenery, architekturę opartą na usługach, DevOps i komunikację API, a także sposób ich współdziałania. Jeśli platforma kontenerowa funkcjonuje dobrze sama w sobie, ale utrudnia pracę jakiejś innej części chmury obliczeniowej organizacji, wówczas należy się wstrzymać z dalszymi pracami, aby ponownie rozważyć swój początkowy wybór.

Patrząc w przyszłość Cloud-Native

Wszystko to prowadzi ostatecznie do wniosku, który odnosi się do wyboru platformy kontenerowej, a także do wszystkich innych części równania cloud-native: czy twoja strategia cloud-native jest przygotowana na przyszłość? Wybór platformy z chmurą obliczeniową nie jest decyzją jednorazową. Zamiast tego należy myśleć o niej jako o rozpoczęciu procesu, który kładzie nacisk na ciągłą integrację i zmiany. Częścią tego procesu jest upewnienie się, że nasza strategia w chmurze uwzględnia obecny i przyszły rozwój oraz przygotowuje nasz zespół na nowe wyzwania. Oznacza to również zachęcanie swojego zespołu do ciągłego stawiania sobie wyzwań poprzez rozwijanie i przeorientowanie swoich umiejętności. Jednym z dobrych przykładów jest Quarkus, który pozwala programistom Javy kontynuować pracę w języku, w którym są biegli, ale na nowo przemyśleć swoje kompetencje w przestrzeni chmury obliczeniowej. Quarkus jest szczególnie zoptymalizowany dla środowisk kontenerowych ze względu na wysoką wydajność czasową i wykorzystanie pamięci. Zwracanie uwagi na nowe narzędzia i technologie nie polega tylko na tym, aby mieć pewność, że wykorzystujemy w organizacji najlepszą platformę kontenerową, jaką można zbudować, ale na to, jakie mają one znaczenie i wpływ na całość naszej strategii cloud-native.

Autor: Erica Langhi, EMEA Senior Solutions Architect, Red Hat

PRZECZYTAJ RÓWNIEŻ:


Back to top