#15 DevOps vs. Architekt Infrastruktury IT – wrogowie czy przyjaciele?

Że to już nie chodzi o to, że wymieniamy Linux z admina na Kubernetes z admina, tylko że mamy DevOps solution, który planuje co później zbudujemy, jak skonsumujemy te nasze współczesne narzędzia i frameworky DevOpsowe. Nie sądzisz, że to jest, bo wiesz, ostatnio prowadziliśmy taki podcast, nasz ostatni podcast dotyczył Industrii 4.0, czyli taka industrializacja pełna i mi się wydaje, że DevOps jest bardzo dobrym, jak się ja obrazuję DevOps dla organizacji, to jest taka trochę industrializacja na IT. To znaczy, żeby to miało proces, a nie patatajnie, że zazwyczaj w IT wyglądało to tak, robimy projekt, no bardzo fajnie, zrobiliśmy go, oj co teraz. To jakby, żeby nie było takiej husarii, tylko po prostu właśnie zindustrializowane podejście, mamy linie produkcyjne, mamy pewnego rodzaju procesy biegnące za tym, czyli nie zastanawianie się po wykonaniu, co żeśmy uczynili,

Nie chodzi o to, że dzisiaj mamy 10 serwerów, a jutro 1000. Chodzi chociażby o rotację tych serwerów, że dzisiaj wkładamy blachy w wersji takiej i jutro chcemy je wymienić. Nie chcemy tracić znowu takiej samej ilości czasu na przekonfigurowanie tego wszystkiego, tylko chcielibyśmy puścić jeden pipeline, który skonfiguruje nam wszystkie blachy od samego dołu, aż do jakiejś wirtualizacji Kubernetes na samej górze. Więc benefitów jest dużo. Są też benefity takie stricte, jakby to powiedzieć, Organizacyjno-biznesowe, mianowicie skrócenie tego wewnętrznego łańcucha dostaw w organizacji. Bo nawet jak mamy taką stosunkowo stabilną firmę, której nie przerasta ilość projektów, to często występują tam opóźnienia w stylu, że zespół deweloperski zamawia nowe środowisko i dostaje informację, że musi

No dobra, czyli generalnie po prostu trzeba szerzej trochę na to spojrzeć, bo jest więcej zabawek, bo jest powiedzmy tu trochę technologii tego typu, tutaj technologii innych. Czy są takie rozwiązania, które pozwalają nam uzyskać powiedzmy w miarę jednorodny ekosystem? To znaczy, żeby właśnie nie robić czegoś takiego, że tutaj mamy wiesz, inne w on-premie, inne przy hybrydowym rozwiązania, a inne w publiku. Tylko jakoś istnieje warstwa abstrakcji, dzięki której możemy tym wszystkim w taki nowoczesny sposób zarządzać, budować, dokumentować, whatever. Podejrzewam, że próbujesz tutaj dotknąć całej tematyki kontenerów Kubernetesa i procesów wokół tego. Oczywiście, to jest wspaniała warstwa abstrakcji. Polecam od lat.

Mega dużo projektów zrobiliśmy na tych środowiskach. Też w kontekście środowisk hybrydowych coraz więcej jest takiego zrozumienia, że możemy hostować tego Kubernetesa w różnych formach, na różnych platformach, czy on premisowo, czy cloudowo. I one mogą mieć wszystkie tą wspólną warstwę, jeżeli wystawiają po prostu API Kubernetesa do testowania różnego rodzaju workloadów i aplikacji. To, co jest ważne tutaj, myślę, że trzeba o tym powiedzieć, że Kubernetes nie jest, wiem, że to jest trywializowanie, ale to nie jest kolejna dystrybucja Linuxa. To jest framework, na którym budujemy nasz ekosystem. I w zależności czy pójdziemy w open source'owe rozwiązanie czy płatne, tutaj bardzo dużo to nie zmienia. Natomiast musimy pamiętać, że to nie jest kolejna wirtualizacja, to nie jest kolejny Linux, tylko to jest framework, do którego dopasowujemy nasz biznes, tak?

Wrogami może nie, natomiast bardzo często występuje takie myślenie życzeniowe, że ten kuberneta stan z openshift będzie prosty, łatwy, przyjemny. Kupimy licencję, włączymy i wszystko rozwiąże się samo. Ale to chyba ze wszystkimi nowymi rzeczami takie jest. Ja pamiętam, że wirtualizacja też tak miała zrobić, wiesz, że instalujesz na serwerach i nagle wszystkie problemy znikają, przenosimy się na wirtualizację, performance rośnie, scaling się udaje. Ja myślę, że tutaj jest to odrobinę bardziej skomplikowane, bo często z perspektywy software architecta On ma wyobrażenie, że kolejne rozwiązanie software'owe to jest kwestia integracji tylko, prostej.

