Ten habrapost jest wywiadem z Antonem Weissem, współwłaścicielem firmy konsultingowej Otomato Software, posiadającym ponad 15-letnie doświadczenie w obszarze wysokich technologii. Jest ekspertem w zakresie nauczania technicznego, inicjatorem i współautorem pierwszego w Izraelu kursu certyfikującego DevOps. Anton uczestniczy w międzynarodowych konferencjach i jest znany jako fajny mówca.
Porozmawiamy na następujące tematy:
Różnica między Rosją a Izraelem
Oleg: Proszę, powiedz nam, kim jesteś i czym się zajmujesz.
Antoni: Mam na imię Anton, urodziłem się w Petersburgu, ale w wieku 15 lat przeprowadziłem się do Izraela i mieszkam tam do dziś. Przez ostatnie dwadzieścia lat w Izraelu zajmuję się informatyką w jej różnych odsłonach. Z tych dwudziestu lat, przez ostatnie dziesięć specjalizowałem się we wszystkim, co jest związane z dostarczaniem oprogramowania: integracją, co kiedyś nazywało się zarządzaniem konfiguracją, a teraz nazywa się DevOps. Pracowałem w dużych firmach - w przedsiębiorstwach międzynarodowych takich jak AT&T, BMC. Pracował w startupach. Od czterech lat prowadzę własną firmę konsultingową Otomato Software, w której pomagamy organizacjom optymalizować procesy dostaw i opanowywać nowe narzędzia, czyli zajmujemy się zarówno częścią techniczną, jak i wszystkim wokół niej.
Oleg: Czy istnieje różnica między Rosją a Izraelem pod względem pracy?
Antoni: Prawie nigdy nie współpracowałem z rosyjskimi klientami. To, co od 3 lat łączy mnie z Rosją, to konferencje. A w kilku rosyjskich firmach przeprowadziliśmy coś w rodzaju audytu: przyjechaliśmy, obejrzeliśmy, ustaliliśmy, wydaliśmy zalecenia i wyszliśmy. To znaczy nie było takiej codziennej pracy, więc trudno mi dokładnie powiedzieć, czym się to różni. Myślę, że wszędzie są inne rzeczy. Oznacza to, że na przykład w Izraelu mamy tak ciężkie organizacje korporacyjne, w których ludzie pracują od 15 lat i wszystko dzieje się bardzo ciężko. I nieważne, jak będą próbowali dokonać jakiejś transformacji, usprawnić procesy: będą rozmawiać i rozmawiać, ale... Mamy klienta, z którym dwa lata temu zrobiliśmy wszystko, podjęliśmy wszystkie decyzje, opracowaliśmy wszystkie programy i w pewnym momencie wszystko się zatrzymało, wydostaliśmy się stamtąd. Zaledwie kilka dni temu spotkałem się stamtąd z szefami, z którymi współpracowaliśmy, i powiedziałem:
- No cóż, jak?
- Cóż, w ten sposób. Trudno, mówią, robimy to, teraz coś zaczyna się dziać.
Dwa lata później. Jest polityka, są strefy wpływów. Są ludzie, którzy nie chcą porzucić tych stref wpływów, dlatego gdy dojdzie do takiej sytuacji, bardzo trudno jest cokolwiek zmienić. Cóż, same narzędzia jakoś posuwają się do przodu. Z drugiej strony w Izraelu są startupy, w których wszystko zmienia się bardzo szybko, łatwo jest wznieść nowe oprzyrządowanie, a do tego wszystkie są już natywne w chmurze i są całkowicie w chmurze. Nawiasem mówiąc, może to być jedna z namacalnych różnic między Rosją a Izraelem. W Izraelu chmura publiczna jest znacznie łatwiejsza. Z tego co widziałem. Na przykład w Rosji wydaje się, że każdemu z wyjątkiem startupów bardzo trudno jest przejść do chmury publicznej, ale w Izraelu jest to nadal łatwiejsze. Dziś nawet banki i firmy ubezpieczeniowe mają już pewną wiedzę, że przynajmniej część ich rzeczy można przenieść do chmury publicznej. I nikt tutaj nie boi się kontraktów z Google i Amazonem. Z tego, co słyszałem na konferencjach w Rosji, tam jest to jeszcze bardziej skomplikowane, no cóż, nawet z punktu widzenia sankcji lub ich braku i niektórych kwestii prawnych.
Różnica między startupami a gigantami
Oleg: Rozumiem. Swoją drogą, gdzie jest Ci ciekawiej i przyjemniej pracować: w startupach czy w dużych organizacjach?
Antoni: W startupach jest oczywiście przyjemniej, bo w dużych organizacjach… no tak, po prostu materiał bardzo mocno się przesuwa. Ma to oczywiście swoje zalety. Jeśli spojrzysz na duże organizacje, zauważysz, że charakteryzują się one na przykład znacznie większymi cechami tak zwanej różnorodności. Duże firmy, po prostu dlatego, że potrzebują dużej liczby osób lub dlatego, że jest to pewnego rodzaju kultura organizacyjna, która wykształciła się przez lata, są gotowe zatrudniać różnych ludzi. Konkretnie, tu, w Izraelu, na przykład, w startupach raczej nie znajdziesz np. Arabów, prawie ich nie ma. W dużych organizacjach jest to znacznie łatwiejsze. Ale startupy wyrastają z pewnego kręgu kulturowego, w którym większość uczestników to w zasadzie ci sami biali mężczyźni. Panuje tam kultura, że trzeba ciężko pracować i wskazane jest pracować 10-12 godzin dziennie, a to też nie wystarczy. Wydaje się, że mamy za sobą Moskwę (czyli Tel Awiw), nie ma gdzie się wycofać i dlatego trzeba krwawić tu i teraz.
Oleg: A co z różnicą w podejściu do DevOps w małych i dużych firmach? Oznacza to, że jeśli na przykład pracujesz dla dwóch osób, nie musisz samodzielnie konfigurować CI/CD, ale kopiuj artefakty za pomocą SCP.
Antoni: Z jednej strony tak. Z drugiej strony dzisiejsze skonfigurowanie CI/CD nie oznacza, że naprawdę realizujesz ciągłe dostarczanie. Ale skonfigurowanie dla siebie pewnego rodzaju rurociągu, jeśli jesteś firmą składającą się z dwóch osób, jest bardzo, bardzo proste. Jeśli wcześniej musiałeś się jakoś pomylić, dziś masz wiele usług w chmurze. Napisałem YAML i poszliśmy. Z tym jest łatwiej. W rzeczywistości wyzwaniem są przerośnięte startupy. Ci, którzy przeszli powyżej 20 osób i tu zaczynają odczuwać ból ze skalingiem, bo nie ma procesów. Wcześniej wszystko jakoś działało, ale teraz zaczyna się cały ten chaos i nie jest jasne, jak utrzymać tę dawną dynamikę, a jednocześnie przeprowadzić procesy i zdecydować, kto jeszcze to wszystko zrobi.
I wtedy zaczyna się cała sprawa w stylu: „będziemy mieli zespół DevOps, który będzie odpowiedzialny za DevOps”. W większości przypadków wiemy, dokąd to prowadzi. Pojawia się wąskie gardło, które stopniowo rośnie do miejsca, w którym znajdują się obecnie duże firmy. W dużych firmach problem jest zupełnie inny, nie mają już nawet wąskiego gardła, a po prostu bramę na tyle potężną, że otwiera się raz dziennie, a przez resztę czasu gromadzi się tam ogromna ilość śmieci. Dlatego myślą: „Jak możemy teraz z tej bramy zrobić wiele małych bramek, które można znacznie łatwiej otworzyć?” Czyli zupełnie inne problemy. Startupy mają problem z tym, że „wciągają nas do lejka, jak z tego wyjść?”, a duże firmy mają problem – już są w lejku, już są w podziemnym królestwie, teraz są myśląc o tym, jak mogą popłynąć z powrotem na górę.
Tendencja do zwiększania złożoności i co z tym zrobić
Oleg: No cóż, plus części technicznej: gdy jest mało ludzi, proste technologie, trzeba znać podstawy Linuksa i tyle. A przy najmniejszym skalowaniu trzeba nauczyć się jakiegoś Kubernetesa i to wydaje się być problemem.
Antoni: I to niewątpliwie jest problemem. Zaledwie dwa dni temu odbyliśmy konferencję i było bardzo zauważalne, że prawie każdy, kto coś tam powiedział, wspomniał o jednym słowie: „złożoność”. Stało się to dziś pewnym słowem definiującym cały dyskurs DevOps.
Oleg: Czy tak było rok temu?
Antoni: Próbując zrobić wszystko szybko, dynamicznie, aby osiągnąć notoryczną elastyczność, sami stworzyliśmy taką złożoność. Rzeczywiście, istnieje wiele małych rurociągów, które indywidualnie działają świetnie, a następnie staramy się z tego wszystkiego złożyć jakiś obraz świata i tu nagle pojawia się złożoność. Ponieważ z tych wszystkich małych rurociągów budujemy teraz jeden proces, aby cała firma działała jak człowiek.
Oleg: I jaka jest odpowiedź? Jak zarządzać tą złożonością?
Antoni: Cóż, odpowiedzi nie ma, rodzą się w trakcie. Mój raport dotyczył jednej z takich decyzji. W sumie, do czego to wszystko prowadzi? Kiedyś byłem zarażony myśleniem systemowym; często wspomina się o tym w DevOps. Zainteresowałem się, przeczytałem książki Petera Senge, Russella Ackoffa, Donelli Meadows – ludzi, którzy kiedyś w jakiś sposób zapoczątkowali myślenie systemowe i w zasadzie nakreślili jego główne postulaty. Jedną z głównych soczewek, przez które myślenie systemowe patrzy na świat, są pętle sprzężenia zwrotnego. Przy tej złożoności powstają teraz te pętle sprzężenia zwrotnego, to znaczy złożoność staje się bardzo, bardzo duża, zaczynamy szukać narzędzi, aby przynajmniej tę złożoność jakoś kontrolować. Nie mówię, żeby to redukować – żeby to kontrolować, żeby się nie rozpadło.
Pojawiają się rozwiązania scentralizowane; w zasadzie nawet Kubernetes jest czymś takim. Masz scentralizowaną płaszczyznę kontroli, która w momencie jej kontrolowania będzie kontrolować całą złożoność działających usług. Sito serwisowe, ta sama siatka serwisowa, to tego samego typu rozwiązanie. Mówimy: „Służb mamy dużo, potrzebujemy, żeby mogli jakoś ze sobą rozmawiać, bo nie wiadomo, gdzie siedzą i nie wiadomo, czy na nie odpowiedzą, czy nie, i nie radzą sobie to sami. Więc zróbmy to teraz, pośrodku wstawimy pewien uniwersalny umysł, który powie im, z kim mogą rozmawiać, a z kim nie, i ochroni ich, jeśli nagle w odpowiedzi powiedzą coś niegrzecznego. Wiąże się z tym wiele pytań. Z jednej strony jest to pewna konieczność, bo organizacje sobie nie radzą. W ciągu ostatnich kilku lat pomogliśmy kilku organizacjom przenieść się do nowego, wspaniałego świata Cloud Native, zwłaszcza gdy firma się rozwija, skaluje, a ludzie po prostu się gubią. Pośrodku tego wszystkiego znajduje się mały zespół tzw. DevOps, który musi napisać tysiące linii YAML, aby jakoś sobie z tym wszystkim poradzić, a wszystko po prostu rozpada się w szwach.
Natywna chmura
Oleg: Czy możesz trochę wyjaśnić, czym jest Cloud Native? Ponieważ stało się to swego rodzaju modnym hasłem, teraz wszyscy wypisują to na każdej ścianie. Jak ty to widzisz?
Antoni: Ogólnie rzecz biorąc, wszystko zaczęło się wraz z pojawieniem się podejścia „platforma jako usługa”, to znaczy, kiedy musieliśmy uruchomić znacznie więcej oprogramowania i znacznie więcej usług sieciowych niż było to potrzebne wcześniej. Zrozumieliśmy, że nie da się już prowadzić każdej usługi z osobna, niczym ukochany zwierzak, którego znamy z imienia i którym opiekujemy się całe życie, musimy się z nimi obchodzić jak ze swoim stadem. Aby to zrobić, potrzebujemy jakiejś jednorodnej platformy, na którą możemy wrzucić ten kod, a platforma będzie wystarczająco inteligentna, aby go obsłużyć. Krótko mówiąc, automat do picia to automat do picia z automatycznym podajnikiem do celów serwisowych.
Pionierami tego podejścia byli Heroku. Powiedzieli, że aby te służby mogły korzystać z naszej infrastruktury, one też muszą być krowami. Oznacza to, że muszą mieć pewne cechy. Tak pojawiła się aplikacja 12-czynnikowa, która miała mieć jak najmniej stanu stabilnego. Taka aplikacja koniecznie jest montowana przez jakiś potok, który sprawdza jej kompatybilność z platformą. Musi być odporny – wiedzieć, że jeśli coś pójdzie nie tak, nie ma potrzeby natychmiastowego upadku. Z drugiej strony w pewnym sensie polegamy na platformie. Generalnie jest to swego rodzaju hybryda. Zrozum, że nie jesteś sam, że istnieje platforma i musisz szanować jej ograniczenia. W zasadzie wszystko zaczęło się od tego.
Ale z jakiegoś powodu podejście „platforma jako usługa” nie uzasadniło się i obiecany boom nie nastąpił. To znaczy tak, był Heroku, a zaraz po nich wszyscy wielcy faceci również stworzyli analogi: Google App Engine, Amazon - Elastic Beanstalk. Musiałem dużo współpracować z firmami, które zaczynały od tego. Ale w momencie, gdy zrobisz coś, co wykracza nieco poza to, na co pozwala platforma, zamienia się to w straszny ból głowy. Ponieważ zaczynasz wpadać na ściany, które są wszędzie. I jak to zwykle bywa w przypadku ludzi, kiedy napotykają ściany, zaczynają szukać sposobu na przebicie się przez nią.
Od tego wyrósł Modern Cloud Native: jak sprawić, by działał nadal w chmurze, korzystał z niektórych usług platformy, ale jednocześnie zapewniał niesamowitą elastyczność we wszystkim, co się dzieje. Stale balansujemy pomiędzy elastycznością i prostotą. Elastyczność powoduje złożoność, a upraszczanie i tworzenie przejrzystej platformy zawsze powoduje ograniczenia. Cloud Native najwyraźniej polega na znalezieniu pewnego rodzaju równowagi pomiędzy ograniczeniami platformy chmurowej a elastycznością, na jaką pozwala chmura dzięki automatycznemu skalowaniu, a to wszystko ma swoją cenę.
Oleg: Prawdopodobnie sama organizacja musi w jakiś sposób nauczyć się procesowo żyć z tym wszystkim.
Antoni: Naturalnie, naturalnie! Wszystko to pozostawia ślad. Mikrousługi również się do tego odnoszą. W sumie to jest pomysł, że mamy małe usługi, małe aplikacje, które są rozproszone po całej chmurze i można je zlokalizować w dowolnym miejscu i czasie, a teraz może być 10 replik, a jutro - 1500, to też wszystko jest częścią Natywny w chmurze. Pomysł, że nie jesteśmy ograniczeni fizycznymi granicami centrum danych. Ogólnie rzecz biorąc, cały świat jest moją chmurą, to absolutnie cudowna wizja, cudowna aspiracja, ale ma to swoją cenę, a tą ceną jest złożoność, ceną jest to, że w zasadzie nikt nie mieści się w głowie co się stanie, gdy nasza aplikacja nagle wzrośnie z 10 instancji do 1500. Nikt nie jest w stanie sobie tego wyobrazić i zaczynają pojawiać się wszystkie artefakty skalowania. My, jako ludzie, jako operatorzy, nie możemy nic z tym zrobić poza reagowaniem na chaos, który się dzieje. I tak zaczynamy myśleć: „Jak możemy zbudować naszą aplikację i naszą infrastrukturę w taki sposób, aby w przypadku pojawienia się tych artefaktów, po pierwsze, można było je przewidzieć, a po drugie, jakoś mogliśmy sobie z nimi poradzić i kontynuować funkcjonowanie?”
Łączenie umiejętności technicznych i nietechnicznych
Oleg: Masz raporty dotyczące spraw technicznych, na przykład: są też raporty na temat przywództwa, zarządzania i tak dalej. Czy ogólnie jesteś osobą techniczną, czy jesteś menedżerem, czy może Twoja struktura jest w jakiś sposób inna?
Antoni: W pewnym momencie zaczęłam nawet pisać post na ten temat, ale jeszcze go nie skończyłam. Osobiście jestem rozdarty pomiędzy tymi dwiema rzeczami, ponieważ z jednej strony lubię rozumieć, jak coś działa, ale lubię je rozgryźć. Kiedy uda ci się rozwiązać problem techniczny, samo to daje ci po prostu niesamowite poczucie swoich możliwości, co nazywa się natychmiastową satysfakcją, natychmiastową nagrodą, przypływem dopaminy: „Och, super, dam radę, zdecydowałem. ” I trudno się poddać, trudno się od tego uwolnić. A ponieważ to już istnieje, nadal zajmuję się sprawami technicznymi. Nowe technologie mnie ekscytują: fajnie jest w coś zagłębić się, coś zrozumieć. Dzięki temu okazuje się, że skoro jest ta wiedza, to ludzie chcą ją kupować, a ja dalej ją sprzedaję.
Z drugiej strony rozumiem, że to tylko mały wycinek większego obrazu, pracuję w branży wystarczająco długo i nie mogę nie zauważyć, że technologia to tylko wycinek większego systemu, tylko jeden z elementów . Zarządzałem zespołami i rozumiem, jak ważne jest uwzględnienie interakcji technologii i narzędzi z ludźmi, którzy z nich korzystają. W końcu technologia informacyjna, a właściwie każda technologia, istnieje po to, aby ludzie mogli z niej korzystać. A tworzenie technologii bez myślenia o tym, kto z nich korzysta, jest zupełnie pozbawione sensu. Technologia sama w sobie nie jest w ogóle interesująca, chyba że pomyśli się o jej zastosowaniu, a aplikacja zawsze kojarzy się z ludźmi, którzy w jakiś sposób z niej korzystają. Dlatego też bardzo interesuje mnie wszystko, co dotyczy technologii. Czuję, że trzeba o tym rozmawiać, rozumiem, że bez tego wszystko naprawdę traci sens. Do tego stopnia, że czasami lubię siedzieć i hakować przez dwa, trzy dni, czasem tygodnie. Potrafię dać się ponieść problemowi, którego nie potrafię rozwiązać, potrafię go rozwiązać i odnieść z tego niesamowite korzyści. Ale wtedy podnoszę głowę znad klawiatury, rozglądam się i zdaję sobie sprawę, że wokół dzieje się coś, czego w żaden sposób nie mogę zignorować. A wtedy kodowanie i grzebanie przy Linuksie staje się dla mnie zupełnie nieciekawe i nieważne, a ja chcę zacząć rozwiązywać problemy na innym poziomie, na poziomie ludzkim.
Jak szybko zrozumieć DevOps
Oleg: Słuchaj, czy masz jakąś radę dla osób, które obecnie zajmują się inżynierią i jednocześnie uczą się praktyk DevOps? Jak to wszystko upchnąć w sobie i w jakiej kolejności? Relatywnie rzecz biorąc, jak zaplanować swoją karierę, aby w krótkim czasie odnieść większy sukces?
Antoni: Ech... Cóż, znowu nie ma uniwersalnej rady, z własnego doświadczenia. Przez dość długi czas, chyba przez pierwsze 10 lat mojej kariery, byłem niezadowolony ze swojego miejsca. Szukałem tego, co mi się nie podobało, skupiałem się na tym, szukałem tego, co byłoby dla mnie ciekawsze. Ale w zasadzie nic z tym nie zrobił. Główna rada brzmi: W którym momencie moja kariera nabrała tempa? Moment, w którym zacząłem mówić o rzeczach, które mnie interesują. Dziedzina wiedzy technicznej, nawet nie tylko technicznej, w ogóle dziedzina informatyki jest bardzo szeroka, czyli można być technikiem: programistą, testerem, integratorem, administratorem systemu – to wszystko różne rzeczy, każdy może znaleźć tam swoją niszę. Nie chcesz być kompletnym technikiem, interesują Cię zarówno kwestie techniczne, jak i biznesowe? Zaangażuj się w pracę nad produktem i projektem. Nisz jest wiele, znajdź swoją niszę, która będzie dla Ciebie interesująca.
Obecnie wiele mówi się o profesjonalistach w kształcie litery T. Musisz zrozumieć, gdzie jest noga twojego T, wybrać jedną rzecz i zacząć kopać w tym miejscu. W chwili, gdy zaczniesz kopać, odkryte zostaną niesamowite głębiny. Ale kopać można wszędzie. I doskonale zdaję sobie sprawę, że jest wiele obszarów, w których nie zagłębiłam się zbyt głęboko, bo próbowałam zajrzeć i zdałam sobie sprawę, że to nie dla mnie. Ale jeśli interesuje Cię kopanie, kopaj dalej, a tutaj bardzo ważne jest, aby o tym rozmawiać. To znaczy, jeszcze raz, rozumiem, że to nie jest dla każdego. Ale nawet tutaj każdy ma inne formy ekspresji: dla niektórych pisanie blogów może być odpowiednie, ale jeśli nie możesz pisać blogów literackich i śmiesznych, po prostu pisz blogi techniczne i publikuj Gists na GitHubie. Jeśli rozwiązałeś problem, opublikuj go.
Ogólnie rzecz biorąc, dziś rozwój kariery odbywa się poprzez dzielenie się. Nie bez powodu dzielenie się wiedzą jest tak ważną wartością w DevOps. Wszyscy na tym korzystają, a ty sam zawsze zyskujesz, jeśli dzielisz się swoją wiedzą. Każda osoba, która ma swój kod open source, doskonale wie, ile trzeba przeczesać kod, jak trzeba inaczej pomyśleć w momencie, gdy oddajesz go komuś innemu i rozumiesz, że ktoś inny go wykorzysta. Natychmiast wchodzą w grę te same kwestie socjotechniczne, o których mówiłem. Zaczynasz myśleć, że to nie jest tylko kod, ale kod, który przeczyta inna osoba, może będzie chciała go zmienić, będzie musiała zrozumieć, co ten kod robi. A kiedy pojawiają się te interakcje, już zaczynasz wchodzić w interakcje z innymi ludźmi w swoim mózgu. A kariera człowieka rozwija się tylko poprzez interakcję z innymi ludźmi. Ogólnie rzecz biorąc, czym jest kariera? Kariera sprawia, że staję się przydatny dla większej liczby osób, użyteczny i potrzebny. Zdobywam wiedzę potrzebną i przydatną większej liczbie osób. Aby to zrobić, musisz zrozumieć, czego ci ludzie chcą i czego potrzebują. Coś takiego. Wszystko zawsze sprowadza się do ludzi.
Oleg: Powiedzmy, że jesteśmy fajni, zajmujemy się DevOps, różnymi nowymi praktykami i tak dalej. Ale są tacy, którzy to wiedzą i szanują, ale są też wszyscy inni. I wyobraźcie sobie, że pracujecie w jakimś zespole, szczególnie w dużej firmie, a tam nadal jest... uważajmy, oni są mało znani i niezbyt szanowani. Czy są jakieś sposoby na rozpoczęcie wdrażania wszystkich tych pomysłów? Jeśli nie jesteś liderem. Jasne jest, że jeśli jesteś menadżerem, możesz po prostu powiedzieć: „Jutro to wdrożymy”. Co się stanie, jeśli jesteś zwyczajną osobą i chcesz się poprawić?
Antoni: Po pierwsze, nie jest konieczne, aby to zadziałało, jeśli jako szef powiesz: „Jutro to wdrożymy”. Ludzie będą wykonywać pewne zadania, ale to nie znaczy, że głębokie zrozumienie, dlaczego jest to realizowane, pojawi się znikąd. A przecież nikt nie lubi żadnych zmian, zwłaszcza gdy mu się mówi: „Musisz się zmienić”.
Oleg: I co robić?
Antoni: No właśnie, byłem w tym miejscu i brałem udział w realizacji takich procesów, a właściwie od dołu, będąc tylko pracownikiem zespołu, a potem już kierownikiem zespołu. Jedyne podejście, które działa, to podejście dilera narkotyków. To właśnie nazywam „współpracą opartą na usługach”, czyli współpracą zorientowaną na usługi. Ogólnie rzecz biorąc, wiesz, że masz wokół siebie ludzi, których możesz postrzegać jako swoich klientów. My coś robimy, ktoś inny to wykorzystuje. W najprostszym scenariuszu, o którym kiedyś mówił Agile: tutaj jestem programistą, mam klienta i w związku z tym muszę zrozumieć, czego chce mój klient, aby efektywnie tworzyć oprogramowanie.
W dużej firmie często nie mam bezpośredniej interakcji z klientem, z użytkownikiem. Ale wokół mnie są ludzie. Ja np. piszę bibliotekę - inni się z nią integrują, piszę jakiś backend - mam frontendowców, którzy muszą z nią porozmawiać, piszę kod - mam testerów, którzy albo piszą za mnie testy, albo ponownie daję im wersje, aby mieli coś do przetestowania. I w zasadzie wystarczy pomyśleć: „Tutaj jestem usługodawcą, mam klientów. Wszystko będzie działać najlepiej, jeśli uszczęśliwię moich klientów. Oznacza to, że jeśli moi klienci są zadowoleni, to ja będę szczęśliwy. Najwyraźniej zdobędę przede wszystkim pewną reputację, zyskam dobre nastawienie, otrzymam pozytywny feedback”. A wracając do podejścia dilera narkotyków, chcę, żeby ci klienci wracali do mnie po więcej tego samego.
To znaczy, jeśli uważam, że jakieś podejście jest słuszne, np. ciągła integracja z testami... Są programiści, którym dzisiaj na przykład trudno jest testować swoją pracę. Musimy dopilnować, aby tak naprawdę nie musieli za dużo o tym myśleć, aby jak najłatwiej przejść kontrolę. Dziś wygląda to dość banalnie, 10 lat temu wcale nie było to trywialne: w momencie kiedy wciskałem swój kod, żeby wszystko automatycznie zostało gdzieś zbudowane, wdrożone i dopiero w przypadku wystąpienia błędu dostawałem komunikat, w międzyczasie mogłem spokojnie iść napić się kawy i nie myśleć o tym, że teraz muszę uruchomić kompilację na komputerze, żeby mieć wszystkie potrzebne narzędzia, bo to też jest ból głowy. Oznacza to, że jeśli zmniejszysz ilość bólów głowy, ludzie się od tego uzależnią. Wszyscy to widzimy: w momencie, gdy masz dobrze działający rurociąg, bardzo szybko każdy, kto z niego korzysta, nie wyobraża sobie już życia bez niego. Jeśli chcę coś zmienić, muszę stworzyć proces, od którego ludzie będą w pewnym stopniu uzależnieni emocjonalnie.
Oleg: Cienki. Wiele osób ma nadzieję, że przyjdzie jakiś król, wielki przywódca lub ktoś inny i powie im, jak mają żyć, a potem wszyscy oczywiście przeniosą się do nowego, wspaniałego świata z DevOps lub czymś innym. Czy taki król jest potrzebny?
Antoni: Nie, król, który będzie ci mówił jak masz żyć, zdecydowanie nie jest potrzebny. Szefa, który chce słuchać swoich pracowników, chce im ufać i wspierać ich w wykonywaniu pracy w sposób, który jest dla nich najwygodniejszy i właściwy? Tak, taka osoba jest potrzebna, bo bez niej będzie to tylko walka. A walka podwładnych z przełożonymi nie kończy się na niczym dobrym. W rezultacie na pewno skończy się to źle dla jednej osoby, zarówno dla szefa, jak i dla podwładnych.
Problem polega jednak na tym, że bardzo trudno jest mówić ludziom, co mają robić, a czego nie. W końcu robią to, do czego podpowiada im ich pochodzenie kulturowe, ego lub chwilowy stan emocjonalny.
Najbardziej przydatne praktyki i technologie ze świata DevOps
Oleg: Nawiasem mówiąc, obecnie głosi się ogromną liczbę wszelkiego rodzaju praktyk: są podejścia od Google, są podejścia od Netflix, od najróżniejszych prelegentów z konferencji. Powiedz mi, jakie praktyki uważasz za najbardziej przydatne?
Antoni: Problem większości organizacji, niezależnie od tego, czy są one duże, czy małe (bardziej cierpią na tym start-upy), polega na tym, że nie mają przejrzystości procesów – zrozumienia tego, jak ogólnie pracujemy, jak dostarczamy oprogramowanie i gdzie pewne rzeczy utknęły. Zwykle sugeruję ćwiczenie wywodzące się z podejścia Lean Management – zwane mapowaniem strumienia wartości. Mapowanie przepływu dostarczanej wartości. Wymaga to pewnej chęci zgromadzenia w jednym pomieszczeniu głównych graczy w organizacji, wszystkich osób, które są w jakiś sposób zaangażowane w proces dostarczania: tych, którzy ustalają niezbędne zmiany, produkty, projekty, programistów, testerów, administratorów systemów, a nawet sprzedawców którzy pracują z klientami. Zbierz je wszystkie razem i zrozum, jak następuje zmiana w oprogramowaniu, jaką drogą zwykle podąża.
To wydaje się dość banalne: co tam jest? Ktoś to wymyślił, ktoś to zakodował, mamy projekt, uruchomiono go i wdrożono. Cóż, tak, wiemy, że nasza budowa tutaj zajmuje dużo czasu, tak, zdecydujemy o tym. No tak, wiemy, że programiści nie mogą teraz kompilować na swoich komputerach, bo mają Javę, wymaga to dużo pamięci, też o tym wiemy, podejmiemy decyzję. I często przychodzę do organizacji, mówią:
— Tutaj musimy to zautomatyzować, rozwiązać.
– Jesteś pewien, że od tego powinieneś zacząć? Skąd ty to wiesz?
- No cóż, nie wiemy tego na pewno, ale czujemy, że tam boli.
Jest , która mówi, że w zasadzie rozwiązanie problemu w dowolnym miejscu, które nie jest ograniczeniem, nie rozwiązuje niczego, a jedynie komplikuje problem. Wielu osobom brakuje koncepcji tego, gdzie coś utknęło i jak płynie.
Czasem po prostu nagle zbiera się różnych ludzi, ktoś mówi:
— Tutaj, w tej chwili, wydanie idzie tam do zatwierdzenia.
A drugi mówi:
- Nie, u nas tak nie jest, u nas to nie działa. Tutaj czekamy na środowisko do testów obciążeniowych.
Lub na przykład testerzy mówią:
- Tutaj, w tym miejscu, zwykle robimy to wszystko rękami.
A programiści mówią im:
- Cóż, mamy do tego zautomatyzowany proces. Dlaczego go nie użyjesz?
A testerzy mówią:
- Nie wiedzieliśmy, co to było.
Każdy zespół widzi tylko swój fragment i nikt nie widzi całości – to właśnie często wpływa na naszą zdolność do skutecznego wdrażania oprogramowania w znacznie większym stopniu niż obecność lub brak narzędzia. To są rzeczy. Warto zacząć od mapowania procesów. Oczywiste jest, że jeśli firma nie posiada obecnie żadnego CI/CD, należy to już do przeszłości. Oczywiste jest, że to również należy zbudować. Warto jednak najpierw odpowiedzieć sobie na pytanie, ile w niego zainwestować, jakie problemy rozwiąże. Wymaga to również ludzi, którzy rozumieją, jak to zrobić poprawnie.
Oleg: Z technicznego punktu widzenia na jakie technologie warto zwrócić uwagę? Jasne jest, że nie możemy już mówić o prostym CI/CD. Z jakimi fajnymi nowymi technologiami warto się zapoznać?
Antoni: Po pierwsze, dla wszystkich jest absolutnie oczywiste, że zwyciężyły kontenery. I dlatego jeśli ktoś jeszcze nie robi kontenerów to zdecydowanie trzeba się im przyjrzeć i to jak najszybciej, bo ruch idzie w tym kierunku, a duże firmy już rozumieją, że trzeba opakować swoje oprogramowanie w kontenery . Cóż, na poziomie platformy zwyciężył Kubernetes: nie ma znaczenia, czy w chmurze, czy nie – udostępnimy klientom pudełko z Kubernetesem. Teraz VMware ogłosiło, że będzie mieć Kubernetes bezpośrednio na hypervisorze. Wszystko jasne, Google wygrało. Co w sumie nikogo nie zdziwiło.
Oleg: Google wygrał?
Antoni: Cóż, jeśli spojrzymy wstecz zaledwie kilka lat temu, nadal nie było do końca jasne, czy Swarm, czy Kubernetes zostanie zabity i czy Docker zostanie zabity. Docker został zabity, to oczywiste. Oznacza to, że wszyscy wkroczyli razem, a Microsoft i Amazon również pomogły – „wszyscy razem zabijmy Dockera”. Zabity Docker! Ale ogólnie rzecz biorąc, winni byli sami Docker. Czy spodziewali się, że przyjdą, zburzą schematy dla wszystkich, nie będą chcieli nikomu sprzedawać, pokonają wszystkich na raz i od razu przytłoczą Google, Microsoft i Amazon? Prawdopodobieństwo, że coś takiego się wydarzy, było bardzo małe. Najwyraźniej nie mogli znaleźć nikogo, z kim mogliby się zaprzyjaźnić. Jeśli nie zaprzyjaźnisz się z nikim, zostaniesz porzucony. I tak się stało.
Więc oto jest. Dlatego musisz spojrzeć na pojemniki. Kontenery i orkiestracja powoli stają się dziś powszechne. Oznacza to, że obecnie raporty na konferencjach brzmią: „Nigdy nie jest za późno, aby zacząć od Kubernetes, nawet jeśli jesteś emerytem”. Więc jest to konieczne. Wokół Kubernetesa zaczyna się teraz dziać wiele ciekawych rzeczy. Ponieważ jedną z fajnych funkcji Kubernetesa jest w zasadzie stworzenie pewnego rodzaju uniwersalnego API, które pozwala nam opisywać wszystko, co dzieje się w naszej infrastrukturze. W ciągu ostatniego roku widzieliśmy próby owinięcia wokół tego interfejsu API wielu innych rzeczy. Oto service sito - jedna z takich prób, prawie wszystkie istniejące obecnie implementacje service sita, w pewnym sensie mówią: „Tutaj będziemy rozbudowywać API, dodamy inteligencję, będziemy opisywać obiekty poza Kubernetesem, ale będziemy czytać obiekty z Kubernetesa i tak dalej.”
Innym takim przykładem jest to, co dzieje się teraz z Fundacją Continuous Delivery, która powstała jakieś półtora roku temu, znowu to Google, to CloudBees, GitLab. Istnieje projekt Google Tekton, którego główną ideą jest stworzenie swego rodzaju uniwersalnego API opisującego proces ciągłego dostarczania. W zasadzie starają się to wszystko rozbić na pewne obiekty, które muszą być obecne w systemie ciągłej integracji/ciągłego dostarczania i w jakiś sposób umożliwić zapisanie tych rzeczy w Kubernetesie, aby później mogły powstać wszelkiego rodzaju różne komponenty, które potrafią odczytać te definicje i zdecydować, co z nimi zrobić. To samo dzieje się z sitami serwisowymi, pisałem o tym w swoim . Microsoft próbuje teraz określić, co powinno robić sito serwisowe, tak zwaną specyfikacją SMI. Z założeniem, że każda implementacja usługi sito będzie w stanie wykonać wszystko, co jest napisane w tej specyfikacji plus coś jeszcze.
Dlatego Kubernetes wygrał. W momencie, gdy stajesz się platformą dla dalszych innowacji, bardzo trudno Cię później gdzieś wyrzucić, bo to już na tym wyrosło, teraz wyrzucenie Kubernetesa to wylanie dziecka z kąpielą.
Z jakimi raportami warto się zapoznać?
Oleg: Do jakich raportów sam trafiasz, co uważasz za interesujące?
Antoni: Po pierwsze, jeśli jest jakaś nowość technologiczna, gadżet, którego po prostu nie miałem czasu osobiście zobaczyć, i jest głośnik, który potrafi o tym jasno powiedzieć, to myślę, że to generalnie jest szalona zaleta, bo zamiast teraz czytaj i kopiuj, a może masz trudności ze zrozumieniem, możesz przyjść i posłuchać za pół godziny, jak ktoś ci pokaże i powie. Ponownie, wymaga to pewnych umiejętności i chęci, aby móc rozmawiać o technologii. I rozumiem, że to też nie bierze się znikąd, trzeba nad tym pracować. Mi też zajęło to dużo czasu. Nawiasem mówiąc, bardzo mi w tym pomógł fakt, że zajmuję się nauczaniem technicznym. Kiedy masz przed sobą zajęcia, musisz coś ludziom wytłumaczyć i zdajesz sobie sprawę, że nieważne jak wyjaśnisz, oni i tak są głupi – wtedy zdajesz sobie sprawę, że najwyraźniej problem tkwi w tym, jak to wyjaśnisz, a nie w fakt, że ludzie są głupi.
Oleg: Jakie nauczanie techniczne? Co robisz?
Antoni: Od około 7-8 lat zajmuję się nauczaniem dyscyplin czysto technicznych. Zaczęło się od tego, że przez rok uczyłem takich rzeczy jak Maven i skrypty powłoki. Ponieważ bardzo blisko współpracowałem z Jenkinsem i dobrze o tym wiedziałem, uczyłem ludzi, jak współpracować z Jenkinsem i administracją. W ostatnich latach - wszystko co związane z cloud native: Kubernetes, kontenery i wszystko wokół. Niedługo jadę do Londynu, żeby zrobić kurs mistrzowski na Istio. Nie jest to główna część mojej działalności, ale mniej więcej raz na miesiąc lub dwa prowadzę kursy mistrzowskie.
Oleg: Czy kierujesz się głównie raportem, tematem czy osobą?
Antoni: Jeśli wiem, że mówca jest dobry, idę do tej osoby po prostu dlatego, że nadal jest dla mnie bardzo ważne, aby uczyć się od innych ludzi, jak dobrze mówić. Nauka jest zawsze ważna. Jeśli jest temat, ale nie znam prowadzącego, to idę i oglądam, ale jest tak jak zwykle, jak przy pójściu na stand-up: obejrzałem pierwsze 10-15 minut, nie nie podoba mi się to i wyszedł. Albo są prelegenci, na których i tak naprawdę pójdę, bo zawsze opowiadają ciekawe rzeczy, nawet wiedzą, jak pokazać to, co się zna z ich perspektywy, to proste, a dla Ciebie odwraca całą kwestię z nowego punktu widzenia . Z tych, których ostatnio lubię... Po pierwsze jest Simon Wardley - konsultant, ma swój własny trik z rysowaniem map, za pomocą map wyjaśnia, jak firmy mogą poprawnie budować swoją strategię, był kiedyś kimś w rodzaju... potem jest CTO, dyrektor generalny startupów, dużo mówi o tym, o technologii. Nawiasem mówiąc, stale propaguje rozwiązania bezserwerowe i twierdzi, że ci, którzy dzisiaj tego nie robią, mają duże problemy.
Oleg: To jest towarzysz, który ? Zrobił to w formie postów. Niezwykły format.
Antoni: On naprawdę mówi w bardzo zabawny sposób. Najbardziej pamiętam jego wykłady z ostatnich 2-3 lat. Cóż, oto John Willis, który przyszedł do DevOops w zeszłym roku – po prostu dlatego, że . Jest z nim pewien problem, bo dużo mówi o amerykańskiej rzeczywistości, o rzeczach, które czasami po prostu nie mają zastosowania ani do rzeczywistości rosyjskiej, ani izraelskiej. Teraz toczą jakąś wojnę z niektórymi komisjami zatwierdzającymi zmiany, o czym ciągle mówią. To najwyraźniej jest pewna rzecz, która istnieje w amerykańskich przedsiębiorstwach; istnieje proces przeprowadzania i zatwierdzania zmian w IT, który wymaga przejścia przez pewne komisje;
Oleg: Ale u nas tego nie ma – nawet nie rozumiem, o czym teraz mówisz.
Antoni: Ja też do końca nie rozumiem; w Izraelu to się też nie zdarza. I tam o tym mówią. Jeśli posłuchasz tych wszystkich towarzyszy, jak DORA, kto , też dużo o tym piszą. Ogólnie mam na myśli to, że ludzie mówią o jakimś problemie, który tylko oni mają, a ciebie to wcale nie interesuje.
Oleg: Byłeś na poprzednich DevOops, na jakie rozmowy warto pójść i przejrzeć nagrania?
Antoni: zobaczyć . Trochę interesuje mnie temat - idź.
Oleg: Myślę, że jest tam jakiś Anton Weiss. Chyba warto zajrzeć.
Antoni: Nie, nie idź na to, to trochę nudne :)
Oleg: Okej, bardzo Ci dziękuję. To było świetne! Widzę, że przesłałeś już referat na następną konferencję, zatem do zobaczenia na kolejnym DevOops!
Konferencja odbędzie się w dniach 29-30 kwietnia, tym razem w Moskwie. Istotę konferencji na temat Habré opisaliśmy w komunikacie . Program jest w fazie intensywnego kształtowania (do konferencji jeszcze wiele miesięcy), ale pierwsi prelegenci już są . Tam możesz .
Źródło: www.habr.com
