🥇„Създаването на технологии, без да се мисли кой ги използва, е напълно безсмислено“: дълго интервю с Антон Вайс

Този хабрапост е интервю с Антон Вайс, съсобственик на технологичното консултиране Otomato Software, с повече от 15 години опит в областта на високите технологии. Той е експерт по техническо обучение, инициатор и съавтор на първия сертификационен курс DevOps в Израел. Антон участва в международни конференции и е известен като готин лектор.

Ще говорим по следните теми:

Разликата между Русия и Израел

Олег: Моля, кажете ни кой сте и какво правите.

Антон: Аз съм Антон, роден в Санкт Петербург, но на 15 години се преместих в Израел и оттогава живея там. През последните двадесет години в Израел се занимавах с ИТ в различните му форми. От тези двадесет години през последните десет съм специализирал във всичко, свързано с доставката на софтуер: интеграция, това, което някога се наричаше управление на конфигурацията, и това, което сега се нарича DevOps. Работил съм в големи компании - в международни предприятия като AT&T, BMC. Работил в стартиращи фирми. През последните четири години имам собствена консултантска компания, наречена Otomato Software, където се занимаваме с подпомагане на организациите да оптимизират процесите на доставка и да овладеят нови инструменти: тоест, ние правим както техническата част, така и всичко около нея.

Олег: Има ли разлика между Русия и Израел по отношение на работата?

Антон: Почти никога не съм работил с руски клиенти. Това, което ме свързва с Русия през последните 3 години, са конференциите. И в няколко руски компании направихме нещо като одит: дойдохме, погледнахме, разбрахме, дадохме препоръки и си тръгнахме. Тоест нямаше такава ежедневна работа, така че ми е трудно да кажа точно как се различава. Мисля, че навсякъде има различни неща. Тоест в Израел, например, имаме толкова тежки корпоративни организации, в които хората работят от 15 години и всичко се движи много трудно. И колкото и да се опитват да направят някаква трансформация, да подобрят процесите: ще говорят и говорят, но... Имаме клиент, с когото преди две години направихме всичко и взехме всички решения, разработихме всички програми и в някакъв този момент всичко спря, ние се измъкнахме от там. Само преди няколко дни се срещнах с шефовете от там, с които работихме, и казах:

- Е, как?

- Ами така. Трудно е, казват те, ние го правим, сега нещо започва да се случва.

Две години по-късно. Има политика, има зони на влияние. Има хора, които не искат да се откажат от тези зони на влияние, следователно, когато възникне такава ситуация, е много трудно да се промени нещо. Е, самите инструменти някак вървят напред. От друга страна, в Израел има стартиращи фирми, в които всичко се променя много бързо, лесно е да създадете нов инструментариум и всички те вече са облачни и са изцяло в облака. Това, между другото, може би е една от осезаемите разлики между Русия и Израел. В Израел публичният облак е много по-лесен. От това, което видях. В Русия, например, изглежда, че е много трудно за всички, с изключение на стартиращите компании, да преминат към публичния облак, но в Израел все още е по-лесно. Днес дори банките и застрахователните компании вече имат някакво разбиране, че поне част от техните вещи могат да бъдат разгърнати в публичния облак. И тук никой не се страхува от договори с Google и Amazon. От това, което чух на конференции в Русия, там все още е по-сложно, добре, дори от гледна точка на санкции или несанкции и някои правни въпроси.

Разликата между стартъпи и гиганти

Олег: Разбирам. Между другото, къде ви е по-интересно и приятно да работите: в стартиращи компании или в големи организации?

Антон: По-приятно е, разбира се, в стартиращите компании, защото големите организации... е, наистина, просто материалът се движи много трудно. Има своите предимства, разбира се. Ако погледнете големите организации, те, например, имат много повече от това, което се нарича разнообразие. Големите компании, просто защото имат нужда от много хора или защото това е някаква организационна култура, която се е развила през годините, са готови да наемат различни хора. Конкретно тук в Израел, например, в стартъпите почти няма да намерите например араби, почти ги няма. В големите организации това е много по-лесно. Но стартиращите фирми израстват от някакъв културен произход, в който по-голямата част от участниците са основно същите тези бели мъже. Там има култура, че трябва да се работи здраво и е препоръчително да се работи по 10-12 часа на ден, а това също не е достатъчно. Сякаш имаме Москва (т.е. Тел Авив) зад гърба си, няма къде да отстъпим и затова трябва да кървим тук и сега.

