Czy automatyzacja sieci jest możliwa

Czy automatyzacja sieci jest możliwa?

W tym cały jest ambaras…

O automatyzacji wszyscy bębnią naokoło, każdy widzi w niej wartość i każdy chce ją wdrażać. Jak się okazuje – teoretycznie (mówię tu cały czas o automatyzacji sieci). Postanowiłem jakiś czas temu, że nowe projekty będę wykonywał nie tylko adżajlowo, ale też automatyzując wszystko co się da. Pomysł był świetny, wykonanie połowiczne. Projekt wykonywany przez integratora wiąże się z przygotowaniem dokumentacji, konfiguracji, uruchomieniem, wykonaniem testów i… tyle. Produkt wdrożenia przekazywany jest później do utrzymania klientowi końcowemu. I tu automatyzacja się kończy. Klienci (administratorzy) chcieliby chętnie zaadoptować przygotowane procesy, ale mają zazwyczaj związane ręce wewnętrznymi procesami i procedurami. Często nie ma po prostu na czym uruchomić narzędzi do systemowej automatyzacji. Sam laptop administratora nie wystarcza. Pojawiające się na etapie oferowania kolejne wymagania projektowe (systemy operacyjne, zarządzanie wersjonowaniem konfiguracji, bezpieczeństwem, dostępem do zasobów, procesem zmian, itp, itd.) zwiększają jego koszty i wydłużają czas implementacji. Na to zazwyczaj nie ma budżetu… i czasu (o ironio).

I tak źle i tak niedobrze…

Żeby coś się zmieniło, musiałby pojawić się dedykowany projekt typu „automatyzujemy naszą infrastrukturę sieciową, całą infrastrukturę”. Ja osobiście nie zauważyłem – póki co – żeby firmy uruchamiały takie projekty. Oczywiście nie generalizuję, opieram się o własne obserwacje, które nie obejmują całego rynku. Ale, ich relatywnie duża ilość pozwala mi wysnuć takie wnioski (zostaw komentarz, jeżeli masz inne obserwacje). Dlaczego tak się dzieje?

Mamy dwa rodzaje projektów: greenfield i brownfield. Pierwszy, to postawienie nowego środowiska od zera. Drugi, to rozbudowa istniejącej infrastruktury. Jeżeli spojrzymy na te projekty w kontekście automatyzacji, to okazuje się, że żaden z nich nie jest do końca na nią gotowy (kompleksowo). Projekty brownfield są skomplikowane operacyjnie i obarczone dużą ilością ograniczeń. Jest to często rozbudowa istniejącego środowiska, działającego produkcyjnie. Wszystkie prace wykonywane są bardzo ostrożnie, a afekt końcowy musi się utrzymaniowo wtopić w to, co działało do tej pory. Automatyzacja? Zapomnij.

Greenfield wydaje się być idealnym miejscem do wdrożenia automatyzacji. Ale, co to znaczy, że budujemy nowe środowisko od zera? To najczęściej oznacza, że dodajemy nową usługę, na której potrzeby dostarczamy: nową sieć, nowe macierze, serwery, systemy operacyjne i aplikacje. Na koniec, dodajemy jakiś punkt styku z istniejącą siecią. Uważam to za absolutnie awykonalne, żeby wyłączyć nagle całą obecną infrastrukturę i postawić ją od zera. Zatem, wszystkie projekty greenfield są de facto „pączkami” istniejącej infrastruktury. A tą „nową” usługą zarządzają te same zespoły.

Wkracza tu czynnik nie tylko ludzki (przyzwyczajenia), ale też biznesowo-mentalny „nie ma uzasadnienia finansowego, do tej pory wszystko jakoś działało”. W obu przypadkach główny nacisk kładzie się na szybkie wprowadzanie zmian i szybkie usuwanie awarii „tak jak do tej pory”. Pojęcie „szybkie” zaczyna być tu kluczowe, ale i dwuznaczne, w zależności od tego jaki przyjmiemy azymut. Ale pamiętacie, wszyscy mówią o automatyzacji i jej pragną…

Spotykamy się z problemamy formalnymi

Mały krok dla administratora, wielki dla biznesu…

Czy powinniśmy automatyzować sieć? Nie ulega to wątpliwości. Sieci automatyzujemy od dawna, w mniejszym lub większym stopniu. Jesteśmy tu jednak wciąż osamotnieni. Wszechobecny trend DevOps’owy zakłada, że infrastruktura obejmie wszystkie elementy – serwery, macierze, systemy operacyjne i właśnie sieć. Jak do tego podejść? Zacznijmy małymi kroczkami. Wiem, kolokwializm. Ale ten kolokwializm ma głębsze znaczenie. Automatyzacja oznacza, że wykonujemy czynności powtarzalne (jednostkowe), posługując się szeroko rozumianym programowaniem. Jednak największą wartością dla firmy są procesy orkiestracji. Biznes chce szybko powoływać nowe usługi, a usługa to nie zawsze tylko VLAN. Orkiestracja pozwala na wykonywanie, w ściśle określonej kolejności, wielu zadań zróżnicowanych technologicznie, składających się na produkt docelowy – usługę biznesową. Automatyzujemy biznes, nie IT.

Te atomowe zadania procesu orkiestracji to są właśnie te małe kroczki. Nie musimy automatyzować całej sieci od razu. I nie musimy nawet dotykać elementów szkieletowych. Jedną z największych obaw sieciowców jest możliwość popsucia jednym kliknięciem całej sieci, a tym samym utratę kontaktu z nią (znika cały biznes). Jak często zmieniamy coś w szkielecie? Raz na rok? Owszem, możemy sobie pomóc automatyzacją w utrzymaniu spójnej konfiguracji i wprowadzaniu zmian utrzymaniowych (snmp, syslog, ntp, itp.). Ale, oddając możliwość konfiguracji w sieci elementów typowo usługowych procesom orkiestracji ułatwiamy sobie życie, bez obawy spowodowania większej awarii. No i pamiętajmy, możemy automatyzować to, co rozumiemy jak działa. To my przygotowujemy ten jeden trybik w procesie orkiestracji, więc mamy kontrolę nad tym, co jest w sieci konfigurowane.

Jak żyć Panie Premierze…

Biznes dostrzega potrzebę automatyzacji infrastruktury, to jest fakt. Żeby mógł na to przeznaczyć odpowiednie środki musimy zdobywać jego coraz większą atencję. Nie zrobimy tego nie angażując się w automatyzację i czekając, aż pojawi się nagle ten jeden, wyczekiwany projekt. Inicjujmy aktywności od dołu. Uczmy się automatyzacji. Mamy do tego ogromne możliwości. Pomimo negatywnego wydźwięku artykułu, widzę światełko w tunelu. W wielu projektach powoli zaczynają pojawiać się przebłyski wymagań automatyzacji, a to prowadzi do alokowania większej ilości czasu dla inżynierów na jej naukę.

Jest światełko w tunelu

Wracając do sedna. Czy uważasz, że automatyzacja sieci stanie się tak popularna jak konfigurowanie jej za pomocą klasycznego CLI? A może pozostanie niezależną wyspą w morzu automatyzacji komponentów infrastruktury? Jestem ciekaw Twojego zdania.

Dodaj komentarz

18 + eight =