Tłumaczenie:
Azat Khadiev: Dzień dobry. Nazywam się Azat Khadiev. Jestem deweloperem w dziale PaaS w Mail.ru Cloud Solutions. Ze mną jest tutaj Pavel Selivanov z firmy Southbridge. Jesteśmy na konferencji DevOpsDays. On wygłosi tutaj wykład na temat tego, jak z Kubernetes można zbudować DevOps, ale prawdopodobnie nic z tego nie wyjdzie. Dlaczego taki ponury temat?
Pavel Selivanov: W rzeczywistości nie jest to ponury temat. Chodzi o to, że wiele problemów w naszej społeczności próbujemy rozwiązać za pomocą technologii. Przy tym staramy się rozwiązywać te problemy w sposób dość jednostronny. Kubernetes to coś, za co odpowiada, można powiedzieć, że Ops. Ale mamy wspaniałe pojęcie inżyniera DevOps. To inżynier DevOps odpowiada za Kubernetes. Przy tym... Po prostu zróbcie Kubernetes, a deweloperzy nie mają w ogóle pojęcia o tych wszystkich kubernetach, nie wiedzą, co on pozwala robić — i dla nich wszystko żyje dokładnie tak samo. I to pomimo faktu, że Kubernetes zawiera gotowe rozwiązania, gotowe narzędzia, które pozwalają rozszerzać podejście DevOps, komunikację między Dev a Ops. Bardzo mało korzystamy z tej możliwości. Poprzez to, że nawet aktualne struktury przenosimy na wszystkie te narzędzia DevOps — Docker, Kubernetes, chmury itd. — pogarszamy tę sytuację jeszcze bardziej. I narzędzia zaczynamy wykorzystywać nie tak, jak były zamierzone. A wokół wszystkich tych technologii budują się po prostu straszne obejścia.
Azat Khadiev: Rozumiem. Widać, że temat jest obszerny. Jak sądzisz, jaki jest najbardziej powszechny problem, z którym borykają się teraz firmy? Z Kubernetes.
Pavel Selivanov: Najbardziej powszechnym problemem z Kubernetesem jest brak kompetencji. W IT jest to powszechny problem. Zawsze brakuje specjalistów. Zawsze brakuje kompetencji. A teraz z Kubernetesem brakuje kompetencji. A przy tym jest bardzo mało gotowych rozwiązań na rynku, które pozwalają na zdobycie Kubernetes, ale jednocześnie nie wymagają posiadania niezbędnych kompetencji. A te, które są, wszystkie budzą jakieś wątpliwości. Stale szukamy ludzi, którzy się na tym znają. Staramy się dostosować rozwój do tego.
Azat Khadiev: Biorąc pod uwagę aktualny brak kadry w IT. Który zawsze istniał. I wciąż istnieje. Jak sądzisz, jak w tych warunkach można żyć? Jakie są przydatne wskazówki?
Pavel Selivanov: Wskazówki. Po pierwsze, z perspektywy chmur wskazówka wygląda tak - oddajcie nam część swoich kompetencji. My je przejmiemy. I będziemy się tym zajmować wewnętrznie. I to jest w porządku. Z wyjątkiem tego, że ważne jest, aby zrozumieć dla tych, którzy z tego korzystają... To naprawdę wspaniały moment... Ale ważne jest, aby zrozumieć, że oddając część swoich kompetencji gdzieś chmurze lub dostawcy, w zamian otrzymujemy uniwersalne rozwiązanie. Mówiąc prosto, mamy bazę danych, która wykonuje bardzo specyficzne zadania, i była bardzo specyficznie skonfigurowana. Oddając tę bazę danych do chmury, oczywiście możemy zwolnić administratora, który wcześniej zajmował się klastrami baz danych – to samo Amazon lub Google zrobi za nas. Ale przy tym Amazon lub Google nie pozwolą nam dokładnie skonfigurować naszej bazy danych. Duże projekty, duże firmy - w każdym razie dochodzą do momentu, w którym na pewnym etapie swojego rozwoju korzystają z rozwiązań chmurowych, a potem i tak wracają do tego, aby odzyskać swoje kompetencje, ponieważ wymagana jest bardziej specyficzna konfiguracja.
Azat Khadiev: Czy uniwersalne rozwiązania są złe, czy można na ich podstawie zbudować więcej?
Pavel Selivanov: Nie, uniwersalne rozwiązania na pewno nie są złe. Uniwersalne rozwiązania to dobre rozwiązania. Po prostu uniwersalne rozwiązania... są uniwersalne. Ważne jest, aby to zrozumieć. To jak wziąć ogólny skrypt... Jeśli potrafisz zbudować całą logikę działania firmy wokół tego ogólnego skryptu, to jest świetne. A jeśli logika działania jest inna, a ty bierzesz to uniwersalne rozwiązanie, uniwersalny skrypt – i zaczynasz, jak sowę na globus naciągać, to jest źle. A w samym uniwersalizmie nie ma nic złego.
Azat Khadiev: Jeśli administrator już u ciebie pracuje, to nie chodzi o jego zwolnienie. On po prostu będzie mógł robić więcej.
Pavel Selivanov: Tak, warto zabrać mu rutynowe działania i oddać je komuś innemu, aby zajmowano się nimi gdzie indziej. To niewątpliwie dobry sposób. Ważnym punktem jest, czy to uniwersalne rozwiązanie pasuje do konkretnego przypadku.
Azat Khadiev: Z doświadczenia widzę, że wiele firm zajmuje się tym samym. Konfigurują klastry Kubernetes, myślą o ich skalowalności. Wszystkie te operacje są bardzo powtarzalne.
Pavel Selivanov: Tak, zdecydowanie. Zwłaszcza jeśli spojrzymy konkretnie na Kubernetes, jest taki moment, że na rynku naprawdę brakuje głębokiej, dobrej wiedzy na jego temat. Kubernetes to ogromny konstruktor, więc jeśli wprowadzisz go do firmy, przygotuj się na zatrudnienie inżyniera, który będzie z nim pracował na pełny etat. A to kosztuje. I takiego inżyniera jeszcze spróbuj znaleźć. Mówiąc o sobie, nie lubię zbytnio cloudowych rozwiązań, ponieważ bardzo dobrze i głęboko rozumiem, jak działa Kubernetes. Często w chmurach brakuje mi jakiejś funkcjonalności, którą staram się uzyskać — a oni mówią „Nie, to niemożliwe”. W takim przypadku przepraszam, ale mogę zrobić to lepiej niż chmura. Ale jednocześnie, jeśli nie masz inżyniera na pełen etat, nie chcesz płacić za inżyniera, który obsługuje Kubernetes, i płacisz mu ciągle dużo pieniędzy, aby tylko eksperymentował, to chmura to po prostu świetne rozwiązanie. Bo przynajmniej tam są ludzie, których dostawca już zatrudnił. I wiedzą, co robią. A te podstawowe rzeczy, które potrzebujesz na co dzień, są tam dostępne.
Azat Khadiev: Co myślisz o obecnym stanie Kubernetes? Co się z nim stanie za pięć i za dziesięć lat?
Pavel Selivanov: Dobre pytanie. Po prostu wiem, co się dzieje w naszej społeczności w tej kwestii. Niektórzy ludzie wierzą, że poza Kubernetesem nic nie zostanie. Taka sytuacja miała miejsce z systemami Linux. To znaczy, że poza Linuksem są ludzie, którzy korzystają z BSD, prawdopodobnie mają bardzo specyficzne zadania. Są ludzie, którzy pracują na Windows — serwery Windows — prawdopodobnie również mają specyficzne zadania lub mają po prostu kompetencje w tej dziedzinie i nie są gotowi się stąd wyprowadzić. W każdym razie standardem w naszej dziedzinie jest Linux. Istnieje opinia, że Kubernetes stanie się takim samym standardem de facto, a poza Kubernetesem nic nie będzie. Kubernetes będzie zarządzać nie tylko aplikacjami, ich wdrażaniem, deployem, skalowaniem. Generalnie wszystkim. Już teraz pytają: „Czy można w Kubernetes włożyć bazę danych”. Zwykle mówię, że tutaj pytanie nie dotyczy Kubernetes, a Dockera. Jeśli jesteś gotowy, aby twoja baza danych działała w kontenerach, to jak ona będzie działać. Odpowiadają mi: „Nie, nie, nie, poczekaj. W kontenery nie trzeba. Musi być w Kubernetes. Przyczepimy ją do węzła. To znaczy, wszystko będzie, jak mamy teraz, tylko tym wszystkim będzie zarządzać Kubernetes.” I to jest naprawdę dobry pomysł. Znaczy, Kubernetes to coś takiego, że można przyjść do firmy, jeśli w firmie jest Kubernetes i na nim zbudowane procesy, to osobie, która się w tym orientuje — wystarczy popatrzeć przez kilka dni, żeby powiedzieć: „Jestem gotów was wspierać. Całkowicie. W całości. Zrozumiałem, jak u was co działa”. W przeciwieństwie do podejść bez Kubernetes — tu wsadzono różne prowizorki, tu inne prowizorki. Tu Ansible, tu Terraform. To wszystko napisane przez kogoś i potrzeba pół roku, żeby to zrozumieć. Tak. Czy Kubernetes stanie się standardem de facto, nie wiem. Na dzień dzisiejszy wygląda znacznie bardziej ambitnie i pewniej niż rozwiązania, które są wokół niego.
Azat Khadiev: No, porównanie z Linuxem jest dość odważne. On działa na jednej maszynie — i to wszystko. A Kubernetes działa na wielu maszynach. Od razu pojawia się milion wariacji, powodów. Tak, to odważne. Po prostu jeśli uwzględnić, że są konkurenci dla tej paradygmy. Na przykład, Serverless. Kubernetes jest w niebezpieczeństwie przy takich konkurentach?
Pawel Seliwanow: Od Serverless... (śmiech) Serverless — musimy zrozumieć, że serwera jednak są. Ostatnio słyszałem na ten temat wykład. Tam człowiek powiedział, że serwery jednak istnieją — i to jest chmura. Ale zawsze musimy pamiętać, że w chmurze — są też serwery. Tam stoją prawdziwe serwery, w szafach, i są gdzieś zainstalowane. To jest ta chmura. Na tym istnieje Serverless, gdzie serwerów „nie”. Więc pytanie, czy Serverless zwycięży Kubernetes? Wydaje mi się, że Serverless przeniesie się na Kubernetes. Dla dostawców, którzy oferują Serverless, Kubernetes jest bardzo wygodną platformą do tego, aby to oferować. Tak, możliwe, że w pewnym momencie przestaniemy mówić o Kubernetes w ogóle, jako o zwyczajnym rozwijaniu aplikacji biznesowych. Ale gdzieś w głębi, u dostawców i inżynierów będzie stał Kubernetes, gdzie wszystko to będzie realizowane.
Azat Chadiyev: Trochę inny temat. Istnieje takie pojęcie jak inżynier fullstack. Co o nich sądzisz? Czy oni w ogóle istnieją?
Pawel Seliwanow: Ehm... Inżynier fullstack... Cóż, wydaje mi się, że warto rozgraniczyć te kwestie o tym, że... Wiesz, jest taka rzecz jak ludzie w kształcie litery T. Czy tacy ludzie są potrzebni w dzisiejszej branży? Tak, bez wątpienia. Potrzebujemy ludzi, którzy mają szeroką wiedzę, ale jednocześnie są specjalistami w swojej wąskiej dziedzinie. I tutaj inżynier fullstack to to samo — osoba, która robi wszystko. Zaczynając od rozwoju front-end, testowania, back-end, serwerów i wszystkiego innego. Nie wierzę, że w dużej firmie może się tym zajmować jedna osoba, nie mając wąskich specjalizacji w każdym z tych parametrów. Ale jednocześnie, mając jedynie wąską specjalizację, typu nie wiem, co się dzieje wokół tego — to także nie działa w nowoczesnym świecie. Więc powiedziałbym... słowo Fullstack bym odrzucił. Potrzebujemy inżynierów bardzo. Potrzebujemy DevOps. Czuję, że wkrótce przemyślimy tę kwestię. I oni będą niepotrzebni.
Azat Chadiyev: Możesz to wyjaśnić?
Paweł Selivanov: Wydaje mi się, że w naszej branży dojdziemy do momentu, w którym te role Dev i Ops szybko znikną. Jeśli potrzebujemy specjalistów i prowadzimy rekrutację… Potrzebny jest określony programista, potrzebni są tacy administratorzy, potrzebni są inżynierowie DevOps — teraz już ich mamy, a wkrótce pojawią się jeszcze inżynierowie produkcji i inżynierowie SRE. Chociaż tak naprawdę to, czego potrzebujemy, to inżynierowie, których chcemy zatrudnić. Tło nie jest w zasadzie ważne. Bo… Na przykład inżynier SRE mówi, że problemy infrastruktury są zawsze problemami związanymi z oprogramowaniem. A co… Zatrudnijmy programistów — z punktu widzenia, że programista to inżynier — wsadźmy ich do działu wsparcia, a będą rozwiązywać te problemy tak samo, jak rozwiązują problemy biznesowe przy pomocy kodu, przy pomocy inżynierii.
Azat Khadiev: A z tej perspektywy… Jak przeprowadzać rozmowy kwalifikacyjne z takimi inżynierami?
Pavel Selivanov: Oh, that's a good question. It's probably beyond what I understand in this life. But I would like to give an example. It doesn't relate to the interview topic. It's about our education system in Russia. In IT, we know that our education system in Russia is very outdated for the IT world; it’s not what it should be. I'm speaking generally about the vast Russia and what's happening there. Graduates are coming out who are completely unprepared to start working in web development or a tech company right after graduation. And that's a problem. We're teaching them some strange things when, supposedly, we should be teaching them how to develop for Android, iOS, how to use Git, and all these things. In reality, it seems like we’re not. College is a time when, for the most part, your parents pay for you. For your entire life. And you can dedicate five years of your life to studying in-depth. Studying all of this T-shaped knowledge. While in college, you can learn about version control systems, various development patterns, how to test everything, and the different types of databases and load balancers. Then, when you start working, you dive deeper into a specific area. And this way, we get engineers. Our education system in Russia is much closer to this reality than we think. We receive a good mathematical foundation, a solid algorithmic education, and a certain understanding of programming languages. And regarding interviews, I think it’s something close to that. We need to interview engineers. We need the top part of the T in T-shaped. Because they'll acquire the vertical line of the T.
Azat Khadiyev: Yes, interesting. For five years after college, I thought my education was somewhat strange and inadequate. But then, as I progressed in my work, with deeper tasks and bigger projects, I realized that no, I was taught very important things. Pavel, thank you. It was very interesting to hear your answers. Let's listen to your presentation.
Pavel Selivanov: Thank you.
Źródło: habr.com
