Хабрахабр

Не бойся микросервиса: Алексей Баитов об использовании микросервисной архитектуры на практике

Для одних микросервисы — это возможность переделать и отрефакторить приложение под условно современный стиль. Другим это архитектурное решение не подходит из-за особенности взаимодействия различных частей приложения. В любом случае, выбирая архитектуру, полезно изучить чужой опыт перехода от монолита к набору сервисов.

Поговорим на тему архитектурных решений, деплоя и возможности масштабирования. Мы попросили поделится своим кейсом разработки и доставки микросервисов Алексея Баитова, ведущего инженера 2ГИС. Расспросим про трендовые и просто удобные инструменты для работы.

Над чем сейчас работаете?
     
В IT я пришел в далеком 2003 году как системный администратор, в разработку погрузился в 2011 году.
— Алексей, расскажи, пожалуйста, немного о себе и о твоей команде в 2ГИС. В 2ГИС работаю с 2015 года. За это время поработал на PHP, JavaScript, реализовал серию RESTful сервисов и Python-драйвер для Git.

Первая состояла из одного сервиса. Поучаствовал в разработке двух микросервисных архитектур. По сути он занимался досылкой сообщений. Это был асинхронный реверсивный прокси с кэшем. Проработкой требований, разработкой и выстраиванием DevOps занимался я один, но мне помогали эксперты из нашей компании 2ГИС.

Быстрая компиляция позволила не ждать, и я смог сконцентрироваться и на Continuous Deployment. Сервис был написан на Go. У нас есть команда Infrastructure and Operations, которая как раз к моменту моей разработки вывела все эти инфраструктурные решения на production ready уровень. Тогда мы только начинали использовать GitLab CI, Prometheus, Grafana и Deis (open source аналог Heroku). Я решил попробовать все это и успешно реализовал независимый микросервис.

Наша команда с нуля разработала микросервисную архитектуру для хранилища рекламных материалов 2ГИС на Scala, C# и JavaScript. Два года назад я перешел в другую команду на новый проект, где стал заниматься функциональным программированием на Scala. Архитектура прошла путь от прототипа до промышленной эксплуатации. В основу всех сервисов я заложил инструментарий и полученный опыт для выстраивания практик DevOps (Continuous Deployment и сопровождение). Она поглотила два монолита, теперь состоит из 15 сервисов и постоянно расширяется.

 Данное определение нужно расширять? — Ты согласен, что микросервисы по сути являются набором независимо развернутых сервисов, имеющих общие характеристики, то есть именно набор определенных черт придает им вид микросервиса? Или по факту компании по-разному понимают микросервисную архитектуру?

Микросервисная архитектура — это архитектурный стиль, который структурирует приложение как коллекцию слабо связанных сервисов, которые реализуют определенную бизнес-логику. Мне нравится следующее определение. Сервисы в микросервисной архитектуре могут не обладать общими характеристиками, но объединяются в рамках общей бизнес-логики.

Это ведь набор практик: распределенная архитектура, непрерывная интеграция и доставка и так далее. Конечно, у каждой компании будет «свой» микросервис. Если расширить понятие практики до используемых инструментов, варианты реализации микросервисов будут самые разнообразные.

— Существуют разные мнения о составе команды, которая должна быть задействована в написании и поддержке микросервисов. Что ты думаешь об этом? Какова оптимальная численность команды и как должно быть построено взаимодействием внутри нее при разработке микросервисной архитектуры? Есть ли удачный пример командной работы из твоей практики?

При этом в разработке этого сервиса могут участвовать несколько человек. Считается правильным разрабатывать сервис таким образом, чтобы вся его предметная область могла уместиться в голове одного разработчика. Корректное разбиение на сервисы позволяет новому человеку быстро войти в контекст. Это поможет избежать bus-фактора, когда разработчик ушел в отпуск или заболел.

Таким образом, одним разработчиком уже не обойтись. «Микросервисная архитектура» говорит нам о том, что в ее состав часто входят несколько сервисов. Разработчики подбираются так, чтобы получилось эту модель реализовать и при этом сфокусироваться на клиенте. Микросервисная архитектура отталкивается от продуктовой модели (или общей бизнес-логики).

Разработчикам надо видеть, как используется их продукт. Фокусировка на клиенте организуется за счет прямого контакта разработчика с клиентом. Отсюда уже вытекают пожелания к знаниям в технологической области, умению как можно быстрее доставить продукт клиенту и сопровождать продукт.