Олег: Какво ще кажете за разликата в подхода към DevOps в малки и големи компании? Тоест, ако например работите за двама души, не е нужно да настройвате CI/CD за себе си, но копирайте артефакти с помощта на SCP.

Антон: От една страна, да. От друга страна, днес настройването на CI/CD не означава, че наистина извършвате непрекъсната доставка. Но създаването на някакъв тръбопровод за себе си, ако сте компания от двама души, е много, много просто. Ако преди трябваше да се объркате по някакъв начин, днес имате много облачни услуги. Написах YAML и тръгнахме. С това е по-лесно. Всъщност предизвикателството се състои в разрасналите се стартиращи фирми. Тези, които са надхвърлили 20 човека и тук започват да ги боли лющенето, защото няма процеси. Преди всичко някак работеше, но сега започва целият този хаос и не е ясно как можем да поддържаме тази предишна динамика и в същото време да извършваме процесите и да решаваме кой друг ще направи всичко това.

И тогава започват всички неща „ще имаме DevOps екип, който ще отговаря за DevOps“, знаем докъде води това в повечето случаи. Появява се тясно място и постепенно те растат до мястото, където сега са големите компании. В големите компании проблемът е съвсем различен, те вече дори нямат тясно място, а просто портал, толкова мощен, че се отваря веднъж на ден, а през останалото време там се натрупва огромно количество боклук. И така те си мислят: „Как можем сега да направим много малки портали от този портал, които могат да бъдат отворени много по-лесно?“ Тоест, съвсем различни проблеми. Стартъпите имат проблем с факта, че „ние сме засмукани във фуния, как да излезем?“, а големите компании имат проблем - те вече са във фунията, те вече са в подземното царство, сега са мислейки как могат да плуват обратно.

Тенденцията към нарастваща сложност и какво да правим по въпроса

Олег: Е, и плюсът на техническата част: когато имате малко хора, прости технологии, трябва да знаете някои основни Linux, и това е всичко. И при най-малкото мащабиране, трябва да научите някои Kubernetes, а това изглежда като проблем.

Антон: И това несъмнено е проблем. Имахме конференция само преди два дни и беше много забележимо, че почти всеки, който каза нещо там, спомена една дума: „сложност“. Това се превърна в някаква определяща дума в целия дискурс на DevOps днес.

Олег: Така ли беше преди година?

Антон: Опитвайки се да правим всичко бързо, динамично, за да постигнем прословутата гъвкавост, ние сами си създадохме такава сложност. Наистина има много малки тръбопроводи, които поотделно работят чудесно, а след това се опитваме да съберем някаква картина на света от всичко това и точно там внезапно възниква сложността. Защото от всички тези малки тръбопроводи сега изграждаме един процес, така че цялата компания да работи като човешко същество.

Олег: И какъв е отговорът? Как да управлявате тази сложност?

Антон: Е, няма отговори, те се раждат в процеса. Моят доклад беше за едно от тези решения. Като цяло до какво води всичко това? По едно време бях заразен със системно мислене; това се споменава много в DevOps. Стана ми интересно, прочетох книгите на Питър Сенге, Ръсел Акоф, Донела Медоус - хора, които по някакъв начин започнаха системното мислене и като цяло очертаха основните му постулати. Една от основните лещи, през които системното мислене гледа на света, е обратната връзка. С тази сложност сега възникват тези вериги за обратна връзка, тоест сложността става много, много висока, започваме да търсим инструменти, за да контролираме по някакъв начин тази сложност, добре, поне. Не казвам да го намалим - да го поставим под контрол, за да не се разплита.

