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.
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.
