Цей хабрапост — інтерв'ю з Антоном Вайсом, співвласником технологічного консалтингу Otomato Software, володарем більш ніж 15-річного досвіду у галузі високих технологій. Є експертом з технічного викладання, ініціатором та співавтором першого в Ізраїлі курсу DevOps-сертифікації. Антон бере участь у міжнародних конференціях та відомий як крутий доповідач.
Ми поговоримо на такі теми:
Різниця між Росією та Ізраїлем
Олег: Розкажи, будь ласка, хто ти такий і чим займаєшся.
Антон: Я — Антон, народився у Пітері, але у 15 років переїхав до Ізраїлю і з того часу живу там. Останні двадцять років в Ізраїлі займаюся IT у різних його іпостасях. З цих двадцяти років останні десять спеціалізуюся на всьому, що пов'язане з доставкою програмного забезпечення: інтеграцією, тим, що називалося свого часу configuration management, і тим, що тепер називається DevOps. Я працював у великих компаніях – у міжнародних ентерпрайзах типу AT&T, BMC. Працював у стартапах. Останні чотири роки маю свою консалтингову компанію, називається Otomato Software, де ми займаємося тим, що допомагаємо організаціям оптимізувати процеси доставки та освоювати нові інструменти: тобто ми робимо і технічну частину, і все що навколо.
Олег: А чи є різниця між Росією та Ізраїлем у плані роботи?
Антон: З російськими клієнтами майже не працював. Те, що мене пов'язує з Росією останні 3 роки, — це конференції. І в кількох російських компаніях ми проводили щось на кшталт аудиту: приїхали, подивилися, розібралися, видали якісь рекомендації та поїхали. Тобто конкретно такої повсякденної роботи не було, тому мені важко сказати, чим відрізняється. Я думаю, що скрізь є різне. Тобто в тому самому Ізраїлі ми маємо такі важкі корпоративні організації, в яких люди працюють уже по 15 років, і все дуже важко рухається. І хоч би як вони там намагалися зробити якусь трансформацію, покращити процеси: вони поговорять-поговорять, але... У нас є такий клієнт, з яким два роки тому ми все зробили і прийняли всі рішення, розробили всі програми, і в якій- то момент це все зупинилося, ми звідти вийшли. Ось буквально пару днів тому зустрів звідти начальників, з якими ми працювали, говорю:
- Ну як?
- Ну так. Важко, кажуть, робимо, ось зараз щось починає відбуватися.
Через два роки. Є політика, є зони впливу. Є люди, які не хочуть ці зони впливу відпускати, відповідно, коли така ситуація дуже важко щось змінити. Ну а сам собою інструментарій якось рухається вперед. З іншого боку, в Ізраїлі є стартапи, в яких все змінюється дуже швидко, легко піднімати новий тулінг, і вони вже всі cloud native і повністю сидять у хмарі. Ось це, до речі, може бути одна з таких відчутних різниць між Росією та Ізраїлем. В Ізраїлі з публічною хмарою набагато простіше. З того, що я побачив. У Росії, наприклад, здається, всім, крім стартапів, дуже важко йти в публічну хмару, а в Ізраїлі все-таки легше. Сьогодні вже є певне розуміння навіть у банків, страхових компаній, що принаймні частину своїх речей можна викочувати в публічну хмару. І тут нікого не лякають контракти з Google та Amazon. З того, що я чув на конференціях у Росії, там все-таки це все ще поки що складніше, ну навіть з погляду санкцій-не санкцій та якихось юридичних питань.
Різниця між стартапами та гігантами
Олег: Я зрозумів. До речі, де тобі цікавіше та приємніше працюється: у стартапах чи у великих організаціях?
Антон: Приємніше, ясна річ, у стартапах, тому що великі організації… ну реально просто матеріал дуже важко рухається. Там є свої переваги, звісно. Якщо подивитися на великі організації, то у них, наприклад, набагато більше того, що називається diversity. Великі компанії просто через те, що їм потрібно багато людей, чи через те, що це якась організаційна культура, яка складалася роками, готові різних людей наймати. Ось саме у нас в Ізраїлі, наприклад, у стартапах ти майже не знайдеш, наприклад, арабів, їх майже немає. У великих організаціях із цим набагато простіше. А ось стартапи виростають уже з якогось культурного бекграунду, в якому більшість учасників — це переважно ті самі білі чоловіки. Там є культура того, що потрібно як слід порватися, і бажано попрацювати 10-12 годин на день, і це теж обмаль. Здається, ніби у нас за спиною Москва (тобто Тель-Авів), відступати нікуди, і тому маємо ось тут і зараз кров'ю стікати.
Олег: А що з різницею у підході до DevOps у маленьких та великих компаніях? Тобто якщо ти, наприклад, працюєш на дві людини, ти можеш не налаштовувати собі CI/CD, а копіювати артефакти SCP.
Антон: З одного боку, так. А з іншого боку, сьогодні налаштувати CI/CD ще не означає, що ти справді робиш continuous delivery. Але налаштувати собі пайплайн якийсь, якщо ти компанія з двох людей, дуже просто. Якщо раніше тобі треба було якось заморочитись, то сьогодні в тебе повно хмарних сервісів. Написав YAML – і вперед, поїхали. Із цим простіше. Насправді челендж являють собою стартапи-переростки. Ті, що вийшли за 20 осіб, і ось тут у них починаються болі з масштабуванням, бо процесів немає. Раніше все якось працювало, а тут починається весь цей бардак, і незрозуміло, як нам зберегти цю колишню динамічність і при цьому вести процеси, і вирішити, хто ще цим займатиметься.
І ось тоді починаються всі речі типу «у нас буде команда DevOps, яка відповідатиме за DevOps», ми знаємо, до чого це здебільшого призводить. З'являється пляшкова шийка, і поступово вони ростуть туди, де зараз є великі компанії. У великих компаніях зовсім інше лихо, у них вже є навіть не пляшкове шийка, а вже просто шлюз такий потужний, який відкривається щодня, і весь час там накопичується величезна кількість сміття. І ось вони думають: "Як нам зараз із цього шлюзу зробити багато маленьких шлюзиків, які можна буде відкривати набагато простіше?" Тобто, зовсім інші проблеми. У стартапів проблема з тим, що «нас засмоктує у вирву, як нам виплисти?», а у великих компаній вони вже у вирві, вони вже в підземному царстві, тепер вони думають, як їм виплисти назад нагору.
Тенденція до збільшення складності і що з цим робити
Олег: Ну і плюс технічної частини: коли в тебе мало людей, прості технології, тобі треба знати якийсь базовий Linux, І все. А при найменшому масштабуванні тобі потрібно якийсь Kubernetes вивчити, і це, здається, проблема.
Антон: І це, безперечно, проблема. У нас була конференція буквально два дні тому, і було дуже відчутно, що майже всі, хто щось там говорив, згадували одне слово: "complexity" (складність). Це стало якимось визначальним словом взагалі всього DevOps-дискурсу сьогодні.
Олег: А було так рік тому?
Антон: У спробах зробити все швидко, динамічно, для досягнення горезвісної гнучкості ми собі накрутили таку складність. Справді, дуже багато маленьких пайплайників, які окремо працюють чудово, а потім ми намагаємось зібрати з усього цього якусь картину світу, і ось там складність раптом і зароджується. Тому що ми з усіх цих маленьких пайплайників тепер будуємо якийсь процес так, щоб вся компанія працювала по-людськи.
Олег: І яка відповідь? Як цією складністю керувати?
Антон: Ну, немає відповідей, вони в процесі народжуються. Моя доповідь була про одне з таких рішень. За великим рахунком, це все до чого йде? Я свого часу був заражений системним мисленням, у DevOps про нього багато згадується. Я зацікавився, я почитав книжки Пітера Сенге, Рассела Акоффа, Донелли Медоуз — людей, які свого часу системне мислення якимось чином починали і, за великим рахунком, основні його постулати виклали. Одна з основних призм, через які системне мислення дивиться на світ, — петлі зворотного зв'язку. З цією складністю зараз виникають ці петлі зворотного зв'язку, тобто складність стає дуже і дуже високою, ми починаємо шукати інструменти для того, щоб якось цю складність хоча б узяти в вуздечку. Я не кажу зменшити - взяти в вуздечку, щоб не розкотило.
З'являються централізовані рішення, за великим рахунком, навіть Kubernetes — це щось таке. У тебе є централізований control plane, який у той момент, коли ти його контролюєш, контролюватиме всю складність тих сервісів, які біжать довкола. Сервісне сито, це service mesh, це такого ж типу рішення. Ми говоримо: «У нас купа сервісів, потрібно, щоб вони могли розмовляти якось один з одним, тому що вони незрозуміло де сидять і незрозуміло, дадуть їм відповідь чи ні, і вони самі не впораються. Тому давайте ми зараз ось так зробимо, у середині вставимо якийсь вселенський розум, який їм говоритиме, з ким можна розмовляти, з ким не можна розмовляти, і охороняти їх, якщо їм раптом щось грубе скажуть у відповідь». І із цим багато питань. З одного боку, це потреба, тому що організації не справляються. Ми за останні пару років допомагали кільком організаціям переходити на новий сміливий світ Cloud Native, особливо коли це пов'язано зі зростанням компанії, з масштабуванням, і люди просто губляться. Посередині всього цього знаходиться якась маленька команда так званих DevOps-ів, яким доводиться писати тисячі рядків YAML, щоб якось з усім цим впоратися, і все просто тріщить по швах.
Хмара рідна
Олег: Ти не можеш трохи пояснити, що таке Cloud Native? Тому що це стало якимсь баззвордом, зараз його на кожній стіні пишуть. Як ти це бачиш?
Антон: За великим рахунком, все почалося з того, що з'явився підхід «платформа як сервіс», тобто коли нам знадобилося запускати набагато більше ПЗ і набагато більше веб-сервісів, ніж потрібно було раніше. Ми зрозуміли, що викочувати кожен сервіс окремо як улюблену домашню тварину, яку ми знаємо на ім'я і доглядаємо її все життя, більше неможливо, нам потрібно з ними справлятися як з якимось стадом. Для цього нам потрібна якась однорідна платформа, на яку ми зможемо закидати цей код, а платформа буде досить розумна, щоб його обслуговувати. Автопоїлка, коротше кажучи, автопоїлка-автогодівниця для сервісу.
Піонерами цього підходу були Heroku. Вони сказали, що для того, щоб ці сервіси могли користуватися нашими інфраструктурами, вони теж повинні бути коровами. Тобто у них мають бути певні якості. Так і з'явився 12-факторний додаток, який мав у собі мати якнайменше стійкого стану. Така програма обов'язково збирається якимось конвеєром, у якому перевіряється його сумісність із платформою. Воно має вміти бути resilient (стійким) — знати, що якщо щось пішло не так, то відразу падати не треба. З іншого боку, у певному сенсі покладатися на платформу. Загалом якийсь гібрид такий. Розуміти, що ти не сам собою, що є платформа і треба поважати її обмеження. За великим рахунком, все почалося звідти.
Але чомусь цей підхід «платформа як сервіс» не виправдав себе, і обіцяного буму не сталося. Тобто так, було Heroku, потім за ними відразу всі великі хлопці теж підняли аналоги: Google App Engine, у Amazon - Elastic Beanstalk. Мені чимало довелося працювати з компаніями, які розпочинали з цього. Але в той момент, коли ти робиш щось, що трохи виходить за межі дозволеного платформою, це перетворюється на жахливий головний біль. Тому що починаєш натикатися на стіни, які скрізь. І як людям властиво, коли вони натикаються на стіни, вони починають шукати спосіб прорубати стінку.
Сучасний Cloud Native виріс звідти: як зробити так, щоб бігти все ще у хмарі, користуватися якимись послугами платформи, але при цьому ще й забезпечити приголомшливу гнучкість всього, що відбувається. Ми постійно балансуємо між гнучкістю та простотою. Гнучкість викликає складність, а спрощення та створення точної платформи завжди викликає обмеження. Cloud Native — це, мабуть, знаходження якогось балансу між обмеженнями хмарної платформи та гнучкістю, яку тобі дозволяє хмара з її автоматичним масштабуванням, і все це має ціну.
Олег: Напевно, сама організація має якось навчитися жити процесно з усією цією штукою.
Антон: Звичайно, звичайно! Все це накладає відбиток. Мікросервіси теж до цього належать. За великим рахунком, це уявлення про те, що у нас є невеликі сервіси, невеликі програми, які розкидані по хмарі і можуть знаходитися будь-якої миті де завгодно, і їх може бути зараз 10 реплік, а завтра — 1500, це теж вся частина Cloud Native. Уявлення, що ми не обмежені фізичними межами дата-центру. За великим рахунком, весь світ - моя хмара, це чудове бачення, чудове прагнення, але в нього є ціна, і ціна ця - складність, ціна - те, що за великим рахунком ніхто в голові не може вмістити те, що відбуватиметься, коли наш додаток раптом виросте з 10 інстансів до 1500. Ніхто не може собі уявити таке, і починають виникати всі артефакти масштабування. Ми як люди, як оператори, не можемо нічого з цим зробити, окрім як реагувати на хаос, що відбувається. І ось ми починаємо думати: «А як же нам так побудувати наш додаток і нашу інфраструктуру, щоб коли ці артефакти виникають, по-перше, їх можна було передбачати, а по-друге, якимось чином з цими артефактами впоратися і продовжувати функціонувати?
Поєднання технічних та нетехнічних навичок
Олег: У тебе є доповіді про технічні речі, наприклад, і є доповіді про лідерство, про менеджмент, таке інше. Ти взагалі більша технічна людина, чи ти менеджер, чи в тебе якось по-іншому влаштовано?
Антон: Я навіть почав писати в якийсь момент про це пост, не дописав поки що. Я в певному сенсі розриваюся суто особистісно між цими двома речами, тому що, з одного боку, мені подобається розуміти, як речі працюють, мені подобається з ними розбиратися. Коли вдається вирішити якусь технічну проблему, це просто саме по собі дає приголомшливе відчуття своїх здібностей, те, що називається instant gratification, негайна винагорода, дофамінове вкидання: «Ох, круто, я можу, я вирішив». І від цього важко відмовитись, з цього важко злізти. І оскільки це є, я продовжую займатись технічними речами. Нові технології мене збуджують: круто щось розколупати, щось зрозуміти. Через це виходить, що оскільки є ці знання, люди хочуть їх купувати, і я продовжую їх продавати.
З іншого боку, я розумію, що це просто маленький шматочок великої картини, я досить довго пропрацював в індустрії, і я не можу не бачити, що технологія — це лише куточок великої системи, лише один із компонентів. Я керував командами, і розумію, наскільки важливо враховувати взаємодію технологій та інструментів із тими людьми, які ними користуються. Зрештою, інформаційні технології, власне, будь-які технології, існують для того, щоб ними користувалися люди. І створювати технології, не думаючи про те, хто ними користується, це безглуздо. Технологія сама по собі не цікава взагалі, якщо не думати про її застосування, а застосування завжди пов'язане з людьми, які якимось чином одержують від цього користь. І тому все, що навколо технологій, мене теж дуже цікавить. Я відчуваю, що про це необхідно говорити, я розумію, що без цього все справді втрачає сенс. Такою мірою, що мені іноді кайф посидіти, щось там похакати протягом двох-трьох днів, іноді тижнів. Я можу захопитися якоюсь проблемою, яка в мене не вирішується, я можу вирішити її, отримати від цього приголомшливий прихід. Але потім я піднімаю голову від клавіатури, дивлюся довкола, і я розумію, що навколо відбувається щось, що проігнорувати я жодним чином не можу. І тоді код і колупання в Лінукс мені стають абсолютно нецікавими, неважливими, і хочеться почати вирішувати проблеми на іншому рівні, на людському рівні.
Як швидко розібратися в DevOps
Олег: Слухай, а ти можеш порадити щось людям, які зараз займаються інженерією та вивченням практик DevOps одночасно? Як це все впхнути і в якому порядку? Умовно кажучи, як розпланувати, можливо, свою кар'єру, щоб стати успішнішим у короткий термін?
Антон: Ех… Ну, немає універсальних порад, знову ж таки, за своїм досвідом. Я досить довго, напевно, перші 10 років своєї кар'єри, був незадоволений своїм місцем. Шукав, що мені не подобається, фокусувався на цьому, шукав чим мені було б цікавіше зайнятися. Але за великим рахунком, нічого не робив із цього приводу. Основна порада така… У який момент я вважаю, що моя кар'єра пішла вгору? У той момент, коли я почав розмовляти про речі, які були мені цікаві. Область технічного знання, навіть не лише технічного, взагалі сама по собі сфера інформаційних технологій — дуже широка, тобто можна бути і технарем: розробником, і тестером, і інтегратором, і сісадміном — це різні речі, там кожен може знайти свою нішу. Чи не хочеш бути технарем повністю, тебе цікавить і технічні, і в той же час бізнес-речі? Займайся продактом, проджектом. Ніш повно, знайди свою нішу, яка тобі буде цікава.
Зараз багато йдеться про професіоналів у формі "Т". Потрібно зрозуміти де знаходиться ніжка твого Т, вибрати щось одне, почати копати в цьому місці. У момент копання виявляться чудові глибини. Але копати можна будь-куди. І я чудово усвідомлюю, що є багато районів, які я глибоко не копнув, бо намагався подивитись і зрозумів, що це не моє. А ось там, де тобі цікаво копати — продовжуй копати, і тут дуже важливо говорити про це. Тобто знову ж таки я розумію, що це не для всіх. Але й тут у всіх є різні форми висловлювання: комусь, можливо, підходить писати блоги, не можеш писати блоги літературні та веселі – пиши просто технічні блоги, публікуй Gist'и на GitHub. Ось ти якусь проблему вирішив – публікуй.
За великим рахунком, сьогодні кар'єрний розвиток відбувається за рахунок шерингу. Недаремно в DevOps обмін знаннями це така важлива цінність. Від цього виграють і решта, і ти сам завжди теж виграєш, якщо ділишся своїми знаннями. Будь-яка людина, яка опенсорсила свій код, чудово знає, наскільки потрібно зачесати код, як треба взагалі по-іншому подумати в момент, коли ти даєш це комусь іншому, і ти розумієш, що хтось інший цим користуватиметься. У гру одразу входять ті самі соціотехнічні речі, про які я говорив. Ти починаєш думати, що це не просто код, а код, який інша людина читатиме, можливо, він захоче його змінювати, йому потрібно буде зрозуміти, що цей код робить. І коли виникають ці взаємодії, і ти вже у своєму мозку починаєш взаємодіяти з іншими людьми. А кар'єра людини розвивається лише рахунок взаємодії коїться з іншими людьми. За великим рахунком, що таке кар'єра? Кар'єра це означає, що я стаю корисним більшій кількості людей, корисний і потрібен. Я отримую знання, які потрібні, корисні більшій кількості людей. Для цього треба розуміти, що ці люди хочуть, і що їм потрібно. Якось так. Все завжди втикається у людей.
Олег: Припустимо, ми такі кльові, ми займаємося DevOps'ом, всякими новими практиками, іншим. Але є ті, хто це знають і поважають, а є всі інші. І ось уяви, що ти працюєш у команді в якійсь, особливо у великій компанії, і там це поки що... скажемо акуратно, не дуже знають і не дуже поважають. Чи є якісь методи, як почати впроваджувати всі ці ідеї? Якщо ти не є керівником. Зрозуміло, якщо ти керівник, ти можеш сказати: «Впроваджуємо завтра». А що буде, якщо ти звичайна людина і хочеш поліпшити?
Антон: По-перше, необов'язково, що це працюватиме, якщо ти скажеш як начальник: «Впроваджуємо завтра». Люди виконуватимуть якісь завдання, але це не означає, що глибоке розуміння того, навіщо це впроваджується, виникне звідки не візьмись. І потім будь-які зміни ніхто не любить, особливо коли йому кажуть: «Тобі треба помінятися».
Олег: І що робити?
Антон: Ну, дивися, я був у цьому місці і займався впровадженням таких процесів, фактично, знизу, будучи просто працівником у команді, і потім уже тимлід. Єдиний підхід, який працює, — це підхід наркоторговця. Це те, що я називаю, «співпраця, заснована на усвідомленні того, що ти надаєш послуги», тобто послуго-орієнтована співпраця. За великим рахунком, ти знаєш, що в тебе є якісь люди навколо тебе, яких ти можеш сприймати як своїх клієнтів. Ми щось робимо, хтось інший користується цим. У найпростішому сценарії, про який свого часу говорив Agile: ось я розробник, я маю клієнта, відповідно, я повинен розуміти, чого хоче мій клієнт для того, щоб ефективно розробляти ПЗ.
У великій компанії найчастіше у мене немає безпосередньої взаємодії із замовником, з користувачем. Але довкола мене є люди. Наприклад, я пишу бібліотеку — інші люди з нею інтегруються, я пишу якийсь бекенд — у мене є фронтендники, які мають з ним розмовляти, я пишу код — я маю тестери, які або для мене пишуть тести, або, знову ж таки я видаю версії для того, щоб їм було що протестувати. І за великим рахунком, потрібно просто подумати: «Ось я — постачальник послуги, у мене є клієнти. Найкраще буде працювати, якщо я зроблю так, щоб мої клієнти були задоволені. Тобто якщо мої клієнти будуть задоволені, то я буду задоволений. Я, мабуть, зароблю, по-перше, собі певну репутацію, я зароблю хороше ставлення, я отримаю позитивний фідбек». І повертаючись до підходу драгдилера, я хочу, щоб ці клієнти повернулися до мене, щоб отримати ще те саме.
Тобто якщо я вважаю, що якийсь правильний підхід, наприклад, continuous integration з тестами... Є програмісти, яким сьогодні, наприклад, складно протестувати свою роботу. Потрібно зробити так, щоб їм справді не доводилося про це занадто багато думати, щоб вони отримували ці перевірки якнайпростіше. Сьогодні це виглядає досить банально, 10 років тому це взагалі не було тривіально: у той момент, коли я запушив свій код, щоб все автоматично там десь побудувалося, розгорнулося, і тільки у випадку, якщо є помилка, я отримав би повідомлення, а поки що я міг би спокійно піти пити каву і не думати про те, що мені потрібно зараз запускати компіляцію і на своєму комп'ютері, щоб у мене були всі необхідні тулзи, бо це теж головний біль. Тобто, якщо зменшити кількість головного болю — люди на це підсідають. Ми все це бачимо: у той момент, коли в тебе є пайплайн, що добре працює, дуже швидко всі, хто ним користуються, вже не можуть без нього собі життя уявити. Якщо я хочу щось змінити, потрібно створити процес, від якого у людей виникне певна емоційна залежність.
Олег: Добре. Ось багато людей сподіваються, що прийде якийсь цар, великий лідер, ще щось розповість, як їм жити, і після цього все, звичайно ж, перейдуть у новий сміливий світ з DevOps або ще з чимось. Чи обов'язковий такий цар?
Антон: Ні, цар, який розповість, як жити, точно не обов'язковий. Начальник, який готовий прислухатися до своїх працівників, готовий довіряти їм та готовий підтримувати їх у тому, щоб робити роботу так, як їм здається максимально зручно та правильно? Так, така людина потрібна, бо без цього це буде просто боротьба. А боротьба підлеглих проти свого начальства не закінчується нічим добрим. В результаті для когось одного це точно закінчиться погано, або для начальника, або для підлеглих.
Але проблема полягає в тому, що дуже складно людям говорити, що треба і не треба робити. Вони в результаті роблять те, до чого їх привів їхній культурний бекграунд, его або миттєвий емоційний стан.
Найкорисніші практики та технології зі світу DevOps
Олег: До речі, зараз проповідується величезна кількість різноманітних практик: є підходи від Google, є підходи від Netflix, від будь-яких доповідачів з конференцій. Скажи, які практики вважаєш найбільш корисними?
Антон: Проблема більшості організацій, не важливо, чи великі вони чи маленькі (якраз стартапи від цього страждають сильніше) у тому, що у них немає спостережуваності процесів — розуміння того, як взагалі ми працюємо, як ми доставляємо ПЗ, де речі застряють. Я зазвичай пропоную вправу, що походить з підходу ощадливого управління, lean management – називається value stream mapping. Картування потоку доставленої цінності. Це вимагає певної готовності, зібрати в одній кімнаті основних гравців в організації, всіх людей, які якимось чином беруть участь у процесі доставки: ті, хто визначають необхідні зміни, продакти, проджекти, розробники, тестери, сисадміни, навіть продажники, які працюють з клієнтами. Взяти, зібрати їх усіх разом і зрозуміти, як відбувається зміна програмного забезпечення, який шлях воно проходить зазвичай.
Це здається досить очевидним: ну що там? Хтось вигадав — хтось закодував, у нас є пайплайн, пробігло — викотилося. Ну так, ми знаємо, що тут у нас білд багато часу займає, так, це ми вирішимо. Так, ми знаємо, що програмісти зараз не можуть збирати на своїх комп'ютерах, тому що у них Java, там потрібно дуже багато пам'яті, про це ми теж знаємо, ми вирішимо. І я часто приходжу до організацій, вони кажуть:
— Ось там треба це автоматизувати, це вирішити.
— А ви впевнені, що взагалі починати з цього треба? Звідки ви знаєте?
— Ну, ми точно не знаємо, але ми відчуваємо, що там болить.
є , Яка каже, що за великим рахунком вирішувати питання в будь-якому місці, яке не є обмеженням, - це нічого не вирішувати, це тільки ускладнить проблему. Чого багатьом не вистачає — поняття того, де речі застряють і як вони течуть.
Іноді просто раптом збираєш різних людей, один каже:
- Ось тут ось у цей момент реліз йде на схвалення туди.
А інший каже:
- Ні, у нас не так, у нас не йде. Тут ми чекаємо оточення під тести навантаження.
Або, наприклад, тестери кажуть:
— Ось тут ми зазвичай робимо ось це все руками.
А програмісти їм кажуть:
— То ж у нас є автоматизований процес для цього. Чому ви ним не користуєтесь?
А тестери кажуть:
— А ми не знали, що таке.
Кожна команда бачить тільки свій шматок, і ніхто не бачить всієї картинки в цілому - це те, що часто впливає на нашу здатність ефективно викочувати програмне забезпечення набагато сильніше, ніж наявність або відсутність інструменту. Ось ці речі. Починати варто з картування процесів. Зрозуміло, якщо в компанії немає нині жодного CI/CD — це вже минуле століття. Зрозуміло, що це збудувати теж потрібно. Але варто спочатку відповісти на запитання, скільки вкладати в це, які проблеми це вирішить. Для цього також потрібні люди, які розуміють, як це правильно робити.
Олег: З технічного погляду, на які технології варто звернути увагу? Зрозуміло, що про простий CI/CD можна не говорити. Що з кльових нових технологій варто подивитися?
Антон: По-перше, абсолютно всім очевидно, що контейнери перемогли. І тому якщо хтось ще не робить контейнери, на них обов'язково потрібно подивитися і дивитися якнайшвидше, тому що рух йде в цей бік, вже й великі компанії всі розуміють, що їм потрібно вже загортати своє ПЗ у контейнери. Ну і на рівні платформи переміг Kubernetes: байдуже, у хмарі чи ні — ми будемо клієнтам викочувати коробочку з Kubernetes. Ось тепер і VMware оголосили, що у них буде Kubernetes прямо на гіпервізорі. Зрозуміло, Google переміг. Що загалом ні для кого не стало сюрпризом.
Олег: Google переміг?
Антон: Ну якщо ми озирнемося буквально на пару років тому, там ще було не дуже зрозуміло, Swarm або Kubernetes, і чи вб'ють Docker. Docker вбили, цілком очевидно. Тобто всі разом навалилися, і Microsoft, і Amazon теж допомогли - давайте разом вб'ємо Docker. Вбили Docker! Але за великим рахунком, Docker самі були винні. Вони розраховували, що вони прийдуть, усім зроблять розрив шаблону, нікому не захочуть продаватися і переможуть усіх одразу, завалять одразу і Google, і Microsoft, і Amazon? Дуже мало шансів було, що це станеться. Вони, мабуть, не знайшли, з ким потоваришувати. Коли ти ні з ким не потоваришував, то в результаті тебе завалять. Так і сталося.
Так ось. Тому на контейнери потрібно дивитися. Контейнери та оркестрація — це сьогодні вже потихеньку стає спільним місцем. Тобто вже зараз доповіді на конференціях — це Починати з Kubernetes ніколи не пізно, навіть якщо ви пенсіонер. Тож це потрібно. І навколо Kubernetes зараз починає відбуватися насправді купа всього цікавого. Тому що одна з прикольних фішок Kubernetes — це створення створення якогось універсального API, яке дозволяє нам описувати все, що відбувається в нашій інфраструктурі. Останній рік ми бачимо спроби навколо цього API закрутити купу решти. Ось сервісне сито — одна з таких спроб, майже всі імплементації, сервісного сита, які є зараз, вони в деякому сенсі кажуть: «Ось ми розширимо API, ми додамо розуму, ми опишемо об'єкти поза Kubernetes, але зчитуватимемо об'єкти з Kubernetes і таким чином знати, що робити».
Інший такий приклад — це те, що відбувається зараз із Continuous Delivery Foundation, який організувався десь півтора року тому, знову ж таки, це Google, це CloudBees, GitLab. Є гуглівський проект Tekton, його основна ідея - це створення деякого універсального API для опису continuous delivery-процесу. За великим рахунком, вони намагаються розбити це все на певні об'єкти, які повинні обов'язково бути присутніми в continuous integration / continuous delivery-системі і якимось чином дати можливість записати ці речі в Kubernetes, щоб потім могли бути різні компоненти, які вміють читати ці визначення і вирішувати що з ними робити. З сервісними ситом відбуваються ті ж речі, про це я говорив на своєму . Microsoft зараз намагаються зробити спеку того, що має робити сервісне сито, так званий SMI Spec. З ідеєю того, що будь-яка імплементація сервісного сита вмітиме виконувати все, що в цьому спеку написано плюс щось ще.
Саме тому Kubernetes і виграв. У той момент, коли ти стаєш платформою для подальших інновацій, дуже складно тебе кудись викинути потім, тому що на ньому вже наросло, тепер викинути Kubernetes — це потрібно немовля разом із водою виплескувати.
На які доповіді варто ходити
Олег: На які доповіді ти сам ходиш, що вважаєш цікавим?
Антон: По-перше, якщо є якась нова технологічна фішка, приблуда, яку просто ще не встиг сам подивитися, і є доповідач, який вміє про це зрозуміло розповісти, то я вважаю, що це взагалі дика перевага, тому що замість того, щоб зараз читати, і розкопувати, і, можливо, важко розуміти, ти можеш прийти і за півгодини послухати, як людина тобі покаже, розкаже. Знову ж таки, для цього потрібно певне вміння та бажання вміти розповісти про технологію. І я розумію, що це теж не приходить звідки, над цим треба працювати. У мене це теж зайняло багато часу. До речі, те, що я займаюся технічним викладанням, мені дуже допомогло. Коли перед тобою клас, тобі треба людям щось пояснити, і ти розумієш, що, як ти не пояснюєш, вони туплять — то усвідомлюєш, що, мабуть, проблема в тому, як ти пояснюєш, а не в тому, що люди тупі .
Олег: А що це за технічне викладання? Що ти робиш?
Антон: Я десь років 7-8 займаюся викладанням суто технічних дисциплін. Почалося з того, що я викладав такі речі, як Maven та shell scripting протягом року. Оскільки я дуже щільно займався Jenkins і глибоко його знав, то я викладав людям роботу з Jenkins, адміністрування. В останні роки все, що пов'язане з cloud native: Kubernetes, контейнери і все навколо цього. Скоро їду в Лондон, робитиму майстер-клас з Istio. Це не основна частина моєї діяльності, але десь раз на місяць-два я проводжу майстер-класи.
Олег: Ти йдеш переважно на доповідь, на тему чи на людину?
Антон: Якщо я знаю, що доповідач хороший, то я йду на людину просто тому, що мені ще дуже важливо вчитися в інших людей, як добре розповідати. Вчитися завжди важливо. Якщо є тема, а доповідача я не знаю, то я піду подивитись, але це як завжди, як піти на стендап: глянув перші 10-15 хвилин, не зайшло — пішов. Або є доповідачі, на яких я справді піду по-любому, бо вони завжди цікаво розповідають, навіть речі, які ти знаєш, вміють показати під своїм кутом, це просто і для тебе самого повертає взагалі все питання з нового боку. З тих хто мені подобається останнім часом ... По-перше, є Саймон Вордлі - консультант, у нього є своя така фішка з малюванням карт, він за допомогою карт пояснює, яким чином компанії вибудувати свою стратегію правильно, він був колись якимсь. то там CTO, CEO стартапів, він багато говорить про це, про технологію. Він, до речі, постійно топить за serverless і каже, що ті, хто сьогодні serverless не роблять, мають великі проблеми.
Олег: Це той товариш, у якого ? Він її у вигляді постів зробив. Незвичайний формат.
Антон: Він реально розповідає дуже прикольно. Його лекції за останні 2-3 роки мені запам'яталася найбільше. Ну ось Джон Вілліс, який приїжджав торік на DevOops – просто тому, що він . З ним є деяка проблема, тому що він дуже багато розповідає про американську реальність, речі, які іноді просто не застосовуються ні до російської, ні до ізраїльської реальності. Ось у них є якась війна зараз із якимись change approval boards, про які вони постійно говорять. Це, певне, якась річ, яка існує в американських ентерпрайзах, там є такий процес для проведення та схвалення змін до ІТ, потрібно проходити якісь комітети.
Олег: А в нас такого немає, я навіть не розумію, про що ти зараз.
Антон: Ось я теж не дуже розумію, в Ізраїлі також такого немає. А там вони про це кажуть. Якщо послухати всіх цих товаришів, як DORA, які , Вони теж про це багато пишуть. Загалом, я про те, що люди говорять про якусь проблему, яка є тільки в них, а вона взагалі взагалі не цікава.
Олег: Ти був у минулому DevOops, на які доповіді там варто ходити та переглядати записи?
Антон: дивіться . Трохи тема цікавить – сходити.
Олег: Там є якийсь Антон Вайс, на мою думку. Мабуть, варто подивитися на нього.
Антон: Та ні, на цього не ходіть, скукотища якась 🙂
Олег: Ну гаразд, дякую. Це було круто! Я бачу, що ти вже подав доповідь на наступну конференцію, тож зустрінемося на наступному DevOops!
Конференція пройде 29-30 квітня, цього разу – у Москві. Суть конференції ми описали на Хабрі в анонсі . Програма активно формується (до конференції ще багато місяців), але перших речників вже . Там же можна .
Джерело: habr.com