Появяват се централизирани решения, като цяло дори Kubernetes е нещо такова. Имате централизирана контролна равнина, която в момента, в който го контролирате, ще контролира цялата сложност на тези услуги, които се изпълняват наоколо. Сервизното сито, същата сервизна мрежа, е същият тип решение. Ние казваме: „Имаме много услуги, имаме нужда от тях, за да можем по някакъв начин да говорим помежду си, защото не е ясно къде седят и не е ясно дали ще им отговорят или не, и не могат да се справят самите те. Така че нека направим това сега, в средата ще вмъкнем определен универсален ум, който ще им каже с кого могат да говорят и с кого не, и ще ги защити, ако изведнъж кажат нещо грубо в отговор. И има много въпроси с това. От една страна, това е определена необходимост, защото организациите не могат да се справят. Помогнахме на няколко организации да се преместят в смелия нов свят на Cloud Native през последните няколко години, особено когато става дума, когато компанията расте, мащабира се и хората просто се губят. В средата на всичко това е някакъв малък екип от така наречените DevOps, които трябва да напишат хиляди редове на YAML, за да се справят по някакъв начин с всичко това, и всичко просто се разпада по шевовете.

Cloud Native

Олег: Можете ли да обясните малко какво е Cloud Native? Понеже стана някаква модна дума, сега всеки я пише на всяка стена. Как го виждате?

Антон: Като цяло всичко започна с появата на подхода „платформа като услуга“, тоест когато трябваше да стартираме много повече софтуер и много повече уеб услуги, отколкото беше необходимо преди. Разбрахме, че вече не е възможно да пускаме всяка услуга поотделно, като любим домашен любимец, който познаваме по име и се грижим за него през целия си живот, трябва да се справяме с тях като с вид стадо. За да направим това, имаме нужда от някакъв вид хомогенна платформа, върху която можем да хвърлим този код, и платформата ще бъде достатъчно умна, за да го обслужва. Автоматичната поилка накратко е автоматична поилка-автоматична хранилка за обслужване.

Пионерите на този подход бяха Heroku. Те казаха, че за да могат тези услуги да използват нашите инфраструктури, те също трябва да са крави. Тоест те трябва да притежават определени качества. Така се появи 12-факторното приложение, което трябваше да има възможно най-малко стабилно състояние. Такова приложение задължително се сглобява от някакъв конвейер, който проверява съвместимостта му с платформата. То трябва да може да бъде устойчиво – да знае, че ако нещо се обърка, тогава няма нужда да пада веднага. От друга страна, в известен смисъл разчитайте на платформата. Като цяло, това е един вид хибрид. Разберете, че не сте сами, че има платформа и трябва да уважавате нейните ограничения. Като цяло всичко започна от там.

Но по някаква причина този подход „платформа като услуга“ не се оправда и обещаният бум не се случи. Тоест, да, имаше Heroku, след което веднага след тях всички големи момчета също повдигнаха аналози: Google App Engine, Amazon - Elastic Beanstalk. Трябваше да работя много с компании, които започнаха с това. Но в момента, в който направите нещо, което малко надхвърля това, което платформата позволява, това се превръща в ужасно главоболие. Защото започваш да се блъскаш в стени, които са навсякъде. И както обикновено хората правят, когато попаднат на стени, те започват да търсят начин да пробият стената.

Modern Cloud Native израсна оттам: как да го накарате да работи все още в облака, да използвате някои услуги на платформата, но в същото време да осигурите невероятна гъвкавост във всичко, което се случва. Постоянно балансираме между гъвкавост и простота. Гъвкавостта води до сложност, а опростяването и създаването на ясна платформа винаги води до ограничения. Cloud Native очевидно е за намиране на някакъв баланс между ограниченията на облачната платформа и гъвкавостта, която облакът ви позволява с автоматичното си мащабиране, и всичко това си има цена.

Олег: Вероятно самата организация трябва по някакъв начин да се научи да живее процесно с цялото това нещо.

Антон: Естествено, естествено! Всичко това оставя отпечатък. Микроуслугите също се отнасят за това. Като цяло това е идеята, че имаме малки услуги, малки приложения, които са разпръснати в облака и могат да бъдат разположени навсякъде по всяко време и може да има 10 реплики сега, а утре - 1500, това също е част от роденият в облака. Идеята, че не сме ограничени от физическите граници на центъра за данни. Като цяло целият свят е моят облак, това е абсолютно прекрасна визия, прекрасен стремеж, но си има цена и тази цена е сложността, цената е, че като цяло никой не може да се побере в главата си какво ще се случи, когато нашето приложение внезапно нарасне от 10 екземпляра на 1500. Никой не може да си представи това и всички артефакти на мащабиране започват да се появяват. Ние като хора, като оператори, не можем да направим нищо по въпроса, освен да реагираме на хаоса, който се случва. И така започваме да мислим: „Как можем да изградим нашето приложение и нашата инфраструктура по такъв начин, че когато възникнат тези артефакти, първо, те да могат да бъдат предвидени, и второ, по някакъв начин да можем да се справим с тези артефакти и да продължим да функционираме?“

