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

Мой опыт

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

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

Дело не в монолите или микросервисах

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

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

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

Что я рекомендую?

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

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

Теперь, если монолиты и/или архитектура микросервисов могут помочь вам решить эту проблему, учитывая ограничения вашей организации, используйте их. Вы не Google, Facebook, Microsoft, Amazon, а они не вы. Вам даже не нужно сразу сравнивать себя с другими организациями, которые могут быть более умными, гибкими или иметь какие-либо из этих характеристик.

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

• Время восстановить сервис
• Изменить частоту отказов
• Время выполнения изменений
• Частота развертывания.

Мое заключительное замечание состоит в том, чтобы сосредоточиться на том, что заставляет вас эффективно поставлять свое программное обеспечение (стоимость, операции и все, что включено). Все остальное похоже на дебаты в 21:00 в новостях.