Вот моя история:

  • Работал в стартапе. Есть один технический основатель.
  • У них был работающий и работающий Rails Monolith.
  • Меня пригласили реализовать стороннюю интеграцию, которая принимает удаленные каналы и запись ETL в базу данных. (Пилотное требование)
  • Пилот - успех! Разблокировано больше средств! Технический основатель начинает читать последние технические модные слова.

AWS / Docker / микросервисы

«Пилот удался. Нам нужно быстро нанять сотрудников и увеличить количество развертываний в 10 раз в этом году! »

«Я смогу запустить удаленную команду». (К его чести, он это сделал)

«Мы должны изменить следующее, чтобы удовлетворить спрос»

  • Перейдите с Rackspace на AWS.
  • Перейдите с Rails на Express.
  • Переход с MongoDb на Mysql.
  • Разбить серверную часть на микросервисы.
  • Перепишите фронтенд с Rails на React.
  • Перепишите развертывание с Nginx + Passenger на Docker.
  • Не только Node.JS, используйте es6 с babel.

Вы и какая армия?

На данный момент у нас есть 3 инженера (считая ваших покорных) в районе залива. И команда из 5 удаленных:

  • 1 технический руководитель.
  • 2 Фронтенд.
  • 2 бэкэнд.

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

После нескольких месяцев обсуждений команда CTO + удаленная команда решила, что версия 2 платформы возможна только в том случае, если мы разделим серверную часть на 10 микросервисов…

Совет №1: количество микросервисов должно быть меньше, чем количество разработчиков.

Традиционные монолитные приложения помещают каждый из микросервисов в свои собственные модули. У вас будет один репозиторий git. Каждый разработчик будет проверять один и тот же репозиторий и пытаться создавать и запускать что-то локально. Если бы был коммит git, который нарушал репо, все бы вскочили и попытались это исправить.

У нас 6 инженеров и 12 репозиториев (вы должны поддерживать существующий конвейер до завершения миграции).

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

Новые ошибки могут возникать в 12 местах вместо 2! Замечательно!

Совет №2: методы обслуживания теперь требуют разработки и проверки REST api.

В большинстве серверных фреймворков у вас есть контроллеры / сервисы / помощники / модели.

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

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

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

Надеюсь, вам понравятся ненужные сетевые обходы!

Совет №3: переключение контекста - вещь очень дорогая.

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

Команда ops попросила, чтобы мы запускали что-то внутри kubernetes, чтобы воспользоваться преимуществами нескольких пространств имен и размещенных секретов.

Сравните набор инструментов до / после пилота:

  • Рубин на рельсах
  • Mongodb
  • Конфигурация Nginx + Passenger
  • Node.JS работает на pm2
  • Ssh на выделенный сервер, базовый bash
  • Шаблоны Erb html

К новой горячности:

  • Докер
  • выражать
  • Redis
  • MySQL
  • Kubernetes (в основном kubectl)
  • Чванство
  • Реагировать
  • Вавилон 6/7

В процесс повседневного развития теперь входят:

  • Запуск сценария для обновления 10–15 репозиториев git и сборки всех из них.
  • Запуск другого сценария для запуска 7–10 микросервисов на разных портах.
  • Разработайте свою функцию, перепроверьте с другими товарищами по команде, чтобы убедиться, что вы используете последнее определение api swagger.
  • PR, объедините его и дождитесь публикации npm и сборки докеров.
  • Проверьте среду poc с помощью браузера и kubectl.
  • Узнайте, что что-то не работает, прочтите последние обновления из 5–10 других репозиториев, написанных в совершенно других стилях.
  • Работайте сверхурочно и мечтайте об идеальном мире, в котором все программируют одинаково (когда на самом деле один вводит новые проблемы быстрее, чем команда может воспринять изменения в рамках этой парадигмы).

Что следовало сделать вместо этого:

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

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

Silver Bullet: монорепозиторий

Monorepos может свести к минимуму вашу ежедневную проверку git и сборку / запуск пряжи. Просто создайте интерфейсную и внутреннюю папки внутри одного репозитория git и при необходимости поделитесь кодом между ними с символическими ссылками.

У инженеров разные скорости и стиль.

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

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

Пока у вас не будет как минимум 3 команды из 5 инженеров, нет смысла разбивать серверный проект на несколько папок.

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

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

Что, если у меня теперь 3 команды по 5 инженеров?

Поздравляю! У вас, вероятно, неплохо получается, что вы так много тратите на инженерное дело.

В этих случаях есть несколько способов уменьшить сложность:

  • Разделить на несколько папок в монорепо.
  • Работайте с бизнес-командой, чтобы придумывать новые продукты, назначьте команду для нового продукта, который полностью независим от текущего продукта.
  • У вас уже есть репозиторий интерфейса iOS / Android?
  • Охватывается ли автоматизация QA?
  • Продвигайте опытных инженеров, чтобы они помогали контролировать стиль программирования и сражаться в бесконечной битве сложности.

Помните: если вы должны пойти по этому пути, количество микросервисов должно быть меньше, чем количество инженеров!

Если вы хотите обсудить больше, напишите нам на [email protected] или оставьте нам комментарий!

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