Всем уже, наверно, известно высказывание Джефа Безоса, основателя Amazon, что размер команды при сервис-ориентированной разработке должен быть достаточно мал, чтобы всех можно было накормить двумя пиццами. Про численность команды однозначно сказать сложно. Мартин Фаулер же, цитируя высказывание про две пиццы, сказал, что речь идет про большие американские пиццы, после чего уточнил, что в команде должно быть не 50, а в районе 12 человек. В комментариях на Хабре была дискуссия на эту тему, и там писали, что одному человеку может быть мало одной пиццы и поэтому команда должна состоять из одного-двух человек. Но уточнение Фаулера про «не более 12 человек» на моей практике пока выигрывало. Я считаю, что все зависит от продуктовой модели. Я заметил, что внутри команды желательно разделиться по технологическим интересам, найти единомышленников.

Например, два человека занимаются первоначальным выстраиванием деплоя и в будущем, скорее всего, они также значительно его усовершенствуют. Необязательно, чтобы все в команде хорошо знали все используемые в работе  технологические области, но суммарные знания команды должны быть равномерно глубокими. Это позволит ей высказывать пожелания и вносить изменения. Но при этом вся команда должна хорошо понимать процесс деплоя. Потому что порой один человек может впасть в творческий ступор. Почему два человека? А в дискуссии рождается истина.

При этом разработчик может также заниматься налаживанием DevOps-практик, а QA-инженер — разрабатывать вспомогательный, не-продакшн сервис (например, прогревалку кэша или сервис поиска аномалий в данных на разных окружениях). Мы естественным образом построились по такому принципу, объединились по технологическим интересам.

— Почти каждый доклад о микросервисах начинается с рассказа о том, что «вот у нас был „айсберг“ и мы его пилили, пилили, пилили… Новые части приложения делали на основе микросервисов, а затем уже начали отделять „кусочки“ от основной махины…»

Как верно определить стратегию «выхода»? Скажи, ты сторонник разработки с нуля или могут быть ситуации, когда стоит делать постепенный вывод из монолита?

Но это работает только в случае не слишком сложного набора функций. Я сторонник разработки с нуля. И иногда приходится несколько раз в корне менять его внутреннюю реализацию. Обычно делается небольшой MVP-монолит. После этого можно переходить к микросервисной архитектуре. Это может быть вызвано как сменой технического задания, так и тем, что приходит понимание реализации — появляются высокоуровневые абстракции на уровне бизнес-модели.

Но если хорошо проработать эти абстракции в самом начале и прорисовать их в разных нотациях (UML, BPMN, IDEF), чтобы все участники процесса понимали то, с чем они работают, то вполне возможно реализовать микросервисную архитектуру сразу.

Сначала был монолит. Наш путь к микросервисной архитектуре был не прямой. Три с половиной года назад нам потребовалось работать с графическими рекламными материалами (изображениями, логотипами). Он обрабатывал текстовые рекламные материалы. Было желание внести в бизнес-логику то, чего не хватало при работе с текстовыми рекламными материалами.

После полутора лет эксплуатации мы поняли, что такой подход был верным. Чтобы опробовать новую бизнес-модель, мы реализовали работу с графическими рекламными материалами как второй монолит на другом стеке технологий.

За это время у нас появилось много хотелок, выявились шероховатости бизнес-логики.

Поэтому мы решили не вести разработку сразу в двух монолитах, а объединить их в рамках третьей архитектуры по той самой новой бизнес-модели. Реализация второго монолита была сложно расширяемой на первый. Два разработчика из этой команды ранее создавали и поддерживали первый монолит, а еще один — второй монолит. Была создана команда в составе семи разработчиков, одного QA-инженера и двух аналитиков. То есть наша команда уже на входе хорошо знала подводные камни предыдущих монолитов.

Второй — на PHP. Первый монолит был написан на C#. PHP-код под эти требования частично не попадал. Нам не хотелось терять отлаженные объемные куски кода из первого монолита и при этом требовались многопоточность, безопасный код и строгая типизация. Поэтому C# остался как основа и реализовал то, что он хорошо делал в рамках первого монолита — работу с контентом рекламных материалов —  но уже на базе другого хранилища: S3-совместимого хранилища и Kafka.

