Это транскрипция эпизода видео подкаста. Посмотрите на YouTube, послушайте его в приложении подкаста.
В первом в истории эпизоде подкаста Devops Speakeasy мы взяли интервью Антон Вейс на консультации DevOps. Эти подкасты JFROG разработаны специально для предоставления новейших и лучших в практике DevOps, разговаривая с экспертами отрасли, которые делятся своим технологическим опытом и дают представление о упрощении деятельности вашей организации.
Барух: Добро пожаловать в первый эпизод нашего подкаста Devops Speakeasy. У нас есть удивительный гость Антон Вайс, международный рок -звезд Devops и докладчик на многих конференциях, включая нашу собственную Yalla Devops. Мы собираемся добраться до Антона очень скоро. Несколько слов о формате Speakeasy и подкаста. Devops Dockeasy родился полгодом назад, как набор интервью, которые мы делаем с докладчиками и знаменитостями в мире Devops. Обычно интервью записаны в прямом эфире на конференциях, где мы просто захватываем людей на шоу или находим конференц-зал и просто интервьюируют у них очень короткие (8-10 минут) по одной теме.
Несмотря на то, что никто больше не собирается провести конференции, мы все еще хотим поговорить с потрясающими людьми, поэтому мы решили превратить этот формат в подкаст, потому что, как вы знаете, все являются подкастом, и никто не подходит, включая нас. Это означает не лицо к лицу, а в наших виртуальных студиях с более длинным форматом. Мы стремимся к часовому эпизоду, поэтому у нас есть достаточно времени, чтобы обсудить все виды вещей и заняться всевозможными темами, и мы посмотрим, как это происходит.
У нас, вероятно, будет наша доля из пяти подписчиков, включая маму Антона и еще пару других, но мы надеемся, что это будет интересно для вас. Это наверняка будет интересным для нас. Сегодня у нас есть удивительный Кэт Косгроув Защитник разработчика в JFROG здесь с нами. И я, я Барух Садогурский , Глава DevOps Advocacy в JFROG. И, как я упомянул Антон Вайс. Итак, давайте доберемся до этого. Кто ты, Антон?
Антон: Вау, это философский вопрос. Ну, кто я? Я человек. В течение последних 30 лет я живу в Израиле, и до этого я родился и вырос в России. За последние 20 лет, и это то, что актуально для темы этого подкаста, я имел дело с информационными технологиями. Я начинал как разработчик, пишущий код в C и C ++. Затем перешел к ряду различных интеграций, как бы они ни называли позициями. Со временем то, что я делал, начали называться управлением конфигурацией.
А потом в определенный момент Патрик Дебуа изобрел новое замечательное слово «DevOps». С тех пор это то, что я все. В течение последних четырех лет я делал это для себя, на самом деле делая это для своих клиентов, для моих клиентов. Итак, я являюсь главой и основателем бутик -консалтинговой компании под названием Программное обеспечение Отомато где мы делаем, мы помогаем нашим клиентам, крупным предприятиям и небольшим стартапам, чтобы облегчить DevOps. Так что DevOps Speakeasy упрощает DevOps.
Барух: В яблочко. И спитзии по этому поводу. С DevOps Consulting я попытался обнять его голову. Как это выглядит? О чем это? Итак, как это работает? Вы приходите в компанию, а потом сделаете что? Вы приводите с собой инженеров Devops?
Антон: Это первое, что я делаю. Я прихожу к ним и говорю: «У вас не должно быть инженеров DevOps». А потом я беру пару 1000 баксов, и у меня нет двери. Так что в основном это консалтинг DevOps.
Кат: Так здорово, ты нанимаешь?
Антон: Ну, это трудно продать. Не ошибайтесь. Я никогда не называл эту консалтингу DevOps, хотя слово DevOps вокруг меня, и я произношу его много раз в день. Но все же то, что я делаю, что мне нравится сказать, что я делаю, это оптимизация доставки программного обеспечения.
Организации создают программное обеспечение. Они хотят сделать это программное обеспечение пригодным для их пользователей, поэтому нам нужно доставить программное обеспечение, и у них есть некоторые трудности на пути. Вот где я вижу наш опыт. Чтобы понять, где находятся препятствия, где находятся узкие места, проанализировать весь процесс и помочь найти способы сделать эту вещь проще, быстрее, веселее.
Это включает, конечно, все компоненты; Процессы, инструменты, люди и информация. Мы всегда говорим о людях, процессе, инструментах. Мы недостаточно говорим о потоке информации вокруг этой вещи, потому что это также не менее важно. Иногда еще более важно, потому что информация — это то, что протекает через трубопровод.
Барух: Но это очень широкое. Я имею в виду оптимизация доставки программного обеспечения — это все. Начиная с поднятия правильного языка программирования и наличия хороших разработчиков, и использования правильных шаблонов дизайна, это то, что мы почти никогда не связываем с DevOps. Я думаю, говоря: «Я здесь, чтобы оптимизировать вашу доставку программного обеспечения, говоря, что я здесь, чтобы сделать вашу жизнь лучше. Ваш кофейный бренд неверен. «Это все. Но люди хотят ощутимых целей, потому что они хотят ощутимых результатов, и они хотят привлечь вас к ответственности. Так как же вы это делаете?
Антон: Как правило, консалтинг — сложный бизнес. Так что да, вы предполагаете, что ваши клиенты хотят ощутимых результатов. Они не всегда делают, потому что у них есть свой консультационный бюджет, и они несут ответственность за эти бюджеты. И если вы не даете результатов, то они подотчетны своим менеджерам. Так иногда, Да. Они ожидают результатов, но они не хотят измерять это, потому что, если по какой -то причине у вас нет результатов и результатов, которые получает консультант, не всегда зависит от консультанта, его или самого.
Поскольку консультант может только рекомендовать, консультант может тренировать, консультант может наставлять, но в конце концов, реализация рекомендаций консультанта со стороны клиента.
Барух: Это никогда не полетит с нашим боссом, что я могу вам сказать прямо сейчас. Вам нужно найти очень конкретных людей, которые не заботятся о результатах или несут вас ответственность.
Антон: Ну, я пытаюсь сказать, что многие люди говорят, что хотят видеть осязаемые результаты. Но когда тема Мой разговор в Yalla Devops И многие другие разговоры, которые я сделал за последние пару лет, было о том, как мы можем измерить результаты DevOps. Как мы измеряем возврат инвестиций от DevOps? И то, что я вижу раз за разом, в это очень мало организаций, которые действительно вкладывают усилия. Поэтому, когда мы делаем DevOps, мы действительно хотим достичь двух вещей: мы хотим быстрее доставлять программное обеспечение и с более качественным качеством. Вы бы пошли быстрее, но все всегда сломано, что мы ничего не делали. И если мы достигаем хорошего качества, но мы не можем идти в ногу с рыночным спросом, опять же, DevOps не работает. Таким образом, мы должны измерять как по скорости, так и по качеству, или как они также называются «скоростью» и «стабильностью». Как они называют это в Ускорить книгу ?
Барух: Время заказа, частота развертывания, частота отказов и среднее время для восстановления.
Антон: Верно. Хорошо. Так что есть четыре очень простые меры. Сколько организаций на самом деле измеряют это?
Барух: Ну, те, к чему Николь Форсгрен Приходит и задавайте эти вопросы, тогда я думаю, что они начинают заботиться об этом.
Антон: Вероятно. Я предполагаю еще раз, что такое Состояние DevOps Report основано на? Это основано на самоотчетных опросах, верно? Итак, вопрос в том, основаны ли они на данных? Я предполагаю, что большинство людей, предоставляющих ответы на сервер, говорят: «Ну, это более или менее. » У них нет ни копейки, потому что сбор этих данных является инвестицией.
И мы не видим организаций, действительно, действительно инвестируют в это, потому что мы очень, очень заняты, исправляем развертывание. Или мы очень заняты заменой нашей текущей инфраструктуры на Kubernetes, или мы очень заняты наймом инженеров DevOps, потому что их так трудно найти. Потому что они не существуют. Очень сложно найти то, чего не существует.
Кат: Я знаю, что у нас есть целое телешоу о поиске чего -то, чего не существует. Есть семь сезонного шоу о поиске снежного человека. Еще не нашел его. Семь сезонов, хотя.
Барух: Ага. Истина где-то там. Это еще одно очень длительное телешоу о поиске вещей, которые могут существовать. Итак, знаете что? Я беспокоюсь сейчас, потому что вы говорите, что все дым и зеркала. Фактических измерений нет, фактических результатов нет.
Вы приходите к людям, и извините меня, ерут их, и они покупают вашу чушь, а потом никто ничего не измеряет. И я рад за тебя. Вы получаете свои деньги, все счастливы. А если серьезно, я лично думал, что это серьезная инженерная дисциплина, что мы серьезные люди, которые занимаются данными, с цифрами, спорят с данными, измеряют вещи и имеют ощутимые результаты. Я слышал, что ничто из этого не является правдой. Ты меня волновал. Теперь вам нужно успокоить меня. Серьезно, давайте поговорим об этом. Вы говорите, что никто ничего не измеряет, и никто не знает, что они делают, и улучшение — это ощущение, что нам самим лучше.
Антон: Теперь это была на самом деле первая часть шоу, когда я все разозлил меня.
Нет, я не говорю, что никто ничего не измеряет. Я говорю, что я вижу, что, опять же, я предвзято, потому что, когда меня вызывают, меня обычно называют, где организации испытывают боль. Потому что, если вам не больно, вы обычно не звоните консультанту. Пока вирус не разбивается, вы не говорите: «Хорошо, мы можем справиться с этим сами».
Кэт: Ага. Раньше я работал в индустрии резервного копирования данных, и это то, что мы тоже там видели, что никто не заботился о том, чтобы иметь резервные копии. Компаниям было все равно, пока они не попали в криптолокерский вирус, и они просто полностью облажались. И там есть какое -то совпадение с DevOps, когда у нас есть DevSecops как вещь. Беспокойство о безопасности с самого начала.
Барух: Хорошо, я тебя слышу. Так что люди приходят к вам, когда думают, что им больно, и вы продаете им этот дым и зеркала, что у вас все будет в порядке.
Антон: Нет, это не то, что я продаю. Я говорю, что я даю измеримые результаты. Вот что вам нужно иметь, чтобы измерить это, и вот что мы собираемся сделать. Процесс оценки, который мы проводили в течение последних трех, четыре года с разными организациями.
Поэтому мы садимся со всеми игроками этой игры доставки. Разработчики, операции, тестеры, менеджеры проектов, менеджеры по продуктам, кто бы ни был в этой игре, кто бы ни предложил требованиям, кто бы ни использовал требования, кто бы ни строил инфраструктуру и так далее и так далее.
И даже из самого основного отображения вы можете понять, что есть определенные узкие места. Есть низкие висящие фрукты, которые все знают, есть. И много раз, когда я прихожу в организацию, они уже знают, где боль. Несмотря на то, что иногда, когда мы садимся и поговорим со всеми, мы узнаем, что это не настоящая боль.
Они говорят: «Наша сборка занимает три часа», но потом вы садитесь с ними, и вы понимаете, что им требуется неделя, чтобы утвердить версию Таким образом, вы говорите, может быть, трехчасовая сборка не является вашим самым большим узким местом, поэтому после оценки мы более или менее знаем, что мы собираемся делать.
Я не могу обещать, насколько лучше организация станет, потому что это процесс постоянного улучшения. Но первое, что я говорю, это то, что нам нужно начать измерять это. И они говорят: «Это очень трудно измерить. Как мы узнаем, когда наше время заканчивается, потому что у нас есть коммиты в начале релиза? «Мы все еще не делаем непрерывную доставку! Кстати, большая часть организации не делает непрерывную доставку. Итак, они говорят: «Мы еще не делаем непрерывную доставку, так как же нам подсчитать время выполнения заказа? Это с того момента, как коммит был подтолкнут до тех пор, пока не будет выпущено релиз? Или до тех пор, пока мы не вытащим это в стационарную среду? Или до того времени, что угодно, была найдена ошибка? «
Поэтому нам нужно определить эти вещи. Это нормально, если каждая организация определяет их по -разному, потому что важно то, что вы начинаете измерять. Вы определяете начальную точку и конечную точку. А потом вы можете сказать: «Хорошо, все это». И если все это не становится быстрее, вероятно, я не оптимизирую в нужную точку. Затем вы начинаете искать фактические узкие места, потому что как Теория ограничений Учит нас, оптимизируя где -нибудь, но не на узком месте, вообще ничего не оптимизирует. Так что это был бы правильный подход.
Так работает в идеальном мире. Это требует большой дисциплины, это не требует паники, и это требует, чтобы вы не испытывали слишком большой боли. Но я сказал, что большинство компаний, с которыми я начинаю работать, уже испытывают боль. Так что, прежде всего, им нужно лекарство от боли. Поэтому они сказали бы: «Наше производство все время рухнет. У нас есть критические оповещения пять раз в неделю. » Итак, мы говорим: «Мне все равно, как долго ваше время выполнения. Первое, что вам нужно сделать, это взять аспирин. «Давайте просто разберемся с вашими оповещениями. Давайте сосредоточим все внимание на ваших производственных оповещениях, давайте разбудим всех, когда происходит предупреждение, и давайте убедимся, что мы уменьшаем эти оповещения.
В одной компании, с которой мы работали, мы создали что -то, что мы называем боли. У них была очень нестабильная обстановка, и все всегда рухнуло. Вещи рухнули из -за тех же проблем, которые никогда не были исправлены, потому что у них не было внимания, чтобы исправить это. Таким образом, мы начали помещать их на доску на большой монитор для всех, чтобы увидеть. И мы начали ежедневные встречи, где мы смотрели на доску и говорили: «Эта проблема возвращается в течение 50 раз. Поэтому мы должны позаботиться об этом первым, потому что мы больше не хотим, чтобы он возвращался. «Когда вы работаете таким образом, медленно, но верно, вы начинаете уменьшать количество проблем. Вы начинаете уменьшать шум Вы начинаете уменьшать боль, и тогда вы можете начать сосредоточиться на фактической проблеме доставки.
Барух: Хорошо. Таким образом, первый этап — это своего рода режим пожаротушения, когда вы просто решаете очевидные проблемы, которые очевидны для всех. Нет необходимости делать какой -либо сложный анализ, а что нет. Каждое развертывание, которое мы делаем, терпит неудачу, так что давайте исправим это.
Вернемся к узким местам, мне интересно, можете ли вы назвать одно самое большое узкое место, которое вы видите в большинстве своих клиентов или организаций, с которыми вы разговариваете. Или, может быть, не одна, может быть, пара, но самые большие боли, которые вы видите.
Антон: Ну, это довольно легко. Был этот разговор, который я должен был выступить в Devoops , тема разговора была Путешествие героя Devops Анкет Итак, я совершал путешествие героя по Джозеф Кэмпбелл Анкет Он изучал мифы о разных странах и разных людях. Такие вещи, как история о мифе о Будде, миф об Иисусе, миф о Мухаммеде, что угодно. Он говорил все эти истории, все эти мифы, они следуют за мономиф Образец, они — все один и тот же миф, но у некоторых из них немного больше шагов, у некоторых из них отсутствуют некоторые шаги, но общий шаблон одинаков. Таким образом, вы могли бы на самом деле разбить их все на один и тот же шаблон. То же самое происходит в реализации практик DevOps.
Барух Непосредственно перед тем, как мы перейдем к реализации, кредит, в котором должен быть получен кредит. Итак, Джозеф Кэмпбелл, книга, из которой мы все узнали, называется Герой с тысячей лиц Анкет Ему 70 лет, но все же очень актуально. Вот где теория мономита установлена. Так что вы говорите, что путешествие героя Devops питается в этой теории мономита, и это то же самое путешествие, что и путешествие Иисуса в этом отношении.
Антон: Конечно. Так что это путешествие к лучшей жизни через трудности и проблемы, которые вы видите в пути. Но когда я начал думать о том, что такое путешествие, я понял, что всегда есть эта стадия, когда вы понимаете, что независимо от того, сколько вещей вы автоматизируете, независимо Узкое место — это человеческое обсуждение, человеческое общение.
Ну, вот с чего начались DevOps. Давайте возьмем Оригинальный разговор Джона Алсопы и Пола Хаммонда , что фактически заставило Патрика Дебуа изобретать DevOps. Речь шла о том, как им удалось развернуть 10 раз в день в Flickr. Потому что их разработчики начали думать немного больше как OPS, и их OPS начали думать немного больше как разработчики. Так что все было связано с изменением мышления, это было все о смене мышления. Никто не говорил о Kubernetes, извините за мой французский, в то время.
Барух: Вы полностью отказались от моего вопроса, потому что, говоря, что проблема всех заключается в сотрудничестве, все равно, что сказать, что проблема в том, что все люди. Хотя это правда, это настолько широкое, что это не совсем действенное. Позвольте мне еще раз спросить вас, может быть, даже связанная с технологиями, какие более крупные узкие места вы видите? Например, вы упомянули, что большинство компаний не выполняют непрерывную доставку, это один из них или есть другие, или, может быть, это не самая большая проблема вообще?
Антон: Связанные с технологиями. Что ж, самая большая проблема, связанная с технологиями, конечно, управляет сложностью.
Шкала, в которой мы работаем сегодня в крупных организациях, особенно вызывает столько сложности, что действительно очень, очень трудно управлять этим, концептуально и технологически. Так что очень легко построить трубопровод для одного монолитного обслуживания, в то время как он еще маленький И имеет небольшое количество зависимостей. И когда у нас есть одна, две, может быть, три команды, это легко. В тот момент, когда нам нужно управлять несколькими дюжинами микросервисов с несколькими десятками команд, это становится трудным, потому что даже с инструментами, которые мы строим сегодня, мы не разрешаем концептуальное понимание этого. Так что инструмент есть, возьмите, например, Kubernetes. Kubernetes — отличный инструмент, но для управления этой сложностью сам инструмент должен быть сложным. Тогда мы, люди, оказываемся ограниченными в нашей способности управлять им.
Кат: Kubernetes действительно сложно. Кривая обучения там крутая.
Антон В яблочко. Так что это технологическая проблема, а также это задача управления, потому что инженеры имеют дело со сложными крупномасштабными технологиями, которые очень сложны. Это сложно для них, чтобы понять. Ни у кого нет всей картины. Одним из последних проектов, которые мы создаем, является конвейер непрерывной доставки для науки о данных. Таким образом, есть те рабочие процессы ETL, которые работают в воздушном потоке. Затем нам нужно понять, как постоянно доставлять эти даты воздушного потока (направленные ациклические графики) в производственную среду. Мы используем сам поток воздуха? Мы используем Дженкинс? Как эти инструменты взаимодействуют? Ни один из непрерывных инженеров по доставке не понимает сложность, связанную с процессами ETL. Никто из инженеров ETL не понимает, как выполняется непрерывная доставка. Итак, как мы можем заставить эти вещи работать вместе? Нет ответов, очень тяжело. Теперь возьмите менеджера, который пытается заставить эти две команды работать вместе. Что этот менеджер говорит им? Как этот менеджер позволяет им работать вместе? Это сложно.
Кэт: Так что это все еще проблема людей, а не строго технологическая проблема?
Антон: Да. Что ж, технология все еще не развита, где масштабирование может быть быстрее, чем развивается инструмент. Например, я думал об этом, есть несколько технологий, которые меня действительно удивляют. Например, возьмите автоматические предложения из Google. Когда вы вводите сообщения сегодня, есть автоматизированные предложения. На самом деле вы можете увидеть, как это становится умнее каждый день, тогда как два года назад это было действительно, действительно глупо.
Кат: Это было. Другим примером является Twitter Flashmob, который идет туда, где вы начинаете предложение с чем -то предопределенным, например: «Я бросаю технологии, потому что …» И тогда вы позволяете автозаполнению закончить его для вас. Это выпускается, это как настоящие предложения. Один из моих друзей получил: «Я бросаю технологию, чтобы стать художником». Боже, я знаю людей, которые на самом деле сделали это. Это реальная вещь.
Антон: Так что нам действительно нужна наша технология доставки, развертывание, чтобы быть такими. Если я построил развертывание и не будет развернуто, система должна предложить мне это. Сказав: «Это, когда вы перекатите его на производство, будет сломано». Так что, может быть, то, что вы действительно имели в виду, говорило: «Я хочу, чтобы это было, я не знаю, очень доступен. «Вы говорите, что хотите хранилище Blob Но на самом деле вы, вероятно, хотите использовать S3.
Кат: Мы хотим всплесков инструментов. Я не хочу, чтобы мои развертывания делали все для меня, потому что этот уровень оставления определенных проблем безопасности или сетевых проблем до автоматического мастера делает меня немного неудобным. В конце концов это довольно последовательно. Но подсказка была бы неплохо. Мол: «Эй, ты уверен, что действительно хочешь сделать это так? Потому что это может быть не идеально. «Я думаю, что сейчас это делает какой -то инструмент. Верно? Разве у нас нет конфигураций и исправлений на платформе?
Барух: Я думаю, что многие чаты делают это. Один из примеров — Автомобиль . Они дают вам намеки на то, что может быть неправильным, а затем очень простой способ исправить это одним предварительно зарегистрированным ответом.
Кат: Линкер для ваших OPS.
Антон: Индустрия движется в этом направлении. Здесь также есть стартап, с которым я недавно разговаривал. Мы думаем в этом направлении ответ инцидента. Как они говорят, мы можем найти определенные шаблоны в том, как мы решаем определенные проблемы или как мы отлаживаем определенные проблемы.
Кэт: Так что нам нужно, так это повелителя ИИ. Вот куда мы движемся.
Антон: Это даже не искусственный интеллект, это больше похоже на машинное обучение. Не та система, которая думает сама по себе, а система, которая, по крайней мере, учитывает то, что мы знаем, люди.
Кат: Барух, будет ли ML, который обрабатывает такую вымышленную систему, может ли это быть инженером DevOps?
Барух: О, это хороший вопрос. Это все о сотрудничестве снова. Почему я не верю, что инженер Devops — настоящая работа, потому что DevOps — это сотрудничество. Налив инженеры DevOps, занимающиеся DevOps весь день, это похоже на то, чтобы инженеры по сотрудничеству занимались сотрудничеством в течение всего дня. Я имею в виду, что это не имеет смысла, и именно поэтому у нас есть уполномоченные команды и T -образные люди, которые на самом деле много знают об одной теме и немного обо всем остальном.
Машинный искусственный интеллект, о котором мы говорим, вероятно, способен быть О-образным инженером и знает все обо всем. Но пока мы не доберемся туда, нам все еще нужны люди, которые специализируются на разных вещах, и ничто из этого не является технической дисциплиной.
Антон, я хотел вернуться к тому, что вы сказали о сложности. Поскольку я пытаюсь выяснить, вы как консультант, вы видели все это, вы прошли через все это. Как посоветовать людям сложно? Потому что я думаю, что есть два сценария. Один из них не нужен. Люди только что влюбились в некоторые архитектуры, изобретенные в башнях из слоновой кости, и нанося это на себя, когда им это не нужно.
Кэт: Это больное место для меня. Я ненавижу это, когда люди это делают.
Барух: Но хорошая новость в том, что это исправлено. Все, что вы можете сказать, это, хорошо, вы выбрасываете все это, вы начинаете легко, вы начинаете с малого, вы начинаете со своего управляемого маленького или монолита и идете оттуда. Но я имею в виду, это не просто, но вы знаете, как это сделать, и решение уходит от сложности. Я думаю, что более ужасный сценарий — это когда вы не можете уйти от сложности. Когда сложность является необходимостью как часть ваших бизнес -требований или бизнес -ситуации, в чем вы находитесь, что вы делаете?
Кэт: Это большой вопрос.
Антон: Вы делаете все возможное, чтобы управлять сложностью. Это может показаться немного расплывчатым, но как мыслитель системы (мне нравится называть себя системным мыслителем, потому что это звучит очень модно) Например, меня учили замечательные люди, Доктор Рассел Аккофф , что сложность не входит в компетентность системы. Если мы разбиваем систему на множество компонентов и сделаем каждый компонент проще. Система в целом становится проще, потому что сложность заключается в взаимодействии между компонентами.
Таким образом, управление сложностью в основном управляет взаимодействием между компонентами. Что ж, я думаю, что первое, что вы должны сделать, это каким -то образом попытаться изложить все возможное взаимодействие между компонентами в вашей системе и приложить необходимые усилия по управлению этими взаимодействиями. Это на самом деле то, что мы пытаемся сделать сегодня с технологией, в которой я немного влюблен. Это будут сетки обслуживания.
Барух: Хорошо, это очень хороший переход. Я люблю это. Давайте переключим шестерни и немного поговорим о технологиях. Это было много о методологии и еще много чего. Давайте поговорим о хардкорных вещах. Сетки как ответ для проблем сложности. Поговори с нами.
Антон: Что ж, в основном, как я уже сказал, лучший способ управлять сложностью — это управление взаимодействиями между компонентами, а не упрощила компоненты. Мы позволим компетенции быть настолько сложной, насколько это нужно, и мы на самом деле позволим взаимодействиям быть настолько сложными, насколько это должно быть. Но нам нужно сделать эти взаимодействия понятными, управляемыми, и для этого нам нужно другое модное слово. Наблюдаемость этих взаимодействий. Это одна из вещей, которые сетки услуг позволяют более или менее выходить из коробки.
Кат: Для людей, которые смотрят это, которые, возможно, не очень знакомы с пространством, можете ли вы просто рассказать, что на самом деле является сервисной сеткой и как она может выглядеть?
Антон: Хорошо, очень короткое введение в сетки обслуживания без диаграмм. Это на самом деле то, что немного сложно понять без диаграммы.
Микросервисы или любая сложная распределенная система, которую мы могли бы создать, вызывают боль макрос. Потому что есть много сложности для управления. Наши услуги продолжают разговаривать друг с другом, и некоторые услуги, с которыми мы говорим, не отвечают своевременно. Некоторые услуги по какой -то причине недоступны. Или другие услуги не предоставляют ответы, которые мы ожидаем предоставить.
Кэт: Конечно, это выглядит как версия кода спагетти микросервиса.
Антон: Да. Более или менее это то, что со временем вырастает любая сложная система. Теперь, чтобы справиться со всеми этими проблемами, со временем был разработан ряд методов для решения всех проблем распределенных систем. Как и в коде спагетти прямо здесь, у вас есть проблемы кода спагетти взаимодействия между компонентами. Но когда вы начинаете запускать систему микросервиса, есть еще один очень важный компонент системы. Это сеть, потому что в системе микросервиса все наши компоненты взаимодействуют друг с другом по сети, верно?
Кэт: Конечно, да.
Антон: Эта сеть ненадежна. Эта сеть может быть медленной. Эта сеть может по какой -то причине отклонить протоколы, с которыми мы хотим поговорить по этой сети. Чтобы управлять всей этой сложностью и отсутствием надежности со временем, мы разработали ряд шаблонов, такие как пулы соединений, чтобы иметь достаточно подключений, когда они нам нужны. Все виды детекторов сбоев, стратегии отказа от переключения, такие вещи, как разрыв схемы, удары, удары, экспоненциальные отступления. Балансировщики нагрузки, конечно, методы обратного давления, такие как ограничение скорости, и так далее.
До сих пор у нас было несколько компаний, которые позволили бы нам управлять этим, но многие из этих проблем все еще были управлялись в Кодексе разработчиками. Но многие из них можно рассматривать как фактически операционные проблемы. Это разрыв между разработчиками, реализующими оперативные проблемы, но затем операторы наткнулись на них, это вызвало у нас много проблем. Вот почему в 2016 году ребята из компании под названием Buoyant создали систему под названием Линкерд (Это было на самом деле первое в мире, что сетчалось, что мир знал). Их создание этого компонента было основано на их опыте в Twitter. Twitter известен библиотеками, которые они создали специально для решения этих проблем. Такие вещи, как Finagle. Они взяли этот опыт из Twitter, и они создали его в отдельном компоненте, говоря, что мы не хотим, чтобы каждый разработчик начал интегрироваться с этой библиотекой. Потому что управление библиотеками также болезненно.
Давайте управляем всем этим автоматическим процессом. Давайте построим сетку с помощью интеллектуальных прокси, которые будут проживать рядом с каждой из наших услуг. Мы сможем управлять всеми этими прокси из централизованного места. Таким образом, мы можем предоставить центральное решение для всех этих проблем и проблем с надежностью распределенной системы. Это в основном то, что такое сервисная сетка. Теперь концепция развилась в значительной степени благодаря Istio Анкет Лидер рынка в реализации концепции сервисной сетки, модели сервисной сетки, которая была разработана Google в сотрудничестве с Lyft и IBM.
В основном это работает. Помимо Istio, у нас также есть Linkerd. У нас также есть Консоль Connect прямо сейчас. Теперь все они в основном делают, так это то, что они ставят интеллектуальные прокси рядом с нашими услугами и предоставляют нам плоскость управления, которая позволяет нам управлять тем, как настраивается эти прокси. Мы можем настроить их для определения всех этих методов надежности. Определить, какой трафик разрешен. Чтобы определить, как управляется трафиком. Это также позволяет нам обеспечить барьеры безопасности для сетевой связи между услугами. И это также позволяет нам наблюдать, потому что с помощью этой плоскости управления мы также можем извлечь данные из всех этих прокси, чтобы понять, о чем говорят наши услуги.
Барух: Мы в основном экстернализуем сетевую связь, и это позволяет нам увидеть, что происходит, и контролировать, что должно говорить с чем.
Кэт: Это слой абстракции поверх ваших распределенных систем, так что он кажется более здравым. Это более читаемое на человеке, а не просто читаемое на машине.
Антон: Для людей, которые управляют Kubernetes, и сегодня в основном в 90% случаев вы развертываете сервисную сетку над Kubernetes. На Kubernetes плоскость данных прокси на самом деле представляют собой боковые карты, которые вводят в каждый из ваших стручков. Плоскость управления — это компоненты, которые работают где -то в кластере и позволяют извлекать данные из этих прокси и настраивать их
Кат: Потому что, на мой взгляд, слишком много, чтобы ожидать, что, как и каждый инженер, является экспертом в Kubernetes или экспертом в любом другом инструменте DevOps. Вы должны быть экспертом в своей вещи, но вы также не можете быть экспертом в Kubernetes. Вам нужно что -то, чтобы сделать эту информацию все еще доступной и полезной для вас. Но вам не обязательно нужно знать, как погрузиться в кластер, смотреть на каждый микросервис индивидуально и выяснить, что не так с этой сетью.
Антон: Верно. Кстати, возвращаясь к тому, о чем мы говорили ранее, есть также инструменты для ведущих сервисных сетей, которые позволяют вам проанализировать конфигурацию в сервисной сетке и найти возможные неправильные сборы. Потому что, опять же, допустим, у меня есть сотня услуг, они все общаются друг с другом. Мне нужно определить роли безопасности для этого общения. Кому разрешено поговорить с кем и с каким движением разрешен и что -то еще. Что -то неправильно настроено, очень трудно понять, поэтому нам нужны некоторые умные в системе, которые скажут нам, где ваша проблема.
Кат: Да, потому что компьютер или система или приложение так же умно, как и человек, который его построил, или человека, который запрограммировал его. Но компьютеры, приложения и такие системы не устают. Им не скучно, и они не отвлекаются, и люди делают. Поэтому нам легче допустить ошибки в повторяющихся вещах, таких как настройки безопасности для тысячи различных микросервисов. Потому что нам скучно или отвлекается.
Антон: В целом. Нам очень легко совершать ошибки.
Барух: Ага. Итак, я пытаюсь представить эту схему потока для консультирования DevOps Consultancy И я думаю, что у меня есть сцепление с этим. Таким образом, в основном существует два типа сложности: необходимый и не необходимый. И для ненужных, очевидно, вы пытаетесь убедить людей упростить вещи, упростить архитектуры, возможно, мигрировать из ненужных микросервисов и так далее. И для необходимых вы пытаетесь предложить им больше контроля, внедряя меры услуг в качестве решения для управления этой сложностью путем контроля над связи между различными компонентами.
Антон: Это могут быть сетки обслуживания. Это может быть просто здоровые практики эволюции API, чтобы всякий раз, когда мы теряем вашу версию, мы не ломаем API для потребителей. И это можно управлять с помощью контрактного тестирования, ориентированного на потребителя. Существуют методы для управления взаимодействием между компетентностью системы, кроме мер обслуживания только одного из примеров.
Барух: Так что для API Evolution, например, есть ли у вас методология, которую вы предлагаете, или, может быть, некоторые инструменты вокруг нее? Или вы просто идете и говорите, что убедитесь, что они версии? Есть ли что -то структурированное, когда вы говорите о правильном подходе API?
Антон: Ну, там ничего нового. Прежде всего, не сломайте API.
Барух: Проще сказать, чем сделать. Это очень широкое правило, которое, вероятно, есть хорошие исключения.
Кейт: Что было бы хорошим исключением, когда вам следует сломать API?
Барух: Я бы сказал, что основные версии, которые вам определенно должны быть разрешены, чтобы сломать API.
Антон: Ага. Тогда то же самое с эволюцией структурированных баз данных только добавляют поля и не удаляйте поля.
Барух: Но именно так вы попадете прямо в эту сложность, когда у вас слишком много всего всего, только потому, что вы продолжаете добавлять и никогда ничего не удаляете. Как это хорошо?
Антон: Итак, когда вы, наконец, решите сломать API, удалите все избыточные поля и обязательно сообщите об этом каждому пользователю, который у вас есть. Таким образом, в основном все сводится в конце концов, со всеми правилами, касающимися нарушения API, а также о том, как продвигать API и как добавлять поля и никогда не удалять поля. Это все о том, что делают наши пользователи. Если мы действительно хотим знать, что делают наши клиенты. Нам нужно иметь Контракты, управляемые потребителем на месте.
Барух: Что это?
Антон: Ну, сама концепция была предложена мыслительными работами. Я думаю, что это был сам Мартин Фаулер или один из людей в «Мыслил». И сегодня на рынке есть инструменты. Есть система под названием Пакт , в основном то, что он позволяет вам делать, — это всякий раз, когда вы создаете API, вы создаете тест для этого и всякий раз, когда вы называете API, вы также создаете тесты для этого, и вы экспертируете определения для этих тестов. Поэтому всякий раз, когда я потребляю API, я могу экспертизировать определение того, что моя служба ожидает от API, и наращивает макет. В тесте я строю издевательства, и эти макет определяют поведение, которое я ожидаю от своего поставщика. А потом где -то в моем CI, если мои тесты прошли, я принимаю определение теста и передаю его поставщику, и поставщик должен убедиться, что эти тесты также работают в их конвейере CD. Таким образом, поставщик несет ответственность за то, что API не сломается.
Катя: Это другое. Это классно.
Барух: Конечно, но это добавляет много сложности. Это оправдано, когда вы имеете дело с внешними потребителями, которые, очевидно, имеют ожидания того, что вы предоставляете постоянные обновления качества. Для этого вам, очевидно, нужен непрерывный шаблон обновлений, когда мы можем доверять друг другу, потому что мне нужно, чтобы вы вслепокнули мои обновления, и вам нужно, чтобы я не ломал вещи. Но я бы сказал, что микросервисы заключаются в том, чтобы каждый микросервис подвергал API, а затем другие микросервисные, потребляющие их API, и если я начну делать все это вокруг каждого микросервиса, это тонны накладных расходов.
Кат: Я не знаю. Я думаю, что это хорошо, чтобы добавить дополнительную сложность, если она даст вам равную или большую оценку согласованности и надежности. Но это только я. Я потрачу кучу времени и усилий, чтобы убедиться, что как можно больше автоматизировано на передней части, чтобы мне не приходилось иметь дело с этим позже. Но это я.
Антон: Да, я согласен с тобой, Кэт. В основном они говорят, что вы не можете действительно справиться с сложностью с простотой, поэтому вам придется добавить сложность, чтобы управлять сложностью.
Барух: Вопрос в том, что есть компромиссы для наличия микросервисов, и я бы сказал, что API на основе контрактов и все, что на самом деле добавляет большой вес к контраргументию, возможно, мне вообще не нужны.
Антон: Ну в определенном масштабе вы должны иметь их, потому что монолит великолепен, пока он не станет огромным. Потому что в определенных моментах есть этот вопрос гравитации. Так что только на прошлой неделе кто -то рассказывал мне о том, как они пытаются перенести свой монолит в Kubernetes, не разбивая его на микросервисы. Таким образом, они пытались создать изображение Docker, но они поняли, что на самом деле сейчас их система упакована как изображение виртуальной машины. И когда они попытались превратить это в изображение Docker, они получили изображение Docker, которое весит 125 гигабайт, потому что их система требует что -то вроде 500 об/мин для установки.
Кат: Святой чувак.
Антон: Но это работающая монолитная система. У них есть клиенты, у них есть платящие клиенты, их система работает. Единственная проблема с этим в том, что она очень, очень тяжелая, поэтому ее трудно доставить. Мы все знаем это, что если у вас есть система, которая занимает часы, на то, чтобы упаковать несколько часов, требуется даже десятки минут, чтобы начать работу. Есть много времени … В то время, которое вы тратите, просто смотрит на свой экран.
Кэт: Да, это огромная трата времени, энергии, денег, рабочей силы, никто не хочет нести ответственность за это. Это не инженер, это няня.
Антон: Вот где возникает потребность в микросервисе. Вы хотите сделать жизнь инженеров лучше.
Барух: Вы говорите, что иногда нет спасения из сложности, и вам просто нужно принять это и попытаться справиться с инструментами, которые у нас есть.
Антон: В яблочко. Притворяться, что нет сложности, это худшее, что может произойти. На самом деле есть очень хороший документальный фильм, который я только что посмотрел. Это не новый. Это с 2016 года Адам Кертис является одним из моих любимых документальных директоров, делающих документальные фильмы на BBC. Итак, его последний называется Гипернормализация И в нем говорится о том, как мир становится все более сложным и как политики в основном пытаются заставить нас поверить, что это просто. И что они контролируют и как это никогда не идет правильно. И мы на самом деле являемся свидетелями этого прямо сейчас среди того, что никто не знает, как контролировать.
Барух: Интересно. И это возвращает меня к тому, с чего мы начали. И это ваш консультационный концерт и ваше сообщение, которое вам нужно передать тем, кто вас нанимает. И в конце концов, я думаю, что сообщение, с которым вы пришли, не утешительно. Так что в основном вы не можете сказать: «Люди, у меня есть это. У меня серебряная пуля. Я собираюсь исправить все для вас. «Это было бы просто безответственно и неправильно. Вместо этого вы должны признать, что все сложно. Все ужасно. Все сложно. У меня нет всех ответов. И что потом?
Антон: Ну, во -первых, я могу помочь вам уменьшить боль. Хорошо? И тогда я буду с вами в этом путешествии. Я буду сопровождать вас в путешествии, и я буду там, чтобы держать вас за руку, и вместе мы сможем сделать это лучше. Это в основном обмен сообщениями.
Кат: Все отстой, но вы не одиноки.
Антон: Верно. На самом деле одна из вещей, которую я, как консультант, — это изучать отрасль и правильные примеры этих процессов, что делает вещи лучше. Есть примеры этих преобразований, которые действительно приносят выгоды, прибыль, счастье, успех, что угодно. Мы не знаем, является ли это постоянным, но даже на временной основе, если сегодня что -то работает лучше, чем вчера, то это доказательство того, что есть методы, которые можно использовать.
Барух: Хорошо. Таким образом, с таким оптимистичным посланием, нам это будет хорошее время, чтобы завершить.
Антон: Спасибо, ребята. Спасибо.
Кат: Спасибо. До свидания.
Оригинал: «https://dev.to/jfrog/devops-speakeasy-podcast-s01e01-interview-with-ant-weiss-10cm»