O DevOps i Snowflakes

W dzisiejszym IT trudno wykonać przysłowiowy ruch bez usłyszenia, jak ludzie mówią o DevOps. DevOps to gorący nowy temat w branży, przejmujący pałeczkę po rozmowach o chmurze, i słuchając dyskusji na ten temat, można by uwierzyć, że tradycyjna administracja systemami jest już martwa i pochowana.

Najpierw musimy porozmawiać o tym, co rozumiemy przez DevOps. Może to być mylące, ponieważ podobnie jak chmura, starszy termin jest często przywłaszczany, by oznaczać coś innego lub, w najlepszym razie, powiązanego z czymś, co już istniało. Tradycyjny DevOps to łączenie ról programisty i operacyjnych. W latach 60. do 90., był to standardowy sposób prowadzenia systemów. W tym świecie ludzie piszący oprogramowanie byli generalnie tymi samymi, którzy je wdrażali i utrzymywali. Stąd połączenie “developera” i “operacji”, gdzie operacje to półstandardowy termin dla roli administratora systemu. Role te nie były powszechnie rozdzielone aż do powstania “Działu IT” w latach 90. i 2000. Od tego czasu powrót do łączenia tych dwóch ról zaczął zyskiwać na popularności, przede wszystkim ze względu na sposób, w jaki obie mogą współpracować z wielką wartością w wielu nowoczesnych, hostowanych sytuacjach aplikacji webowych.

Tam, gdzie DevOps jest dziś często omawiany, nie jest to ścisłe połączenie programistów i personelu operacyjnego, ale modyfikacja personelu operacyjnego z znacznie większym skupieniem na kodowaniu — nie samej aplikacji, ale na definiowaniu infrastruktur aplikacji jako kodu jako naturalnego rozszerzenia architektur chmurowych. Na początku może to być nieco mylące. Ważne jest, by zauważyć, że tradycyjny DevOps nie jest tym, co powszechnie ma miejsce dzisiaj, ale nowy “fałszywy” DevOps, gdzie programiści pozostają programistami, a operacje pozostają operacjami, ale operacje ewoluowały w nową rolę “zorientowaną na kod”, która nadal skupia się na zarządzaniu serwerami uruchamiającymi kod dostarczany przez programistów.

Istotne jest dziś to, że rola administratora systemów zaczęła się rozgałęziać w dwie powiązane, ale znacząco różne role, z których jedna jest nieprawidłowo nazywana DevOps przez większość branży (większość branży jest zbyt młoda, by pamiętać, gdy DevOps był normą, a nie wyjątkiem, i z pewnością nie czymś nowym i nowatorskim). Dwa te aspekty roli administratora systemu określam tu jako podejście DevOps i Snowflake.

Używam terminu Snowflake w odniesieniu do tradycyjnych architektur systemów, ponieważ każdy indywidualny serwer można postrzegać jako “unikalny płatek śniegu”. Wszystkie są różne, przynajmniej o tyle, o ile nie są w jakiś sposób zarządzane w celu utrzymania ich identyczności. Nie oznacza to, że wszystkie muszą być unikalne, tylko że zachowują potencjał bycia takimi. W tradycyjnych środowiskach administrator systemów będzie logował się do każdego serwera indywidualnie, by na nim pracować. Pewien stopień skryptowania jest powszechny, by ułatwić zadania administracyjne, ale w swej istocie rola ta wiąże się z dużą ilością czasu spędzonego na pracy na poszczególnych systemach.

Ułatwianie administracji architektur Snowflake często wiązało się z próbami minimalizacji różnic między systemami w rozsądny sposób. Generalnie zaczyna się to od takich rzeczy, jak wybór jednolitego standardowego systemu operacyjnego i wersji (Windows 2012 R2 lub Red Hat Enterprise Linux 7) zamiast pozwalania, by każda instalacja serwera była innym systemem operacyjnym lub wersją. Ta standaryzacja może wydawać się podstawowa, ale wiele środowisk brakuje jej nawet dzisiaj.

Kolejnym krokiem jest zwykle tworzenie standardowej metodologii wdrażania lub wzorcowego obrazu (gold master), który jest używany do tworzenia wszystkich systemów, tak że podstawowy system operacyjny i wszystkie podstawowe pakiety — często w tym dostosowania systemowe, pakiety monitoringu, pakiety bezpieczeństwa, konfiguracja uwierzytelniania i podobne modyfikacje — są standardowe i wdrażane jednolicie. Zapewnia to wspólny punkt startowy dla wszystkich systemów, minimalizujący rozbieżności. Ale technicznie zapewniają tylko standardowy punkt startowy i z czasem należy antycypować rozbieżności w konfiguracji.