Natomiast tu jest trochę ta szara strefa i czasem jest to dość trudno wytłumaczyć, że mamy tą twardą infrastrukturę, o której wspomniałeś, mamy software, który będzie działał na tej twardej infrastrukturze. Te frameworki po środku często jest trudno zaklasyfikować tak naprawdę, czy ten Kubernetes traktujemy jako software, czy traktujemy to jako infrastrukturę. Jeżeli traktujemy to jako infrastrukturę, to kto jest odpowiedzialny za budowanie integracji i automatyzacji na przykład. Jeżeli traktujemy to jako software, to często brakuje nam tam ludzi ze zrozumieniem co się dzieje w środku tak naprawdę, jak to tuningować, przygotowywać pod kątem bezpieczeństwa itd. Więc wracając do twojego pytania, to nie jest tak, że jest tam wrogość jakaś, ale często występuje brak takiego zrozumienia i zaplanowania projektów. Komunikacji? Komunikacji też, ale często brakuje... Odniosę się tu do jednego projektu, który się ciągle toczy, więc oczywiście nie będę poddawał na nas i tak dalej, ale często występuje takie myślenie na rynku,

Nie wiem jak to zaktualizować, nie wiedzę, to jest bardzo trudne powiedzmy. I po prostu w pewnym efekcie skali to zaczyna mieć sens, ale ten efekt skali jest absurdalny. To znaczy to musi być tak absurdalnie wielkie, że ci sześciu specjalistów, którzy są na świecie dotyczących tej akurat technologii możesz zatrudnić. Czyli powiedzmy taki Netflix, takie Spotify, wspominane firmy, które, wiesz, mają, powiedzmy, trochę inny lewar, że tak powiem, przyciąganie do siebie naprawdę znakomite. Jak przypomniałeś o tych sześciu specjalistach, to przypomniały mi się moje początki z Kubernetesem, kiedy byłem jednym z sześciu w Polsce. Tak, ale to jest właśnie kwestia dojrzałości tej technologii. W sensie 5 lat temu kontenery w postaci Kubernetesa były mega trudne do zbudowania on-premisowo i mało kto to robił.

I po prostu jak zaczynał się ten projekt, oni już te podstawy mieli. Mieli już zrozumienie tego, że wszystkie te serwisy wystawiają API, że są jakieś automatyzacje itd. I był to greenfield dla tych ludzi pracujących na projekcie. W kontekście serverlessu jest to trochę trudniejsze, bo kto tak naprawdę ma tu zmiany wykonań? No deweloper nauczy się procesu serverlessu, okej, ale osoba utrzymująca Kubernetes albo wirtualizację? No nie do końca, bo sobie tego nie skonsumuje później, tak? VMware sobie przez API postawisz, jak jesteś adminem VMwarea, no to szybko zobaczysz, że można tak, można inaczej i tak dalej. Jak postawisz sobie Kubernetesa, to już zaczyna się szara strefa, bo kto ma go stawiać, tak? Nie wiadomo, czy ten admin, czy ten developer, bo tu już się rozmywa. W kontekście serverlessa jest jeszcze bardziej, bo nagle musisz zbudować całą infrastrukturę pod spodem, tylko kto ma to zbudować?

Jedzie przez te Excele, wiesz, tam przez te Gartnery, Forestery i na końcu wprowadza taki projekt za 100 milionów rzeczony. Jeszcze na wczoraj mówię. Na wczoraj, bo jakby maszyna jechała długo. Tak, ale termin zaczął się liczyć od pierwszego dnia. Termin projektu został ustalony pierwszego dnia. No i wiesz, to nawet mnie bawi, bo od 15-16 lat... Wszyscy byliśmy w tym totalnie. Natomiast tak sobie myślę o tym z dłuższej perspektywy, że Te warstwy, o których mówimy, czyli stwarda infrastruktura, na niej stoi wirtualizacja, jest gdzieś tam sieć w okolicy, do tego jest warstwa kubernetesowa, która rozciąga się jeszcze na różne tam hybrydy, niehybrydy, publiki, niepubliki, za tym ciągle ci sieć, za tym lecą jakieś repozytoria.