Docker i kontenery – marketingowy „hype” czy „real deal” ?

W dobie technokracji firmy z branży IT produkują więcej zabawek niż jesteśmy w stanie kupić, a tym bardziej użyć. Marketingowy „hype” przybiera na sile, a programiści – wiadomo – lubują się w nowych zabawkach. Rozróżnienie „real deal” od chwilowej mody może stanowić w naszej branży o życiu lub śmierci, a w każdym razie o powodzeniu lub fiasku naszego projektu.

Czym są kontenery?

Wyobraź sobie, że właśnie wynaleziono autobus. Do wczoraj każdy, kto chciał dojechać do pracy na określoną godzinę, musiał kupić sobie samochód. Dzięki temu zyskiwał mobilność, a po drodze do biura mógł zabrać ze do trzech lub czterech osób. Rozwiązanie wygodne, ale dość drogie. Co nam daje autobus? Mamy tylko jednego kierowcę i jeden pojazd, który jest w stanie pomieścić i dowieźć do pracy kilkadziesiąt osób. Żeby przetransportować tę samą liczbę osób potrzebowalibyśmy np. kilkunastu samochodów, w każdym z nich kierowcę; do tego korki, rachunki za paliwo itd.

Tym właśnie są kontenery w IT – sposobem na uzyskanie większej „gęstości” na serwerach. Jeden fizyczny serwer jest w stanie pomieścić więcej usług, przez co te stają się tańsze w utrzymaniu.

Containers Inception

To samo zapewniała nam wirtualizacja, jednak na trochę innym poziomie. Używanie wirtualnych „maszyn” zużywa więcej zasobów, ponieważ na każdej z nich zainstalowany jest system operacyjny. W przypadku kontenerów, system operacyjny jest jeden (choć może być wirtualny), współdzielony przez poszczególne kontenery. Efektem tego jest mniejsze zużycie pamięci i zasobów – każdy kontener zużywa ich tyle, ile potrzebuje usługa i jej zależności.

Ktoś mógłby zadać pytanie – a czy nie można po prostu zainstalować kilka usług na tym samym systemie operacyjnym i skonfigurować je tak, by mogły współistnieć? Odpowiedź brzmi – „tak”, ale takie podejście najczęściej powodowało powstanie konfliktów pomiędzy poszczególnymi usługami w przypadku np. wymagania różnych wersji biblioteki przez różne komponenty (DLL hell) oraz utrudniało przenoszenie tych usług pomiędzy serwerami oraz , ogólnie, zarządzanie nimi i ich monitorowanie. W przeciwieństwie do tego podejścia, kontenery hermetyzują poszczególne usługi, dostarczając im wszystkich wymaganych zależności. Przez to bardzo łatwo oddzielić poszczególne usługi i dowolnie przenosić je pomiędzy serwerami. Kontenery stanowią jednocześnie „wdrażalne” części naszego systemu.

Idea jest bardzo obiecująca, jednak – nawiązując do analogii komunikacyjnej – mimo kursowania po mieście autobusów, samochodów osobowych na drogach nie ubywa. Tak tutaj, mogą wystąpić powody, dla których możemy zdecydować się na pozostanie przy tradycyjnych metodach wdrażania oprogramowania.

Korzyści:

  • zmniejszenie kosztów infrastruktury IT – zwłaszcza w środowiskach „chmurowych”, gdzie płacimy tylko za faktyczne zużycie maszyny – ponieważ na jednej maszynie (fizycznej lub wirtualnej) możemy pomieścić więcej usług;
  • usprawniają testowanie i wdrażanie oprogramowania ze względu na to, że kontener zawiera w sobie wszystkie zależności, które są potrzebne do uruchomienia usługi; koszt przygotowania środowiska (instalacji zależności, bibliotek itp.) spoczywa na zespole przygotowującym dany kontener, znacznie upraszczając wdrażanie rozwiązania na kolejnych serwerach;
  • rozwiązania kontenerowe niosą ze sobą narzędzia ułatwiające zarządzanie farmami serwerów, na których osadzane są kontenery, przez co dodawanie kolejnych instancji usługi w okresach zwiększonego zapotrzebowania na moc obliczeniową (koniec okresu rozliczeniowego itp.) przestaje być karkołomnym i kosztownym przedsięwzięciem;
  • lepsza dokumentacja środowiska – kontenery tworzone są na podstawie plików konfiguracyjnych, które zawierają całą sekwencję operacji potrzebnych do skonfigurowania środowiska;
  • sporą część rozwiązań IT można przenieść do środowiska kontenerowego bez konieczności głębokiego refactoringu kodu.

Ryzyka

  • używana zwłaszcza w połączeniu z filozofią „microservices” może prowadzić do tworzenia zbyt wielu małych komponentów, co może prowadzić do problemu z zarządzaniem infrastrukturą i połączeniami pomiędzy mikrousługami;
  • technologia dość „świeża”, niezupełnie wspierana na wszystkich systemach operacyjnych (Windows posiada pewne ograniczenia w zakresie funkcji sieciowych, które w przyszłości będą zapewne uzupełnione),
  • konieczność przyswojenia sobie nowego modelu projektowania i wdrażania oprogramowania; aby w pełni wykorzystać podejście kontenerowe należy zainwestować czas i środki w wypracowanie metodyki budowania aplikacji, wdrażania na środowiska testowe, produkcyjne itp.; może to nie być efektywne w przypadku projektów z mniejszą liczbą docelowych klientów lub rzadszymi cyklami odsłon kolejnych wersji; W efekcie zespoły, które niedomagają w obszarze „DevOps” mogą mieć do przebycia długą drogę;
  • dość stroma krzywa nauki; sama koncepcja kontenerów jest dość prosta i spójna, jednak jej użycie w praktyce i w warunkach produkcyjnych wymusza na nas opanowanie kolejnych narzędzi używanych do tzw. „orkiestracji” (z ang. „orchestrate”) kontenerami, do ich diagnostyki i aktualizacji; użycie kontenerów w środowisku testowym lub rozwojowym to jedno – zapewnienie nieprzerwanej pracy w warunkach produkcyjnych to osobna historia.

Mam nadzieję, że niniejszy artykuł pomoże Czytelnikowi w wypracowaniu stanowiska względem tej technologii. Należy, przede wszystkim, pamiętać, że w branży IT nie istnieją „silver bullet”, które rozwiążą wszelkie problemy doskwierające ludzkości, a użycie każdego narzędzia niesie za sobą konsekwencje – mniej lub bardziej dotkliwe, w zależności od projektu.

Dodaj komentarz