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

A tymczasem jest jej tam mega dużo. Jest mnóstwo. Wiadomo w tej części faktycznie tego core'owego kodu, który się wykonuje, ale on nigdy sam nie egzystuje do końca. Nie zawsze są jakieś interfejsy zewnętrzne. I to absurd, który zauważam w projektach tego typu, polega na tym, że tam w ogóle ta komunikacja jest załamana. To znaczy, że jeżeli już jest rozwiązanie serverless, to jest serverless absolutny, że nie ma kompromisów. Ja tu widzę kilka szans i kilka ryzyk. Może zacznę od szans. To jest trochę takie oczekiwanie takiego poziomu dojrzałości danego rozwiązania, że człowiek już nie musi się zastanawiać, jak to działa.

I to jest często taki przykład odnośnie samochodów poruszanych, że wsiadasz do samochodu i jedziesz. I to jest trochę takie oczekiwanie, że serverless będzie już tym etapem, że wrzucisz swoją funkcję i to wszystko zadziała. Natomiast od strony ryzyk nie jesteśmy jeszcze w tym punkcie. Jesteśmy już dość blisko, szczególnie w kontekście komercyjnego, komercyjnych zastosowań dostępnych w chmurach. Natomiast jak rozmawiamy o serverlessie w kontekście on-premise'owym, gdzie tej infrastruktury poruszającej się jest mega dużo pod spodem, tak? Tak, tak, tak. To też jest wizja skali. A wiesz, to jest właśnie kwestia skali, o której trochę nawiązuję do tego, co wcześniej mówiłem, to znaczy czasami z perspektywy takiej powiedzmy architekta wiodącego, o którym jestem, mówię o kilku klientów, wdrażane są rozwiązania konteneryzacyjne, są wdrażane rozwiązania serverlessowe na różnych platformach, dość rzadko nam premię ze względu na po prostu bagaż asetowy, który trzeba ze sobą ciągnąć w postaci

Po kilku latach mamy komercyjny offering, który już spełnia te wymagania i myślę, że dokładnie to samo się dzieje z serverlessem. Możliwe, że nawet jeszcze szybciej tak naprawdę niż z kontenerami, bo W dużej mierze serwer dla nas korzysta pod spodem z technologii kontinuaryzacyjnej, bo to bardzo przyspiesza egzekucję tak naprawdę tych funkcji, limituje problem cold startu, hot startu bez wchodzenia w szczegóły, więc myślę, że to jest w zasięgu rankingu, natomiast problem widzę w innym miejscu zupełnie z adopcją tego. Mianowicie od strony takiej biznesowo-technicznej, że to co mówiliśmy w kontekście DevOps na początku, że to wymaga bardzo dużej ilości umiejętności, no ale w kontekście serverlessa nie jest prościej, bo musimy zmienić nasz w ogóle cykl dostarczania oprogramowania.

Zupełnie inaczej myślimy o tym, jak nasze oprogramowanie ma działać, żeby poprawnie konsumowało serverless. Myślę, że tu jest dużo większe wyzwanie. Jeszcze widzę jedną rzecz, która jest też istotna, to znaczy to, o czym mówisz, dojrzałość. Może i dojrzałość jest produktowa, ale rynek nie jest też dojrzały na tyle, żeby to skonsumować. To znaczy, wiesz, Po prostu nie każdy lubi baraninę. Przychodzi taki motyw, w którym masz bardzo dużo różnych technologii dostępnych na rynku, które spełniają w jakimś stopniu twoje oczekiwania i dopóki nie przełamie się ta wartość widoczna przez potencjalnego użytkownika końcowego z wdrożenia nowej technologii, to on w nią nie pójdzie. A będąc w etapie