Scala удовлетворяла нашим техническим требованиям. Для работы с той самой новой бизнес-моделью на этот раз была выбрана Scala и база данных PostgreSQL. Это сокращало время на межкомандные коммуникации. К тому же, Scala-разработчики располагались на том же этаже, что и C# разработчики. PHP-разработчик перепрофилировался в Scala-разработчика. Сработал закон Конвея — структура компании продиктовала структуру приложения. Я же как раз закончил работу над независимым микросервисом на Golang с полным CI/CD циклом, после чего пришел в команду и тоже стал Scala-разработчиком.

Дело в том, что у нас не было достаточного количества C#-разработчиков. Интересно, что именно я предложил использовать для работы с бизнес-логикой Scala, а не C#. Плюс у нас была возможность привлечь опытного Scala-разработчика. PHP-шник и я хотели переквалифицироваться на Scala. Разделение же на Scala и C#, различные по потребностям хранилища и наличие опытных разработчиков в каждой из требуемых областей  - все это прямо указывало нам на микросервисную архитектуру. Еще момент: если бы мы реализовывали все на C#, то на выходе могли бы получить либо микросервисную архитектуру, либо очередной монолит. Год назад микросервисная архитектура по работе с графическими и текстовыми материалами вышла в промышленную эксплуатацию и успешно работает до сих пор. И мы от этого только выиграли.

Полтора года назад в процессе работы над микросервисной архитектурой к нам пришло требование поддержать новое направление в наших продуктах — видеорекламные материалы. К вопросу о том, можно ли создать микросервисную архитектуру с нуля. Наша архитектура была в начальной стадии разработки. Необходимо было в короткие сроки опробовать новую модель продаж. Вектор развития мы решили не менять и реализовали MVP по видеоматериалам как отдельно стоящую микросервисную архитектуру на C# и доверенном видеохостинге. Работа с видеоматериалами охватывала новую область технологий. Таким образом, у нас появилось две параллельно существующих микросервисных архитектуры. Это успешный опыт, и у нас есть доклад на эту тему. MVP сильно не развивался, по нему также накопились хотелки и в скором времени мы объединим все в рамках одной микросервисной архитектуры — получится единое хранилище рекламных текстовых, графических и видеоматериалов.

Первый — возможность вывода отдельных частей в облако и, как следствие, колоссальная масштабируемость. — Сходу можно назвать два важных фактора, которые говорят в пользу микросервисов. Какие еще ты видишь плюсы перехода на микросервисы? Второй —  возможность создания отдельного сервиса на другом языке. Ну и о минусах, конечно, тоже хочется услышать.

А если он нас не устроит, выберем еще один. Если говорить про технологическую составляющую, то к плюсам, помимо перечисленного, можно отнести возможность использования другого стека технологий. Микросервисная архитектура также дает устойчивость и независимость: деградация одного сервиса не должна приводить к полной деградации всей системы. Новые технологии обходят проблемы старых решений. С точки зрения организационной составляющей разбиение на сервисы позволяет разделить разработку в пределах распределенных команд или одной большой команды.
Компонуемость сервисов позволяет переиспользовать функционал сервиса в других микросервисных архитектурах.

Основные минусы микросервисной архитектуры: она гораздо сложнее, а ее реализация обходится дороже.

Еще нужно быть готовым к поддержке контрактов сервисов, выбору правильного протокола удаленного доступа, решению вопросов безопасного межсервисного взаимодействия, возможным отказам, а также к дедупликации и управлению распределенными транзакциями.

Но по факту все зависит от задачи. Вообще в свободном доступе можно найти много информации и материалов о том, как с этим работать. На моей практике плюсы всегда оказывались весомее минусов.

Еще стоит вспомнить слова Сэма Ньюмена: чем меньше сервис, тем сильнее проявляются все преимущества и недостатки микросервисной архитектуры.

Деплой микросервисов и Подход к Continuous Deployment в микросервисной архитектуре. — У тебя есть несколько интересных докладов про микросервисы. За это время ничего не изменилось? На одном из слайдов первого есть «шаблоны» деплоя, а в докладе ты говоришь о том, что для вас трендовым подходом является распространение через контейнеры. Связка Docker + Kubernetes не утратила актуальность?

Я думаю, что мы выбрали правильное направление и пока планируем его придерживаться. Мы переводим на эту связку все больше и больше сервисов. Если что-то поменяется, я обязательно расскажу об этом в новом докладе или интервью.

