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

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

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

Мотивация

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

Переход к сервис-ориентированной архитектуре (SOA) является сложной задачей. Компании принимают SOA, потому что она обещает обеспечить «быстрые итерации», но сама по себе архитектура не приведет вас к этому.

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

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

Это мой многословный способ сказать: «SOA - это сложно… очень сложно, и вам нужна вся помощь, чтобы сделать это должным образом». Вот здесь-то и пригодится шаблонный шаблон. Boilerplate - отличное средство, которое поможет облегчить смену парадигмы, которая потребуется для масштабирования экосистемы услуг.

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

Служба шаблонов

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

  • Вся инфраструктура, необходимая для запуска сервиса в производство.
  • Сценарии, помогающие разработчикам запускать тесты, создавать документацию, развертывать свои службы и создавать среды персональных разработчиков.
  • Полный конвейер CI / CD (например, линтинг, тестирование, развертывание, уведомления Slack и т. Д.).

Вот примерная структура каталогов, которая поможет вам лучше понять:

boilerplate-service/
    infrastructure/
        config/
            ...
        template.yml
    docs/
        index.md
        ...
    scripts/
        setup.sh
        ...
    src/
        ...
    tests/
    README.md
    Dockerfile
    Jenkinsfile
    ...

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

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

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

  • Использование передовых методов (настройка маршрутизации, аварийные сигналы ЦП и памяти и т. Д.) Помогает повысить компетентность вашей экосистемы услуг.
  • Включение инструментов разработчика помогает улучшить опыт разработки на местном уровне и повысить производительность труда разработчиков.

Давайте копнем немного глубже и посмотрим, как наш шаблонный сервис помогает нам в переходе к SOA.

Изгнание

Первое, что нужно сделать командам при запуске новой службы, - это извлечь из стандартного шаблона службы. Такие инструменты, как create-react-app и gradle-init, имеют плавный процесс извлечения самообслуживания. Вы предоставляете название проекта, некоторую информацию о версиях, и он генерирует соответствующий шаблонный код.

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

  1. Клонируйте наш boilerplate-service репозиторий.
  2. Обновите ссылки на boilerplate-service на название своей службы.
  3. Настройте интеграцию с информацией о своей команде (например, Slack, электронная почта).

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

Причина №1: операционные проблемы

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

Что это значило для команд:

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

Что это значило для организации:

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

Причина № 2: Проверка

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

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

Когда наша экосистема услуг созрела и мы превзошли порог операционной компетентности, мы сделали наш шаблонный отказ от услуг столь же простым, как eject <service_name>.

Бурлящее изменение

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

  • Должны ли локальные сервисы подключаться к сервисам в среде песочницы?
  • Должны ли все службы предоставлять клиентскую библиотеку в памяти для использования другими службами во время тестирования / локальной разработки?
  • Должны ли мы запускать все необходимые службы локально?
  • И т.п.

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

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

Услуга состоит из трех «компонентов»:

  1. Код / файлы, за которые несет ответственность владелец сервиса. Любые внесенные нами изменения не коснутся этих файлов (например, таких вещей, как код приложения, файлы инфраструктуры, документация и т. Д.).
  2. Разработчики локальных инструментов разработки используют для взаимодействия с сервисами и экосистемой сервисов.
  3. Инструментальные и инструментальные услуги, используемые в производстве.

Библиотека строительных лесов

Библиотека строительных лесов обращается к пункту 2. Это зависимость для всех наших сервисов. Он отвечает за все / все, что помогает в развитии вашего сервиса:

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

Как мы используем библиотеку scaffolding для распространения изменений (и другие вещи, которые нам в ней нравятся):

  • Когда мы вносим изменения, мы выпускаем новую версию библиотеки строительных лесов, и владельцы сервисов просто должны обновиться до последней версии.
  • Разработчики могут очень быстро приступить к работе с незнакомой службой, поскольку инструменты, необходимые для взаимодействия со службой, одинаковы.
  • Используя команды, предоставляемые библиотекой шаблонов, мы можем написать один конвейер CI / CD, который будет работать для каждой службы.

Библиотека времени исполнения

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

  • «Инфраструктурное» приложение Django, которое помогает с такими вещами, как проверки работоспособности.
  • Утилиты ведения журналов, которые помогут нам пометить журналы и включить распределенную трассировку.
  • Вспомогательные функции для связи с различными системами в нашей организации.

Примечания

  • Я бы солгал, если бы сказал, что эта система была задумана дизайнером. Отчасти это была интуиция, но по большей части метод проб и ошибок.
  • Мы можем пользоваться преимуществами наших строительных библиотек / библиотек времени выполнения только потому, что мы придерживаемся дисциплинированного подхода к обновлениям. Мы избегаем внесения критических изменений и следим за тем, чтобы владельцы служб были в курсе последних версий библиотеки.
  • Наличие системы, которая обеспечивает быстрое и легкое распространение изменений, позволяет нам использовать в своих интересах таланты, имеющиеся в нашей организации. Мы проводим еженедельные встречи с владельцами наших сервисов, чтобы получить отзывы о наших предложениях SOA. Когда владельцы сервисов обнаруживают пробел в своем сервисе, они сообщают нам свое решение, и мы обобщаем его, прежде чем внедрять его во все сервисы. На первый взгляд небольшие изменения могут иметь большое влияние на нашу организацию.

Резюме

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

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

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

  • Весь код, генерируемый вашим шаблоном, должен быть актуальным. Если он нерелевантен, его следует абстрагировать или структурировать так, чтобы разработчик никогда к нему не прикасался. С другой стороны, если это актуально, оно должно быть явным и присутствовать, даже если его можно абстрагировать.
  • Мы начали с сложного процесса выброса. У нас это сработало, но, очевидно, не во всех случаях. Предположим, мы предлагаем шаблонную лямбду вместо стандартной службы. Даже если бы наша шаблонная лямбда-выражение была забита инструментами, задействованный процесс извлечения не был бы хорошей идеей, поскольку лямбда-выражения обычно обслуживают специальные сценарии использования.
  • Я полагаю, что это более философский вопрос: точно так же, как коммуникативные структуры, которые работают для стартапов, не работают для крупных компаний, методы, которые работают для монолитной разработки (несколько баз кода), не работают для SOA (многие базы кода). В этих случаях нам нужна новая структура, которая поможет справиться с масштабом. Шаблон помогает нам создать эту структуру.