Смесване на технически и нетехнически умения

Олег: Имате доклади за технически неща, напр. относно сервизното сито и има доклади за лидерство, управление и всичко останало. Като цяло по-скоро технически човек ли сте, или сте мениджър, или структурата ви е по някакъв начин различна?

Антон: В един момент дори започнах да пиша публикация за това, но още не съм я завършила. Лично аз се разкъсвам между тези две неща, защото от една страна обичам да разбирам как работят нещата, обичам да ги разбирам. Когато успеете да разрешите технически проблем, това само по себе си просто ви дава невероятно усещане за вашите способности, това, което се нарича моментално удовлетворение, незабавна награда, прилив на допамин: „О, страхотно, мога да го направя, реших. ” И е трудно да се откажеш, трудно е да се измъкнеш от него. И тъй като това е там, продължавам да правя технически неща. Новите технологии ме вълнуват: готино е да се заровиш в нещо, да разбереш нещо. Поради това се оказва, че след като има това знание, хората искат да го купят, а аз продължавам да го продавам.

От друга страна, разбирам, че това е само малка част от една голяма картина, работил съм в индустрията достатъчно дълго и не мога да не видя, че технологията е само ъгъл на по-голяма система, само един от компонентите . Управлявал съм екипи и разбирам колко е важно да се обмисли как технологиите и инструментите взаимодействат с хората, които ги използват. В крайна сметка информационните технологии, всъщност всяка технология, съществуват, за да могат хората да ги използват. А създаването на технологии без да се мисли кой ги използва е напълно безсмислено. Технологията сама по себе си не е никак интересна, освен ако не мислите за нейното приложение, а приложението винаги е свързано с хора, които по някакъв начин се възползват от него. И затова всичко около технологиите също много ме интересува. Чувствам, че е необходимо да се говори за това, разбирам, че без това всичко наистина губи смисъл. До такава степен, че понякога ми харесва да седя и да хаквам два или три дни, понякога седмици. Мога да се увлека от някакъв проблем, който не мога да разреша, мога да го разреша и да получа невероятни ползи от него. Но тогава вдигам глава от клавиатурата, оглеждам се и разбирам, че нещо се случва наоколо, което по никакъв начин не мога да пренебрегна. И тогава програмирането и ръчкането с Linux стават напълно безинтересни и маловажни за мен и искам да започна да решавам проблеми на различно ниво, на човешко ниво.

Как бързо да разберете DevOps

Олег: Слушайте, имате ли съвет за хора, които в момента се занимават с инженеринг и едновременно с това изучават DevOps практики? Как да го натъпчете всичко в себе си и в какъв ред? Относително казано, как можете да планирате кариерата си, за да станете по-успешни за кратко време?

Антон: Ех... Е, няма универсален съвет, пак от собствен опит. Доста дълго време, вероятно първите 10 години от кариерата си, бях недоволен от мястото си. Търсих това, което не харесвам, фокусирах се върху него, търсех какво би ми било по-интересно да правя. Но като цяло той не направи нищо по въпроса. Основният съвет е... В кой момент смятам, че кариерата ми е тръгнала нагоре? В момента, в който започнах да говоря за неща, които ме интересуват. Областта на техническите познания, дори не само техническите познания, като цяло самата област на информационните технологии е много широка, тоест можете да бъдете техник: разработчик, тестер, интегратор и системен администратор - това са всички различни неща, всеки може да намери своята ниша там. Не искате да сте пълен технолог, интересувате ли се както от технически, така и от бизнес неща? Включете се в работа по продукти и проекти. Има много ниши, намерете вашата ниша, която ще ви бъде интересна.