— Насколько беспроблемным является непрерывный деплой и передача микросервисов на прод?

Вначале кажется, что все просто. Все зависит от того, как выстроить процесс. Слабая связанность обеспечивается за счет разных подходов к работе с эволюцией контракта. Сервисы независимы, деплоятся порознь. Например, можно внедрить версионирование контракта или добавить сервис для разъединения контракта (contract decoupling). И тут уже приходится выбирать.

Надо стараться не запутаться в совместимости сервисов разных версий. Если в микросервисной архитектуре в активной разработке находятся сразу 10 или больше сервисов и у каждого свое версионирование, то возникает проблема согласованности версий.

Непрерывный деплой подразумевает, что мы можем доставить приложение в любое время на любое окружение.

Значит, в любой момент времени нам нужно знать стабильное сочетание версий сервисов. Приложением в микросервисной архитектуре является коллекция сервисов. А еще мы должны где-то иметь совокупность доменных адресов и другие параметры, свойственные для разных окружений для конфигурирования сервисов и связывания их друг с другом.

Все это нужно где-то хранить, править изменения в нескольких местах (микросервисы ведь независимы) и не запутаться.

Соответственно, может быть так, что потребуется откатить сразу несколько сервисов и нужно будет соблюсти правильный обратный порядок деплоя сервисов. Непрерывный деплой подразумевает возможность в любое время откатиться на любую версию.

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

Какие варианты ты бы посоветовал использовать для работы с микросервисами? — Какой может быть начальный набор инструментов  для непрерывного деплоя микросервисов?

Наиболее популярными инструментами для последовательного выполнения этапов являются Jenkins 2 Pipelines, TeamCity Build Chains, Bitbucket Pipelines и GitLab CI Pipelines. Непрерывный деплой — это последовательность этапов (pipelines), включающих непрерывную интеграцию, интеграционные тесты и доставку сервиса на среду оркестрации. Нужен удаленный CI сервер, который бы занимался сборкой и прогоном тестов на этой сборке. Вначале нужно автоматизировать непрерывную интеграцию (Continuous Integration, CI).

Мы используем GitLab CI, и в качестве таких серверов выступают GitLab Runner’ы. Перечисленные инструменты предлагают свои решения. В рамках интеграционных тестов можно провести нагрузочные и емкостные тесты с помощью Gatling, в частности, чтобы определить требуемые ему ресурсы (процессор и память) для функционирования на среде оркестрации (например, Kubernetes). Артефактом сборки является Docker-образ. В нашей компании мы не используем Helm. Для деплоя широко применяется Helm, он позволяет описать микросервисную архитектуру для разных окружений. Оба эти инструмента обладают схожими полезными качествами, но реализация и дистрибуция различаются. У нас — собственный инструмент деплоя, который был создан, когда Helm был в версии Classic и не поддерживал разные окружения. А собственный инструмент позволяет вносить в деплой улучшения и адаптировать все под нашу инфраструктуру.

Не слишком ли это дорогое удовольствие для них? — Какие технологии оптимальны для небольших и средних компаний, которые хотят внедрить у себя микросервисы?

Ведь для этого им нужно содержать свое железо и одну или несколько команд для его настройки и поддержки. Все чаще встречаю подтверждения, что небольшим и средним компаниям нецелесообразно поднимать собственную среду оркестрации (например, Kubernetes, Docker Swarm или Apache Mesos). Проще использовать популярные сторонние облачные сервисы (на базе Google Cloud Platform, Amazon Web Services, Microsoft Azure или Oracle Cloud) и правильно выбрать тариф.

Этот инструмент позволяет хранить код и видеть всю информацию о его деплое в одном месте. Мы используем бесплатную версию GitLab и GitLab CI. Я часто говорю Helm и не привожу аналогов. GitLab активными темпами интегрируется с Helm и разными облачными сервисами. У Helm есть свои недостатки, но эти недостатки для всех разные и зависят от масштаба разработки, поэтому можно с него начать, а потом обязательно найдутся необходимые инструменты в дополнение.

Наш инструмент конфигурации и деплоя, о котором я говорил ранее, я бы тоже порекомендовал, но он пока недоступен как open source, хотя работы в этом направлении активно ведутся.