Poza tymi krokami, środowiska Snowflake zazwyczaj używają niestandardowych, dedykowanych skryptów administracyjnych lub narzędzi zarządzania, by utrzymać pewną standaryzację między systemami w czasie. Im więcej wspólnych cech istnieje między systemami, tym łatwiej je utrzymywać i rozwiązywać problemy, a tym mniej wiedzy potrzebuje personel administracyjny. Więcej standaryzacji oznacza mniej niespodzianek, mniej niewiadomych i znacznie lepsze możliwości testowania.

W środowisku z jednym administratorem systemu i dobrymi praktykami i narzędziami, środowiska Snowflake mogą osiągnąć wysoki stopień standaryzacji. Ale w środowiskach z wieloma administratorami systemów — szczególnie tymi obsługiwanymi całą dobę z wielu regionów — i z dużą liczbą systemów, standaryzacja, nawet przy bardzo pilnych praktykach, może stać się bardzo trudna. I to jeszcze zanim zmierzymy się z oczywistymi problemami wynikającymi z faktu, że różne pakiety i możliwie różne wersje pakietów są potrzebne na systemach pełniących różne role.

Podejście DevOps wyrasta organicznie z modelu architektury chmurowej. Architektura chmurowa jest zaprojektowana wokół automatycznie tworzonych i automatycznie niszczonych, szeroko identycznych systemów (przynajmniej w grupach), kontrolowanych przez programowalny interfejs lub API. Ten model nadaje się, całkiem oczywiscie, do centralnego sterowania przez system zarządzania, a nie przez manualne wysiłki administratora systemów. Manualna administracja jest faktycznie niemożliwa i całkowicie niepraktyczna w tym modelu. Poszczególne systemy nie są unikalne jak w modelu Snowflake i jakakolwiek rozbieżność spowoduje poważne problemy.

Idea, która wyłoniła się ze świata architektury chmurowej, zakłada, że architektura systemów powinna być definiowana centralnie “w kodzie”, a nie na samych serwerach. Na początku brzmi to myląco, ale ma dużo sensu, gdy przyjrzymy się temu głębiej. By wspierać ten model, pojawił się nowy typ narzędzia do zarządzania systemami, który jeszcze nie przyjął naprawdę standardowej nazwy, ale jest często nazywany narzędziem do automatyzacji systemów, frameworkiem DevOps, narzędziem do automatyzacji IT lub po prostu narzędziem “infrastructure as code”. Popularne zestawy narzędzi w tym obszarze to Puppet, Chef, CFEngine i SaltStack.

Idea stojąca za tymi zestawami narzędzi do automatyzacji polega na tym, że centralna usługa jest używana do zarządzania i kontrolowania wszystkich systemów. Ten centralny organ zarządza poszczególnymi serwerami za pomocą opartych na kodzie opisów tego, jak system powinien wyglądać i zachowywać się. W świecie Chef te opisy nazywane są “przepisami” (recipes), co jest urocze, ale analogia działa dobrze. Kod każdego systemu może zawierać informacje takie jak lista pakietów i wersji pakietów, które powinny być zainstalowane, jakie konfiguracje systemowe powinny być modyfikowane oraz pliki do skopiowania na maszynę. W wielu przypadkach decyzje dotyczące tych wdrożeń lub modyfikacji są obsługiwane przez potencjalnie złożoną logikę, stąd potrzeba rzeczywistego kodu zamiast czegoś bardziej uproszczonego, jak znaczniki lub szablony. Systemy są następnie grupowane według roli i zarządzane jako grupy. Rola “serwera web” może nakazać zestawowi systemów zainstalowanie Apache i PHP i skonfigurowanie pamięci z minimalnym swapem. Rola “SQL Server” może zainstalować MS SQL Server i specjalne narzędzia do tworzenia kopii zapasowych używane tylko dla tej aplikacji i skonfigurować pamięć według życzenia dla puli maszyn SQL Server. To tylko przykłady. Zazwyczaj organizacja miałaby wiele ról, niektóre mogą być ogólne, jak “serwer web”, a inne znacznie bardziej specyficzne dla obsługi bardzo specyficznych aplikacji. Role można generalnie nakładać warstwami, tak że system może być jednocześnie “serwerem web” i “serwerem java”, spełniając połączone potrzeby obu.