Ale później też, bo de facto pozbywała się kupy złomu. To wszystko jakby się faktycznie ułatwiało. Natomiast przy serverlessie, przy konteneryzacji jest dokładnie tak samo, tylko do tego dochodzi jeszcze szybkość dostarczania nowych funkcji, bezpieczeństwo, dokumentacja w kodzie, ale to wymaga fundamentalnie innej zmiany, nie technologicznej, bo oni już na podział z funkcji na różne segmenty typu VM-ki ludzie się przyzwyczaili, czy tam kontenery, to dla nich percepcyjnie, technicznie nie ma większego znaczenia. Problem polega znacząco gdzie indziej, czyli w tym, Muszę przypisać ERP-a, nie? Ok, trochę mnie ściągniesz z język, że może mniej politycznie mówię.

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ć?

Ja myślę, że to się nie rozmywa, to chodzi o to, która strona to inicjuje. To znaczy, where is more fun? Jeżeli jesteś zajawiony na technologie serverlessowe, generalnie jesteś programistą, jesteś zajawiony na tym, żeby uruchamiać to w serverlessie, to po prostu masz gdzieś infrastrukturę. To jest dla ciebie no fun zone. Jeżeli ty definiujesz ten projekt, to o tym zapominasz i strzażasz to, bo nie chcesz się tym zajmować. I to znowu jest brak komunikacyjny. Zwykłej, prostej, ludzkiej komunikacji. Bo tam są ludzie, dla których to jest fan zone. Tylko trzeba się z nimi zapiąć. I ja to widzę teraz od strony właśnie kontyneryzacyjnej, bo jej jestem bliżej. To znaczy świat developerski, świat właśnie DevOpsowy uważa infrastrukturę tą twardą jako no-found zone.

Tak, albo budują np. te serverlessy na potrzeby jakiegoś małego poke itd. I później jest kwestia zbudowania tej świadomości, kto jest klientem, a kto jest konsumentem tej technologii, bo można zrobić mały projekt na 5 osób, zbudowanie przykładowego serverlessa w ramach jakiejś organizacji. Wystarczy to rozpropagować dalej w firmie. I ktoś zobaczy, że jest fajny, że się da i z tego dopiero przechodzimy do 100 milionowego projektu. I bardzo często w tym miejscu, w tym miejscu tego przejścia, Ja to widziałem parę razy w organizacjach, czasami z pozytywnym skutkiem, czasami z negatywnym, ale te przejście, ono niczyje zazwyczaj taką gigantyczną korporacyjną machinę, która dalej zapomina na pokład załabować specjalistów.

Po prostu się opłaci. Tak i nawet nie w długiej perspektywie. Dość szybko, bo dlatego, że możesz nie wybrać po prostu rozwiązań albo wybrać rozwiązania, które nie pasują albo pasują źle. Naprawdę ilość narzędzi na tym świecie jest tak ogromna, że Póki ich w kilku chociaż z nich nie przejrzysz, to może po prostu nie idź w to, co wszyscy reklamują i mówią, że jest świetne, dlatego że... No bo później wszyscy my będziemy to łatać, a na końcu wszyscy będą niezadowoleni. I my, że taka robota, i ty, że coś to wybrał. Dlatego początek konsultacyjny jest bardzo ważny i te właśnie konsultacje, żeby je przeprowadzać na tych różnych szczeblach, to znaczy, że jak chcesz iść w serverless, i kontenery, i jeszcze wirtualizacja, i hybrydowe chmury, i sześć ośrodków, i super sieć, To warto zanim to zrobisz i przybijesz pieczątkę, projekt ze 100 milionów dolarów, jesteś tym imperatorem, który tam pieczęć przyciska, po prostu być pewnym, że to zostało przejrzane, bo to jest mniej więcej jak wylot na inną planetę czasami dla niektórych klientów.

I to nieważne, czy to w stronę twardej infrastruktury, serverlessa, nie wiem, baz danych, czegokolwiek. Świat IT jest tak szeroki, że nie da się na wszystkim znać. Pamiętajmy też na koniec, że po to robimy migrację tych naszych infrastruktur, żeby globalnie poprawić efektywność. Nie poprawimy efektywności bez zrozumienia tej technologii. Myślę, że to bardzo fajny przekaz. Dziękuję Ci pięknie Łukasz. Zapraszam Was wszystkich w następny raz na leokast. Trzymajcie się, na razie.