При этом при большом количестве сервисов соблюдение версионности может серьезно замедлить развитие инфраструктуры. Интересно также взглянуть на Spinnaker и Heroku — это разные, но зарекомендовавшие себя решения, которые позволяют быстро задеплоиться на облачные сервисы.
   
— С одной стороны, для обеспечения контроля связей и надежности на уровне, достаточном для промышленной эксплуатации, нужна версионность. Как вы решили эту проблему?

С версионированием мы впервые столкнулись, когда нам потребовалось задеплоить единое тестовое окружение из всех сервисов, а потом в ходе изменения каждого сервиса поддерживать стабильность имеющегося функционала. Разрабатывая микросервисную архитектуру из нескольких сервисов, мы прошли путь от прототипа до промышленной эксплуатации.

Микросервисная архитектура позволяла заменять один сервис другим с другой реализацией или на другом стеке технологий. Мы не хотели плодить версии (а их на этапе прототипа порождается очень много) или внедрять разные сервисы для разъединения контракта.

Мы предложили свой подход к эволюции контракта. При добавлении или удалении сервисов версионирование не помогает. Далее реализовали простой пакетный менеджер и стали использовать этот слепок для деплоя коллекции часто меняющихся сервисов. Наиболее часто меняющиеся сервисы мы объединили в единый слепок версий, он же пакет (package).

Нам пришлось перестроить непрерывный деплой, но от этого стало только легче. Версиями сервисов (не контрактов) являются тэги Docker-образов, которые в свою очередь равны хэш коммитам или тэгам в Git. В общем, мы смогли на этапе прототипа отказаться от привычного версионирования контракта и значительно ускорили разработку. Я подробно рассказывал об этом в докладе, а динамику деплоя можно посмотреть на слайдах.

И то: мы добавили его только в публичный API. Версионирование контракта мы добавили в сервисы за месяц до выхода в промышленную эксплуатацию, когда нам потребовалось интегрироваться с внешними клиентами. При этом мы продолжаем заниматься активной разработкой: добавляем и удаляем функции. И вот мы уже год находимся в промышленной эксплуатации и за это время подняли всего три минорные версии. Мы знаем, какие методы API используют внешние клиенты, а какие — мы. У нас есть клиентские сервисы, которые используют наш публичный API. Если изменения касаются только наших методов, то в большинстве случаев мы не поднимаем версию API, изменяем только слепок версий и не делаем необратимых изменений на коротких промежутках времени.

Если бы мы их оставили, нам пришлось бы покрывать тестами каждую версию; просить внешних клиентов переходить на новую версию публичного API, хотя большинство изменений их не касаются; следить за тем, не используется ли старая версия, и удалять ее из кода. Таким образом мы смогли отказаться от множества версий контракта.

 Можно ли сказать, что они становятся аналогом ядра приложения? Знаю, что вы используете подход, при котором часть микросервисов выделяете в отдельные группы.

Если смотреть на это как на многослойную микросервисную архитектуру, где есть слои с сервисами для высокоуровневого API, интеграционные сервисы и небольшие атомарные сервисы, то ядром в этом случае являются как раз эти низкоуровневые атомарные сервисы. Ядро — это что-то внутреннее. В отдельную группу выделяем часто меняющиеся сервисы на разных слоях микросервисной архитектуры. У нас другое разделение.

Для деплоя отдельной группы создали отдельный репозиторий, где хранятся конфигурации деплоя, имеется свой менеджер пакетов для слепка версий и выстроен непрерывный деплой на разные окружения. Сервисы, которые меняются редко, имеют собственный независимый процесс непрерывного деплоя. При этом непрерывная интеграция, которая является базовой частью непрерывного деплоя, распределена по репозиториям часто меняющихся сервисов.

Давай возьмем 2ГИС. — Всегда интересно узнать не только про подходы и технологии, но и про личный опыт компаний. Что доделывается сейчас? Скажи, процесс перехода на микросервисы занял много времени?

Вначале мы провели исследование. Переход начался более трех лет назад. Выбор пал на Deis и у нас есть доклад на эту тему, а также доклад о поддержке Deis в течение полутора лет. Попробовали Mesosphere, OpenShift и другие доступные на тот момент PaaS и IaaS решения. У него была хорошая документация и грамотная архитектура. Это open source аналог Heroku, он позволял доставлять свой сервис как Heroku Buildpack’ом, Dockerfile’ом или подготовленным Docker-образом. Это была первая реализация для непрерывного деплоя. Мы написали семейство make файлов как универсальный набор команд поверх командной консоли для деплоя в Deis.