Напоследък много се говори за професионалисти с Т-образна форма. Трябва да разберете къде е кракът на вашето Т, да изберете едно нещо и да започнете да копаете на това място. В момента, в който копаете, ще се разкрият невероятни дълбочини. Но можете да копаете навсякъде. И добре осъзнавам, че има много области, в които не съм се задълбочил, защото се опитах да погледна и разбрах, че това не е за мен. Но там, където ви е интересно да копаете, продължавайте да копаете и тук е много важно да говорите за това. Искам да кажа, разбирам отново, че това не е за всеки. Но дори и тук всеки има различни форми на изразяване: за някои може да е подходящо да пишат блогове, но ако не можете да пишете литературни и забавни блогове, просто пишете технически блогове, публикувайте Gists в GitHub. Ако сте решили проблем, публикувайте го.

Като цяло днес кариерното развитие става чрез споделяне. Има причина споделянето на знания да е толкова важна ценност в DevOps. Всички останали печелят от това, а вие самият винаги печелите, ако споделяте знанията си. Всеки, който е отворил кода си, знае много добре колко трябва да разчесвате кода, как трябва да мислите различно в момента, в който го давате на някой друг и разбирате, че някой друг ще го използва. Същите социотехнически неща, за които говорих, веднага влизат в действие. Започвате да си мислите, че това не е просто код, а код, който друг човек ще прочете, може би ще иска да го промени, ще трябва да разбере какво прави този код. И когато възникнат тези взаимодействия, вие вече започвате да взаимодействате с други хора в мозъка си. И кариерата на човек се развива само чрез взаимодействие с други хора. Като цяло какво е кариера? Кариера означава да стана полезен на повече хора, полезен и необходим. Получавам знания, които са необходими и полезни на повече хора. За да направите това, трябва да разберете какво искат тези хора и от какво имат нужда. Нещо като това. Винаги всичко се свежда до хората.

Олег: Да кажем, че сме толкова готини, че правим DevOps, всякакви нови практики и т.н. Но има хора, които знаят и уважават това, а има и всички останали. И представете си, че работите в екип в някаква, особено в голяма компания, и там все... нека внимаваме, те не са много известни и не много уважавани. Има ли начини да започнете да прилагате всички тези идеи? Ако не си лидер. Ясно е, че ако сте мениджър, можете просто да кажете: „Ще го приложим утре“. Какво се случва, ако сте обикновен човек и искате да се подобрите?

Антон: Първо, не е задължително да работи, ако кажете като шеф: „Ще го приложим утре“. Хората ще изпълняват някои задачи, но това не означава, че дълбоко разбиране защо се изпълнява ще се появи от нищото. И тогава никой не обича промените, особено когато му кажат: „Трябва да се промениш“.

Олег: И какво да правя?

Антон: Е, вижте, аз бях на това място и участвах в изпълнението на такива процеси, всъщност отдолу, като просто работех в екип, а след това вече бях ръководител на екип. Единственият подход, който работи, е подходът на наркодилъра. Това е, което аз наричам „сътрудничество, базирано на услуги“, тоест сътрудничество, ориентирано към услугите. Като цяло знаете, че около вас има хора, които можете да възприемате като свои клиенти. Ние правим нещо, някой друг го използва. В най-простия сценарий, за който Agile веднъж говори: тук съм разработчик, имам клиент и съответно трябва да разбера какво иска моят клиент, за да разработя ефективно софтуер.

В голяма компания често нямам пряко взаимодействие с клиента, с потребителя. Но около мен има хора. Например, аз пиша библиотека - други хора се интегрират с нея, аз пиша някакъв вид бекенд - имам предни разработчици, които трябва да говорят с нея, аз пиша код - имам тестери, които или пишат тестове за мен, или, пак им давам версии, за да има какво да тестват. И като цяло, просто трябва да си помислите: „Ето аз съм доставчик на услуги, имам клиенти. Всичко ще работи най-добре, ако направя клиентите си доволни. Тоест, ако моите клиенти са доволни, и аз ще бъда щастлив. Очевидно ще спечеля, първо, определена репутация за себе си, ще спечеля добро отношение, ще получа положителна обратна връзка. И връщайки се към подхода на наркодилъра, искам тези клиенти да се връщат при мен за още от същото.