Te standardowe definicje oznaczają, że systemy, gdy zostaną wyznaczone jako należące do jednej lub innej roli, mogą “budować się” automatycznie. Nowy system może być tworzony przez administratora żądającego systemu lub system monitoringu pojemności może zdecydować, że potrzebna jest dodatkowa pojemność dla danej roli i automatycznie tworzyć nowe instancje serwerów bez jakiejkolwiek interwencji ludzkiej. W chwili żądania systemu — przez człowieka lub automatycznie — rola jest wyznaczona, a system za pomocą frameworka automatyzacji przekształci się w w pełni skonfigurowany i aktualny “węzeł”. Nie jest wymagana manualna interwencja administratora systemu. Proces jest szybki, prosty i, co najważniejsze, całkowicie powtarzalny.

Definiowanie systemów w kodzie ma pewne nieoczywiste konsekwencje. Jedną z nich jest to, że kopie zapasowe kompletnych systemów nie są już potrzebne. Po co tworzyć kopię zapasową systemu, który można odtworzyć przy minimalnym wysiłku niemal natychmiast? Lokalne dane z systemów bazodanowych musiałyby być kopiowane, ale tylko dane bazy danych, nie cały system. Może to znacznie zmniejszyć obciążenie infrastruktur kopii zapasowych i sprawić, że procesy przywracania będą szybsze i bardziej niezawodne.

Ilość dokumentacji potrzebnej dla systemów już zdefiniowanych w kodzie jest bardzo minimalna. W środowiskach Snowflake administrator systemu musi utrzymywać dokumentację specyficzną dla każdego hosta i utrzymywać tę dokumentację manualnie. Jest to bardzo czasochłonne i podatne na błędy. Systemy zdefiniowane za pomocą centralnego kodu wymagają mało lub wcale dokumentacji, a dokumentacja może być obsługiwana na poziomie grupy, a nie poszczególnego węzła.

Testowanie systemów zdefiniowanych w kodzie jest również łatwe do przeprowadzenia. Można stworzyć system za pomocą kodu, przetestować go i wiedzieć, że gdy przeniesie się tę definicję do produkcji, system produkcyjny zostanie stworzony powtarzalnie dokładnie tak, jak był tworzony w testach. W środowiskach Snowflake bardzo powszechne jest posiadanie praktyk testowania, które próbują to robić, ale robią to poprzez manualne wysiłki i są podatne na bałaganiarstwo i brak dokładnej powtarzalności, a bardzo często polityka będzie decydować, że szybciej jest naśladować powtarzalność niż naprawdę do niej dążyć. Systemy zdefiniowane kodem omijają te problemy, czyniąc testowanie znacznie bardziej wartościowym.

Poza potrzebą zdefiniowania liczby węzłów istniejących w każdej roli, system może automatycznie odbudować całą architekturę od zera. Odbudowa po katastrofie lub uruchomienie dodatkowego miejsca może być wykonane bardzo szybko i łatwo. Migracja między lokalnie hostowanymi systemami a zdalnie hostowanymi, w tym tymi od firm takich jak Amazon, Microsoft, IBM, Rackspace i innych, jest również niezwykle łatwa.

Oczywiście w świecie DevOps istnieje ogromna wartość w używaniu architektur chmurowych, by umożliwić najbardziej ekstremalny poziom automatyzacji, ale używanie architektur chmurowych nie jest konieczne, by korzystać z tego typu narzędzi. I oczywiście posiadanie architektury zdefiniowanej w kodzie może być używane częściowo, podczas gdy manualna administracja może być też wdrożona jako podejście hybrydowe, ale rzadko jest to zalecane na poszczególnych systemach. Generalnie znacznie lepiej jest mieć dwa środowiska — jedno zarządzane jako Snowflakes i jedno zarządzane jako DevOps — gdy wymagane są oba podejścia. To tworzy znacznie lepszą hybrydyzację. Widziałem, jak działa to bardzo dobrze w środowisku enterprise z dziesiątkami tysięcy serwerów “Snowflake”, każdy bardzo unikalny, ale z dedykowanym środowiskiem dziesiątek tysięcy węzłów zarządzanym w sposób DevOps, ponieważ wszystkie węzły miały być identyczne i wymienne przy użyciu jednej z dwóch możliwych konfiguracji. Hybrydyzacja była bardzo efektywna.

