Почему культура команды важна для успешных микросервисов

1656556350 pochemu kultura komandy vazhna dlya uspeshnyh mikroservisov

автор Джейк Люметта

ZE3M6JY77nGOiL8eiTu4UKB5Y0eLC3nAyFEK
Фото от rawpixel на Unsplash

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

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

Правило №1: Вы не можете создать успешные микросервисы без успешной командной культуры.

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

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

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

Эта дилемма, а также многие другие подобные, заставили техники задавать себе такие вопросы как: сколько свободы я должен дать своей команде, когда дело доходит до внедрения новых технологий? И, может быть, еще важнее, как я могу управлять общей культурой в своем лагере?

Дайте каждому члену команды шанс процветать

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

Проблема заключалась в том, что наша команда была разделена на два лагеря: ребята с Java и ребята с JavaScript. Проходило время, появлялись новые и увлекательные проекты, и мы всегда обращались к Java, чтобы выполнить работу. Вскоре в лагере JavaScript возникло некоторое раздражение, которое подкралось.

Почему ребята из Java всегда берутся за работу над новыми увлекательными проектами, а нам остается выполнять повседневные задачи, такие как внедрение инструментов аналитики сторонних разработчиков? Мы также хотим работать над большим, увлекательным проектом!»

Как и большинство разрывов, это было небольшим, но со временем становилось хуже.

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

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

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

Выбор технологий: стабильность против гибкости

Одна из самых больших проблем, с которой приходится бороться техническим директорам и разработчикам, — это то, сколько технологической свободы позволяет разработчикам.

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

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

Правильный ответ зависит от многих различных факторов, а это значит, что правильного ответа нет.

Технологическая свобода

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

«Мы даем нашей команде и себе 100% свободы в выборе технологий. В конце концов, мы определили две или три технологии, которые в конце концов не будем использовать, прежде всего из-за того, что не хотим усложнять нашу историю развертывания», — сказал Бенджамин Кертис, соучредитель Honeybadger.

«Иными словами, мы рассматривали возможность внедрения новых языков и новых подходов к нашему технологическому стеку, создавая наши микросервисы, и фактически мы в один момент разворачивали производственный микросервис на другом стеке. [While we do generally] следуя технологиям, которые мы знаем, чтобы просто стек операций, мы периодически пересматриваем это решение, чтобы увидеть, можно ли получить потенциальные преимущества в производительности или надежности, введя новую технологию, но пока мы не вносили изменений», — продолжил Кертис. .

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

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

Высокая свобода, высокая ответственность

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

Во время интервью с техническим директором Sumo Logic Кристианом Бидженом и главным архитектором Стефаном Зиером они расширили эту тему. Они добавили значение к позиции, что если вы собираетесь дать разработчикам свободу выбора технологии, это должно сопровождаться высоким уровнем ответственности.

«Это действительно важно [whoever builds] программное обеспечение полностью владеет им. Другими словами, они не только создают программное обеспечение, но запускают программное обеспечение и остаются ответственными за весь жизненный цикл», – сказали они.

Они продолжили, объясняя, что система, напоминающая систему федерального правительства, должна быть введена, чтобы помочь держать эти свободы под контролем путем ужесточения ответственности.

“[You need] действительно федеральная культура. У вас должна быть система, где несколько независимых команд могут объединиться для достижения большей цели. Это в определенной степени ограничивает независимость подразделений, поскольку они должны согласиться с тем, что потенциально существует некое федеральное правительство. Но в этих группах они могут самостоятельно принимать сколько угодно решений в рамках руководящих принципов, установленных на высшем уровне», – сказал он.

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

Но не все согласны.

Ограничьте технологию, чтобы упростить вещи

Кроме того, Дарби Фрей, соучредитель Lead Honestly, использует более ограничительный подход к выбору технологий.

«В моей последней компании у нас было много сервисов и довольно небольшая команда, и одной из главных вещей, благодаря которой она работала, особенно учитывая размер команды, которая была у нас, было то, что каждое приложение было одинаковым. Каждый серверный сервис был приложением Ruby», – объяснил он.

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

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

«Наличие полиглотовой архитектуры может увеличить затраты на разработку и обслуживание. Если все равно, вы можете сосредоточиться на ценностях бизнеса и бизнес-функциях, а не быть слишком ограниченным в том, как работают ваши услуги. Я не думаю, что всем нравится такое решение, но в конце дня, когда им приходится что-то исправлять по выходным или посреди ночи, они это ценят», – сказал Фрей.

Централизованная или децентрализованная организация

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

К примеру, инженеры программного обеспечения обычно пишут код, прежде чем отправить его в операционную группу, которая, в свою очередь, разворачивает его на серверах. Но когда что-то ломается (а вещи всегда ломаются!) возникает внутренний конфликт.

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

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