Тоест, ако смятам, че някакъв подход е правилен, например непрекъсната интеграция с тестове... Има програмисти, които днес например им е трудно да тестват работата си. Трябва да сме сигурни, че те наистина не трябва да мислят за това твърде много, така че да получават тези чекове възможно най-лесно. Днес изглежда доста тривиално, преди 10 години изобщо не беше тривиално: в момента, в който натиснах кода си, така че всичко автоматично да се изгради някъде, да се внедри и само ако има грешка, ще получа съобщение, междувременно мога спокойно да отида да пия кафе и да не мисля за факта, че сега трябва да стартирам компилацията на компютъра си, за да имам всички необходими инструменти, защото това също е главоболие. Тоест, ако намалите количеството главоболия, хората се пристрастяват към него. Всички го виждаме: в момента, в който имате добре функциониращ тръбопровод, много бързо всеки, който го използва, вече не може да си представи живота без него. Ако искам да променя нещо, трябва да създам процес, от който хората да имат определена емоционална зависимост.

Олег: Глоба. Много хора се надяват, че някой крал, велик лидер или нещо друго ще дойде и ще им каже как да живеят, и след това всички, разбира се, ще се преместят в смел нов свят с DevOps или нещо друго. Нужен ли е такъв цар?

Антон: Не, цар, който ще ви казва как да живеете, определено не е необходим. Шеф, който е готов да изслушва служителите си, желаещ да им се довери и готов да ги подкрепя да вършат работата по начина, по който се чувстват най-удобни и подходящи за тях? Да, такъв човек е необходим, защото без него ще бъде само борба. И борбата на подчинените срещу техните началници не завършва с нищо добро. В резултат на това определено ще свърши зле за един човек, било то за шефа или за подчинените.

Но проблемът е, че е много трудно да се каже на хората какво да правят и какво да не правят. В крайна сметка те правят това, към което ги кара техният културен произход, его или моментно емоционално състояние.

Най-полезните практики и технологии от света на DevOps

Олег: Между другото, сега се проповядват огромен брой всякакви практики: има подходи от Google, има подходи от Netflix, от всякакви лектори от конференции. Кажете ми кои практики намирате за най-полезни?

Антон: Проблемът с повечето организации, без значение колко големи или малки (стартъпите страдат повече от това), е, че те нямат видимост на процесите – разбиране за това как работим като цяло, как доставяме софтуер, къде нещата се забиват. Обикновено предлагам упражнение, което идва от подхода на щадящо управление - наречено картографиране на потока от стойност. Картографиране на потока на доставената стойност. Това изисква известно желание да се съберат в една стая основните играчи в организацията, всички хора, които по някакъв начин участват в процеса на доставка: тези, които определят необходимите промени, продукти, проекти, разработчици, тестери, системни администратори, дори хора по продажбите които работят с клиенти. Вземете ги всички заедно и разберете как се случва промяната в софтуера, какъв път обикновено изминава.

Това изглежда доста тривиално: какво има? Някой го е измислил, някой го е кодирал, имаме тръбопровод, той се пусна и пусна. Е, да, знаем, че изграждането ни тук отнема много време, да, ще решим това. Е, да, знаем, че сега програмистите не могат да компилират на компютрите си, защото имат Java, изисква много памет, знаем и за това, ще решим. И често идвам в организации, те казват:

— Това е мястото, където трябва да автоматизираме това, да разрешим това.
— Сигурен ли си, че това е, с което трябва да започнеш? От къде знаеш това?
- Е, не знаем със сигурност, но чувстваме, че боли там.

Има Теория на ограниченията на Голдрат, което казва, че като цяло решаването на проблема на всяко място, което не е ограничение, не решава нищо, то само ще усложни проблема. Това, което липсва на мнозина, е концепцията за това къде нещата се забиват и как протичат.

Понякога просто изведнъж се събират различни хора, един казва:
— Ето в този момент изданието отива там за одобрение.

А другият казва:
- Не, при нас не е така, не ни върви. Тук чакаме средата за тестове за натоварване.

Или, например, тестерите казват:
- Тук, на това място, обикновено правим всичко с ръцете си.

И програмистите им казват:
- Е, имаме автоматизиран процес за това. Защо не го използваш?

И тестерите казват:
- Не знаехме какво е.

