розшифровка:
Азат Хадієв: Здрастуйте. Мене звуть Азат Хадієв. Я розробник PaaS напряму Mail.ru Cloud Solutions. Зі мною тут Павло Селіванов із компанії Southbridge. Ми перебуваємо на конференції DevOpsDays. Він тут виступить з доповіддю про те, що з Kubernetes можна побудувати DevOps, але, швидше за все, у вас нічого не вийде. Чому така похмура тема?
Павло Селіванов: Вона насправді не похмура. Вона про те, що багато проблем у нашій спільноті намагаємось вирішити за допомогою технологій. І до того ж ми намагаємося вирішувати за допомогою технологій досить однобоко. Kubenetes той же - це штука, за яку відповідають, можна сказати, що Ops. Але у нас є чудове поняття DevOps інженер. Ось за Kubernetes відповідає DevOps інженер. При цьому ... Типу ви ось зробіть Kubernetes, а Dev хлопці взагалі не в курсі всіх цих кубернетесів, не в курсі, що він дозволяє робити - і все для них живе так само. І це незважаючи на те, що Kubernetes містить готові рішення, готові інструменти для того, щоб за допомогою цієї технології розтягувати цей DevOps підхід, спілкування між Dev і Ops. Ми дуже мало використовуємо цю можливість. За рахунок того, що ми навіть поточні структури перекладаємо на всі ці інструменти DevOps - Docker, Kubernetes, хмари і так далі - ми посилюємо цю ситуацію ще сильніше. І інструменти починаємо використовуватися не оскільки вони замислювалися. І довкола всіх цих технологій будуються просто страшні милиці.
Азат Хадієв: Зрозуміло. Відчувається, що тема велика. Як ти вважаєш, як найпоширеніша проблема у компаній зараз? З Kubernetes.
Павло Селіванов: З Кубернетесом найпоширеніша проблема — відсутність компетенцій. В ІТ це поширена проблема. Завжди не вистачає спеціалістів. Завжди бракує компетенцій. А зараз із Kubernetes компетенцій не вистачає. А при цьому ще стовідсотково готових рішень на ринку, які дозволяли б отримати собі Кубернетес, але при цьому не володіти необхідними компетенціями, їх ще на ринку відверто мало. А ті, що є, всі вони викликають якісь питання. Постійно з Кубернетесом ми знаходимося в пошуку людей, які в цьому розуміються. Намагаємося розробку під це підтягнути.
Азат Хадієв: А з огляду на поточний кадровий голод у IT. Котрий завжди був. І зараз є. Як ти думаєш, як у цих умовах жити? Які лайфхаки?
Павло Селіванов: Лайфхакі По-перше, з погляду хмар лайфхак має такий вигляд — а давайте ви нам віддасте частину своїх компетенцій. І ми їх заберемо собі. І займатимемося цим у собі. І це все гаразд. За винятком того, що важливо розуміти для тих, хто цим користується… Насправді чудовий момент… Але важливо розуміти, що віддай частину своїх компетенцій кудись хмарі чи провайдеру, ми у відповідь отримуємо універсальне рішення. Грубо кажучи, ми маємо базу даних, яка виконує дуже специфічні речі, і вона була дуже специфічно налаштована. Віддаючи цю базу даних у хмару, ми, звичайно, можемо звільнити адміна, який раніше займався кластерами баз даних — той самий Amazon або Google зробить це за нас. Але при цьому той самий Amazon чи Google не дозволять нам чітко налаштувати нашу базу даних. Великі проекти, великі компанії — вони в будь-якому разі приходять до того, що на якомусь етапі свого життя використовує хмарні рішення, а потім у будь-якому разі повертаються до того, щоб забрати компетенції назад собі, бо потрібні специфічніші.
Азат Хадієв: Універсальні рішення — погано чи на їхній базі можна більше збудувати?
Павло Селіванов: Ні, універсальні рішення — це точно непогано. Універсальні рішення – це добре. Просто універсальні рішення... універсальні. Тут важливо розуміти. Це як взяти загальний скрипт… Якщо ти довкола цього загального скрипту, загального застосування зможеш побудувати всю-всю логіку роботи компанії — це кльово. А якщо логіка роботи інша, але ти береш це універсальне рішення, універсальний скрипт і починаєш, як сову на глобус натягувати, це погано. А в самому універсалізмі немає нічого поганого.
Азат Хадієв: Якщо адмін цей у тебе вже працює, то справа не в його звільненні. Він просто зможе більше робити.
Павло Селіванов: Так, забрати у нього рутину віддати їх кудись комусь, щоби їх робили десь там. Це, безумовно, хороший підхід. Важливий момент тут чи підходить це стандартне рішення під конкретний кейс.
Азат Хадієв: Просто виходячи зі свого досвіду ось бачу, що багато компаній займаються одним і тим самим. Вони налаштовують кубернетес кластер, думають про його масштабування. І всі ці операції дуже повторювані.
Павло Селіванов: Так, безперечно. Тим більше, що якщо ми візьмемо саме Кубернетес, тут є такий момент, що глибоких, добрих знань сьогодні по Кубернетесу зараз на ринку реально мало. І Кубернетес це такий гігантський конструктор, що якщо ви його взяли в компанію, будьте готові брати разом з ним інженера, який на фултаймі буде всім цим займатися. І це дорого. І такого інженера спробуй ще знайти. Якщо я говоритиму про себе, я не дуже люблю якісь клаудні рішення, тому що я досить добре і глибоко розумію, як працює Кубернетес. І мені часто в клаудах якраз і не вистачає якоїсь функціональності, яку я прошу — а мені кажуть «Ні, не можна». Ну, у такому разі вибач, але я можу краще, ніж клауд. Але в той же час, якщо у вас немає інженера на fulltime, немає бажання платити за цього інженера, який тягне Кубернетес, і ви йому постійно платите багато грошей, щоб він просто експериментував, то cloud — це гарне відмінне рішення. Бо бодай там сидять хлопці, яких провайдер сам уже нахантив. І вони розуміються на тому, що вони роблять. І ті базові речі, які вам потрібні на щоденній основі, там є.
Азат Хадієв: Як ти думаєш щодо поточного стану Kubernetes? Що з ним буде через п'ять і десять років?
Павло Селіванов: Гарне питання. Я просто знаю, що у нас відбувається у ком'юніті з цього приводу. Деякі люди вірять, що, крім Кубернетеса, нічого не залишиться. Та ситуація, яка давно сталася із лінуксами. Тобто поза Linux є люди, які живуть на BSD, швидше за все, у них дуже специфічні завдання. Є люди, які працюють під Windows - windows-сервера - швидше за все, у них теж є специфічні завдання, або є просто компетенція в цій справі і вони не готові їхати звідти. У будь-якому випадку, стандарт у нашій сфері – це Linux. Ось є думка, що Kubernetes стане таким самим стандартом де-факто, і крім Кубернетеса нічого не буде. Кубернетес керуватиме не лише додатками, їх розгортанням, деплоєм, масштабуванням. Загалом усім керувати. Зараз уже запитують: «А чи можна в Kubernetes запхати базу даних». Я зазвичай говорю про те, що тут питання не в Кубернетесі, а в Docker. Якщо ви готові, що ваша база даних буде працювати в контейнерах, як вона буде працювати. Мені відповідають: «Не-не-не, зачекайте. У контейнери не потрібно. Потрібно у Кубернетес. Ми її прищепимо до ноди. Тобто все буде, як у нас зараз, тільки всім цим керуватиме Кубернетес.» І це гарна ідея насправді. Тобто Кубернетес — це така штука, коли можна прийти в компанію, якщо в компанії є Кубернетес і на ньому побудовані процеси, то людині, яка в цьому розуміється, їй достатньо подивитися кілька днів, щоб сказати: «Я готовий вас підтримувати. Повністю. Цілком. Я зрозумів, як у вас працює». На відміну від підходів без Кубернетеса, тут одні милиці запихали, тут інші милиці. Тут Ansible, тут Terraform. Кимось усе це написано, і треба півроку, щоби розібратися. Ось. Тож чи стане Кубернетес стандартом де-факто, я не знаю. На поточний день він виглядає набагато амбітніше і впевненіше, ніж рішення, які навколо нього є.
Азат Хадієв: Ну, порівняння з Linux досить сміливе. Він працює на одній машині — і все. А Кубернетес працює на багатьох машинах. Відразу виникає мільйон варіацій, причин. Так, це сміливо. Просто якщо враховуватися, що є конкуренти цієї парадигми. Наприклад, Serverless. Кубернетес у небезпеці за таких конкурентів?
Павло Селіванов: Від Serverless… (сміх) Serverless — ми ж таки розумінням, що сервери таки є. Я ось недавно чув із цього приводу доповідь. Там людина сказала, що сервера таки є — і це хмара. Але ми завжди маємо розуміти, що хмара — там теж є сервери. Там стоять реальні залізні сервери, стійка, і ось вони десь встановлені. Ось ця хмара. Поверх цього існує Serverless, де серверів немає. Тому питання чи переможе Serverless Kubernetes? Мені здається, що Serverless поїде до Kubernetes. Для провайдерів, які надають Serverless, Kubernetes є дуже зручна платформа, щоб це надавати. Так, можливо, в якийсь момент ми перестанемо говорити про Кубернетес у принципі як про рядову розробку бізнес-додатків. Але десь у глибині, у провайдерів та інженерів буде стоять Кубернетес, де все це буде реалізовано.
Азат Хадієв: Трохи інша тема. Є таке поняття fullstack-інженер. Що ти думаєш про них? Вони взагалі є?
Павло Селіванов: Ем… Fullstack-інженер… Ну мені здається, що варто розмежувати ці речі про те, що… Знаєш, є така штука, як T-shaped people. Чи потрібні такі люди у сьогоднішній індустрії? Так, потрібні, безумовно. Нам потрібні люди, які мають широкий кругозір, але при цьому вони спеціалісти у якійсь вузькій своїй галузі. І ось тут Fullstack-інженер те саме — людина, яка робить все. Починаючи від розробки фронтенду, тестування, бекенд, сервера та все інше. Я не вірю, що у великій компанії цим може займатися одна людина, не маючи вузьких спеціалізацій щодо кожного з параметрів. Але при цьому просто маючи вузьку спеціалізацію, типу навколо цього, що відбувається, я нічого не знаю — це теж у сучасному світі не працює. Що тут би я сказав… слово Fullstack я би відкинув. Нам потрібні дуже інженери. Потрібні нам DevOps. Відчуваю, що ми скоро переглянемо цей момент. І вони не будуть потрібні.
Азат Хадієв: Чи можеш розкрити?
Павло Селіванов: Мені здається, що ми в індустрії прийдемо до того, що ці ролі Dev та Ops вони скоро відпадуть. Якщо нам потрібні фахівці і ми хантимо ... Потрібен розробник такий, потрібні адміністратори такі, потрібні DevOps-інженери - тепер вони у нас з'явилися, зараз з'являться продакшн-інженери, SRE-інженери. Хоча насправді те, що нам потрібно, це інженери, яких ми хочемо на роботу взяти. Бекграунд, за великим рахунком, не важливий. Тому що… Наприклад, SRE каже, що проблеми інфраструктури вони завжди софтварні. А що… Давайте брати розробників — з погляду, що розробник це інженер — саджати їх у відділ супроводу і вони вирішуватимуть ці проблеми так само, як вони вирішують бізнес-проблеми за допомогою коду, за допомогою інженерії як такої.
Азат Хадієв: А з цього погляду... Як співбесідувати таких інженерів?
Павло Селіванов: Ох, гарне питання. Він, напевно, вже за межею того, що я розумію в цьому житті. Але я просто приклад би навів. Він до співбесіди відношення не має. Це про нашу систему освіти у Росії. В IT ми знаємо, що наша система освіти в Росії для IT-світу дуже застаріла, вона не така, як має бути. Я говорю в середньому про Росію неосяжну — і що там відбувається. Випускаються люди, які абсолютно не готові піти завтра після випуску піти в веб-розробку, в технологічну компанію. І типу це погано. Ми навчаємо їх якимось дивним речам, хоча начебто маємо вчити розробляти їх під Android, під iOS, як користуватися Git та всім цим речам. Насправді начебто ні. Інститут — це такий час, коли за тебе здебільшого платять батьки. За все твоє життя. І ти можеш присвятити п'ять років свого життя, щоб глибоко навчатися. І вивчати весь цей T-shaped. Коли ти можеш в інституті вивчати, що таке система контролю версій, які бувають патерни розробки, як це справа тестувати, які бувають бази даних, балансувальники. А коли ти вже йдеш працювати, ти починаєш заглиблюватись у якійсь конкретній галузі. Та таким чином ми отримуємо інженерів. І ось наша система освіти в Росії набагато ближча до цієї правди, ніж нам здається. Нам дають хорошу математичну підготовку, дають хорошу алгоритмічну підготовку, нам дають якесь уявлення про мови програмування. І про співбесіду мені здається щось близьке до цього. Інженерів нам треба співбесідувати. Нам потрібна верхня частина букви T у T-shaped. Тому що вертикальної межі літери Т він набуде.
Азат Хадієв: Так, цікаво. Мені п'ять років після інституту здавалося, що моя освіта була якась дивна та неадекватна. А потім уже по ходу роботи, коли завдання стали глибшими, проекти більші, я усвідомив, що ні, мене вчили дуже важливим речам. Павле, дякую тобі. Було дуже цікаво послухати відповіді. Послухаймо твою доповідь.
Павло Селіванов: Дякую вам.
Джерело: habr.com