Децентрализованный = высокая ответственность

Один из способов решить эту проблему — следовать примеру Netflix и Amazon, выступающих за децентрализованное управление. Джеймс Льюис и Мартин Фаулер, два лидера разработки программного обеспечения, изложили свои мысли в длинном блоге. По их мнению, децентрализованное управление — это путь, когда речь идет об организации команды микросервисов.

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

«Возможно, апогеем децентрализованного управления является принцип «строй, управляй», популяризированный Amazon. Команды несут ответственность за все аспекты создаваемого ими программного обеспечения, включая эксплуатацию программного обеспечения 24/7», – продолжает он.

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

«Эти идеи настолько далеки от традиционной модели централизованного управления, насколько это возможно», — заключают они.

Кто переходит на страницу по выходным?

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

Это одна из причин, почему Дарби Фрей, соучредитель Lead Honestly, не является сторонником концепции децентрализованного управления.

«Образец «одна команда отвечает за определенную службу» – это то, что вы часто видите в архитектурах микросервисов. Мы этого не делаем по нескольким причинам. Основная причина бизнеса состоит в том, что мы хотим, чтобы команды отвечали не за конкретный код, а за функции, ориентированные на клиента. Команда может нести ответственность за обработку заказов, поэтому это коснется нескольких баз кода, но конечный результат для бизнеса состоит в том, что есть одна команда, которая владеет всем делом от конца до конца, поэтому меньше трещин, которые могут провалиться», — Фрей объяснил.

Другая основная причина, продолжил он, состоит в том, что разработчики могут взять на себя большее право собственности на общий проект:

«Они действительно могут думать [the project] целостно», – сказал Фрей.

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

Должна ли децентрализация привести к отделению и силоизации?

Далее Пек объясняет, что его решение заключается в DevOps, модели, направленной на усиление обратной связи путём сближения этих двух команд. Это укрепляет командную культуру и коммуникацию в процессе. Пек описывает это как подход «ты строишь, ты запускаешь».

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

Одним из самых мощных подходов к децентрализованному управлению является формирование мышления DevOps, — написал Пек. “[With this approach], инженеры участвуют во всех частях конвейера программного обеспечения: написании кода, его построении, развертывании полученного продукта, эксплуатации и мониторинге его при производстве. Способ DevOps контрастирует со старой моделью отделения команд разработчиков от операционных команд, когда команды разработчиков пересылают код через стену операционным командам, которые затем отвечали за его запуск и поддержку».

DevOps, как объяснил технический директор Armory Айзек Москера, является гибким фреймворком и культурой разработки программного обеспечения, которые набирают популярность благодаря – ну, почти всему, что сказал Пек.

Интересно, что Москера считает, что этот подход действительно противоречит закону Конвея:

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

«Вместо того чтобы коммуникация руководила разработкой программного обеспечения, теперь коммуникация движет архитектура программного обеспечения. Команды не только работают и организуются по-разному, но для поддержки этого типа архитектуры нужен новый набор инструментов и процессов, то есть DevOps», – объяснил Москера.

Крис Макфадден, вице-президент по инженерии SparkPost, имеет интересный пример, которому следует подражать. В SparkPost вы найдете децентрализованное управление, но вы не найдете культуру одной команды на услугу.

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

Такой подход, объяснил Макфадден, позволяет любой команде работать над чем угодно, от новых функций до устранения ошибок и проблем производства, связанных с любым из этих сервисов. Есть полная упругость, а не силоса.

«Это позволяет [the teams to be] немного гибче как с точки зрения разработки новых продуктов, так и только потому, что вы не слишком ограничены, и это зависит от нашего размера как компании и команды инженеров. Нам действительно нужно сохранять определенную гибкость», – продолжил он.

Однако здесь может иметь значение размер, поскольку Макфадден признал, что если бы SparkPost был гораздо больше, «тогда было бы целесообразнее иметь одну из этих микросервисов большую команду».

“[It’s] Я думаю, лучше иметь немного более широкую ответственность за эти услуги, и это дает вам немного больше гибкости. По крайней мере, это работает для нас сейчас, где мы как организация», – сказал он.

Успешный микросервис, инженерная культура – ​​это балансировка

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

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

Вот краткий результат того, как обеспечить надлежащее сочетание культуры вашей команды с архитектурой микросервисов:

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

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

И если вы хотите добавить блог или CMS на свой веб-сайт, не возиться с WordPress, вам следует попробовать Butter CMS. ButterCMS – это CMS без головы, которая позволяет создавать программы на основе CMS с помощью любого языка программирования, включая Ruby, Rails, Node.js, Python, ASP.NET, Flask, Django, Go, PHP, Laravel, Angular, React , Elixir, Phoenix, Meteor, Vue.js и Gatsby.js

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

Ваш адрес email не будет опубликован.