Всеки екип вижда само своята собствена част и никой не вижда цялата картина - това е, което често влияе върху способността ни да пускаме ефективно софтуер много повече от наличието или отсъствието на инструмент. Това са нещата. Струва си да започнете с картографиране на процеса. Ясно е, че ако една компания в момента няма CI/CD, това вече е нещо от миналото. Ясно е, че и това трябва да се изгради. Но си струва първо да отговорите на въпроса колко да инвестирате в него, какви проблеми ще реши. Това също изисква хора, които разбират как да го направят правилно.

Олег: От техническа гледна точка на кои технологии си струва да се обърне внимание? Ясно е, че вече не може да се говори за обикновен CI/CD. Какви страхотни нови технологии си струва да разгледате?

Антон: Първо, за всички е абсолютно очевидно, че контейнерите спечелиха. И следователно, ако някой все още не прави контейнери, определено трябва да ги разгледате и да ги разгледате възможно най-скоро, защото движението върви в тази посока и големите компании вече разбират, че трябва да опаковат своя софтуер в контейнери . Е, на ниво платформа Kubernetes спечели: няма значение дали е в облака или не - ние ще пуснем кутия с Kubernetes на клиентите. Сега VMware обяви, че ще има Kubernetes директно на хипервайзора. Всичко е ясно, Google спечели. Което, общо взето, не изненада никого.

Олег: Google спечели?

Антон: Е, ако погледнем назад само преди няколко години, все още не беше много ясно дали Swarm или Kubernetes ще бъдат убити и дали Docker ще бъде убит. Докер е убит, съвсем очевидно. Тоест, всички се нахвърлиха заедно и Microsoft и Amazon също помогнаха - „нека всички заедно да убием Docker“. Убит Докър! Но като цяло самите Docker бяха виновни. Очакваха ли, че ще дойдат, ще разчупят калъпа за всички, няма да искат да продават на никого и ще победят всички наведнъж и веднага ще победят Google, Microsoft и Amazon? Имаше много малък шанс това да се случи. Явно не можаха да намерят с кого да се сприятеляват. Когато не се сприятеляваш с никого, в крайна сметка те зарязват. Така и стана.

И така, ето го. Следователно, трябва да погледнете контейнерите. Контейнерите и оркестрацията бавно стават нещо обичайно днес. Тоест сега докладите на конференциите са „Никога не е късно да започнете с Kubernetes, дори и да сте пенсионер“. Така че е необходимо. И сега около Kubernetes започват да се случват много интересни неща. Тъй като една от страхотните функции на Kubernetes като цяло е създаването на някакъв универсален API, който ни позволява да описваме всичко, което се случва в нашата инфраструктура. През изминалата година видяхме опити да се обвият куп други неща около този API. Ето сервизното сито - един от тези опити, почти всички реализации на сервизното сито, които съществуват сега, те в известен смисъл казват: „Тук ще разширим API, ще добавим интелект, ще опишем обекти извън Kubernetes, но ще четем обекти от Kubernetes и така нататък."

Друг такъв пример е това, което се случва сега с Continuous Delivery Foundation, която беше организирана преди около година и половина, отново това е Google, това е CloudBees, GitLab. Има проект на Google Tekton, чиято основна идея е създаването на един вид универсален API, който да описва непрекъснатия процес на доставка. Като цяло те се опитват да разделят всичко на определени обекти, които трябва да присъстват в системата за непрекъсната интеграция / непрекъсната доставка и по някакъв начин да направят възможно записването на тези неща в Kubernetes, така че по-късно да има всякакви различни компоненти, които могат да четат тези дефиниции и да решават какво да правят с тях. Същите неща се случват и със сервизните сита, говорих за това в моя доклад. Сега Microsoft се опитва да направи спецификация за това какво трябва да прави сервизното сито, така наречената SMI Spec. С идеята, че всяка реализация на сервизното сито ще може да изпълни всичко, което е написано в тази спецификация плюс още нещо.

Ето защо Kubernetes спечели. В момента, когато се превърнете в платформа за по-нататъшни иновации, е много трудно да ви изхвърлим някъде по-късно, защото вече е израснал върху нея, сега да изхвърлите Kubernetes е да изхвърлите бебето с водата за баня.

На кои доклади си струва да присъствате?

Олег: Какви доклади ходите пред себе си, какво намирате за интересно?