У него была обратная совместимости с Deis, но в качестве среды оркестрации уже использовался Kubernetes. Далее компания перешла на Deis2. Те, кто переходили на микросервисные архитектуры, в большинстве случаев выбирали Deis2, но были и те, кто выбирал низкоуровневый путь — прямую работу с Kubernetes. Команда Infrastructure & Operations, которая занималась поднятием этих платформ и их дальнейшим обслуживанием, разработала свой инструмент по деплою в Kubernetes и Deis2. Deis2 обладал рядом недостатков: не было возможности зайти в запущенный контейнер, pod мог состоять только из одного контейнера и для каждого pod’а создавался свой namespace. Вторые оказались правы. Kubernetes был лишен этих недостатков. Это не давало гибкости и осложняло работу команде Infrastructure & Operations. Этим летом запланирован полный отказ от Deis2 в пользу Kubernetes. В итоге приняли решение перенести все сервисы из Deis2 в Kubernetes.

Какие интересные идеи уже невозможно применить? — Скажи, если бы ты стал сейчас переписывать все под микросервисную архитектуру, уже имея такой  опыт за плечами, что бы ты изменил в реализации?

У него очень большая документация, и ее тяжело прочитать за короткий промежуток времени. Я бы сразу почитал про Helm. Но Helm хорошо выстраивает понимание практики деплоя микросервисной архитектуры.

Helm сразу наталкивает на мысль, что микросервисная архитектура — это коллекция сервисов: они хоть и слабо связаны друг с другом, но деплоятся вместе.

В Helm есть зависимость chart’ов и можно описать корневой chart, который бы описывал сервисы и связывал их по параметрам, присущим определенному окружению.

У нас было больше десяти сервисов (на тестовых окружениях для каждой задачи мы поднимали дополнительно свои backing сервисы: Postgres, Kafka, Zookeeper, Ceph). Разработанный в 2ГИС инструмент деплоя позволяет объединять деплой сразу нескольких сервисов, но отлично подходит для коллекции из не более 10 сервисов. Я понял, что нужен язык программирования. В какой-то момент я понял, что yaml-программирование не раскрывает всего потенциала, с ним неудобно работать в IDE, алиасы и якоря не покрывают всей вложенности. Описал абстрактную фабрику, которая бы порождала семейство описаний сервисов. Выбрал Python, потому что на нем был написан инструмент деплоя и Python точно есть в контейнере с этим инструментом. Например, параметры доступа к третьим сервисам. Это позволило добавить описания для абстракций, которые мы не деплоим. Появилась возможность вкладывать одни описания в другие и переиспользовать описания. Они были все так же представлены классами, как и описания наших сервисов, и все так же порождались абстрактной фабрикой. Я понял, что я ушел дальше, чем Helm, и мне интересны решения по описанию ресурсов Kubernetes на каком-либо языке программирования, а не на yaml. Можно наследовать окружения, например, нагрузочное от стейджинга, так как хотелось иметь актуальное одинаковое описание ресурсов (процессор и память) для обоих окружений.

Но текущая реализация вполне справляется с поставленной задачей, а лучшее — враг хорошего. Еще бы сделал публичный API раздробленным на несколько сервисов и внедрил бы API Gateway.

Микросервисная архитектура принесла нам гораздо больше плюсов, чем сложностей, которые мы успешно смогли победить.
Но что бы я точно не стал менять, так это результат выбора: монолит или микросервисная архитектура.

Присоединяйтесь к DevOpsConf Russia. Принципы DevOps плотно проникли в жизнь разработчиков, пора собраться на большой профессиональной конференции для обмена опытом.

Мы собираемся обсуждать DevOps как единое целое из всех процессов разработки, тестирования и эксплуатации. DevOpsConf Russia состоится 1 и 2 октября в  Москве и будет логически продолжать серию RootConf, название которой, однако, перестало отражать то, что мы делаем.

Программный комитет ждет ваши заявки до 15 августа. Если в вашей компании DevOps набирает обороты, или же трансформация еще только начата, но уже есть определенные успехи – приходите поделиться ими с сообществом.

Теги
Показать больше

Похожие статьи

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *

Кнопка «Наверх»
Закрыть