Podejście DevOps jednak wiąże się z poważnymi zastrzeżeniami. Zestawy umiejętności niezbędne do zarządzania systemem w ten sposób są znacznie większe niż te potrzebne do tradycyjnej administracji systemami, ponieważ przynajmniej cała tradycyjna wiedza z zakresu administracji systemami jest nadal potrzebna, plus solidna wiedza z zakresu programowania — zazwyczaj w nowoczesnych językach takich jak Python i Ruby — oraz znajomość konkretnych używanych frameworków. Ten rozszerzony wymóg wiedzy oznacza, że praktycy DevOps są nie tylko rzadkością, ale i drodzy. Oznacza to również, że edukacja akademicka, już daleko od przygotowania zarówno administratorów systemów, jak i programistów do świata zawodowego, jest teraz jeszcze dalej od przygotowania absolwentów do pracy w modelu DevOps.

Administratorzy systemów pracujący w każdym z tych dwóch obozów mają tendencję do postrzegania wszystkich systemów jako wymagających dopasowania do ich własnego modelu. Nowi praktycy DevOps często uważają, że systemy Snowflake są przestarzałe i wymagają aktualizacji. Administratorzy Snowflake (tradycyjni) mają tendencję do postrzegania ruchu “infrastructure as code” jako głupiego, pełnego zbędnego narzutu, nadmiernie skomplikowanego i bardzo niszowego.

Rzeczywistość jest taka, że oba podejścia mają ogromne zalety i oba pozostaną niezwykle żywotne. Oba mają sens dla bardzo różnych obciążeń, a duże organizacje, jak podejrzewam, powszechnie będą widzieć oba w formie hybrydyzacji. Na rynku SMB, gdzie zazwyczaj jest tylko niewielka liczba serwerów, brak dźwigni skalowania uzasadniającej architektury chmurowe i duża rozbieżność między systemami, podejrzewam, że DevOps pozostanie prawie na zawsze poza normą, ponieważ narzut i dodatkowe umiejętności niezbędne do jego funkcjonowania są niepraktyczne lub nawet niemożliwe do zdobycia. Większe organizacje muszą spojrzeć na swoje obciążenia. Wiele tradycyjnych obciążeń i wiele tradycyjnego oprogramowania nie jest dobrze dostosowane do podejścia DevOps, szczególnie automatyzacji chmurowej, i będzie wymagać albo hybrydyzacji, albo niepraktycznie wysokiego poziomu kodowania na podstawie poszczególnych systemów, co sprawia, że model DevOps jest niemożliwy do uzasadnienia. Ale obciążenia zbudowane na architekturach webowych lub te, które mogą skalować się horyzontalnie bardzo dobrze, skorzystają znacznie z modelu DevOps w skali. Może to dotyczyć dużych firm enterprise lub mniejszych firm prawdopodobnie produkujących hostowane aplikacje do użytku zewnętrznego.

Ta różnica w podejściu oznacza, że na przykład w Stanach Zjednoczonych większość USA składa się z firm, które pozostaną skoncentrowane na modelu zarządzania Snowflake, podczas gdy niektóre firmy ze wschodniego wybrzeża mogłyby skutecznie ocenić model DevOps i zacząć poruszać się w tym kierunku. Ale na zachodnim wybrzeżu, gdzie nowocześniejsze architektury i znacznie większy nacisk na hostowane aplikacje i aplikacje do zewnętrznego użytku są głównymi czynnikami ekonomicznymi, DevOps już przesuwa się od nowicjusza do dojrzałej, ugruntowanej normalności. Podejścia DevOps i Snowflake prawdopodobnie pozostaną mocno rozdzielone regionalnie w ten sposób, tak jak IT generalnie widzi różne zestawy umiejętności migrujące do różnych regionów. Nie byłoby niespodzianką zobaczyć DevOps zaczynające zadomawiać się na rynkach takich jak Austin, gdzie tradycyjne IT radziło sobie raczej słabo.

Żadne podejście nie jest lepsze ani gorsze — to dwa różne podejścia obsługujące dwa bardzo różne sposoby dostarczania systemów i dwie różne fundamentalne potrzeby tych systemów. Wraz z rozwojem architektur chmurowych i modelu DevOps jednak niezwykle ważne jest, by istniejący administratorzy systemów rozumieli, co oznacza model DevOps i kiedy ma zastosowanie, tak by mogli prawidłowo oceniać własne obciążenia i unikalne potrzeby. Duża część tradycyjnego świata administracji Snowflake będzie migrować — z biegiem czasu — do modelu DevOps. Jesteśmy bardzo daleko od osiągnięcia stabilnego stanu w branży co do równowagi tych dwóch modeli.

Pierwotnie opublikowano na blogu StorageCraft.