Антон: Първо, ако има някаква нова технологична функция, джаджа, която просто не съм имал време да видя, и има говорител, който може да говори ясно за това, тогава мисля, че това като цяло е огромно предимство, защото вместо сега четете и ровете и може би ще ви е трудно да разберете, можете да дойдете и да слушате след половин час, както човек ви показва и ви казва. Отново, това изисква определено умение и желание, за да можете да говорите за технологии. И разбирам, че това също не идва от нищото, трябва да работите върху него. И на мен ми отне доста време. Между другото, фактът, че се занимавам с техническо обучение, ми помогна много за това. Когато имаш клас пред себе си, трябва да обясниш нещо на хората и осъзнаваш, че както и да обясняваш, те са глупави - тогава осъзнаваш, че явно проблемът е в това как обясняваш, а не в фактът, че хората са глупави.

Олег: Какъв вид техническо обучение? Какво правиш?

Антон: От около 7-8 години преподавам чисто технически дисциплини. Започна с преподаването на неща като Maven и shell скриптове в продължение на една година. Тъй като работих много тясно с Дженкинс и го познавах дълбоко, научих хората как да работят с Дженкинс и администрацията. През последните години – всичко свързано с облачен натив: Kubernetes, контейнери и всичко около него. Скоро заминавам за Лондон, за да направя майсторски клас за Istio. Това не е основната част от моята дейност, но около веднъж на месец или два провеждам майсторски класове.

Олег: Основно към репортажа, към темата или към човека?

Антон: Ако знам, че говорещият е добър, тогава отивам при човека, просто защото все още е много важно за мен да се науча от другите хора как да говоря добре. Ученето винаги е важно. Ако има тема, но не познавам говорещия, тогава ще отида и ще го гледам, но е както обикновено, като да отидете на стендъп: Гледах първите 10-15 минути, нали не ми хареса и си тръгна. Или има лектори, при които наистина ще отида, защото те винаги казват интересни неща, дори знаят как да покажат неща, които знаете от техния ъгъл, просто е и за вас обръща целия въпрос от нов ъгъл . От тези, които харесвам напоследък... Първо, има Саймън Уордли - консултант, той има свой собствен трик с рисуването на карти, използва карти, за да обясни как компаниите могат да изградят правилно стратегията си, той някога беше някакъв вид... след това има технически директор, главен изпълнителен директор на стартиращи компании, той говори много за това, за технологиите. Между другото, той непрекъснато защитава без сървъри и казва, че тези, които днес не го правят, имат големи проблеми.

Олег: Това е другарят, който книга на Medium? Той го направи под формата на постове. Необичаен формат.

Антон: Той наистина говори по много забавен начин. Най-много си спомням лекциите му през последните 2-3 години. Е, ето го Джон Уилис, който дойде в DevOops миналата година - просто защото той наистина знае как да каже. Има някакъв проблем с него, защото той говори много за американската реалност, неща, които понякога просто не се отнасят нито за руската, нито за израелската действителност. Сега имат някаква война с някакви бордове за одобрение на промени, за които постоянно говорят. Това, очевидно, е нещо, което съществува в американските предприятия; има процес за извършване и одобряване на промени в ИТ; трябва да преминете през някои комисии.

Олег: Но ние нямаме това - дори не разбирам за какво говорите сега.

Антон: И аз наистина не разбирам; това също не се случва в Израел. И там говорят за това. Ако слушате всички тези другари, като ДОРА, които направете доклад за състоянието на DevOps, те също пишат много за това. Като цяло имам предвид, че хората говорят за някакъв проблем, който имат само те и това изобщо не ви е интересно.

Олег: Бяхте на предишния DevOops, на какви разговори си струва да отидете и да прегледате записите?

Антон: виждам всички. Малко ме интересува темата - давай.

Олег: Мисля, че там има някакъв Антон Вайс. Сигурно си струва да се види.

Антон: Не, не се захващайте с това, малко е скучно :)

Олег: Добре, благодаря ви много. Беше готино! Виждам, че вече сте изпратили доклад на следващата конференция, така че ще се видим на следващия DevOops!

конференция DevOops 2020 Москва ще се проведе на 29-30 април, този път в Москва. Същността на конференцията на Хабре описахме в анонса „Няма инженери на DevOps“. Програмата се формира активно (има още много месеци до конференцията), но първите лектори вече са може да се види на сайта. Там можете закупуване на билети.

Източник: www.habr.com