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

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

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

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

Learning Rate - это мой еженедельный информационный бюллетень для тех, кто интересуется миром AI и MLOps. Каждую пятницу вы будете получать от меня обновления и мысли о последних новостях, исследованиях, репозиториях и книгах в области искусственного интеллекта. Подпишитесь здесь!

Соображения по дизайну

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

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

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

Собираем функциональные требования

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

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

Перечислите доступные ресурсы

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

  • Какие инженерные ресурсы есть в нашем распоряжении? Какие инструменты используют разработчики и какой язык программирования является основным продуктом их работы?
  • Сколько денег вы готовы потратить, чтобы это произошло? Другими словами, каков бюджет?
  • Когда крайний срок? У вас есть время или нужно срочно выйти на рынок?

Монолиты Vs. Микросервисы

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

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

Каждая архитектура разделена на 3 основных уровня:

  • Пользовательский интерфейс (пользовательский интерфейс): пользовательский интерфейс обычно отвечает на HTTP-запросы и предоставляет графический интерфейс, который упрощает взаимодействие с пользователем.
  • Бизнес-логика: уровень бизнес-логики содержит код, который контролирует все и предоставляет услуги пользователям.
  • Уровень данных: уровень данных обеспечивает доступ к информации, необходимой приложению, и хранилище для состояния приложения.

Монолиты

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

Микросервисы

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

Выбор между микросервисами и монолитными

Как мы можем выбирать между этими подходами? В конце концов, микросервисы - это новый тренд, и кажется, что мы всегда будем в выигрыше, если выберем этот подход? Помните упражнение, которое мы проделали в разделе «Рекомендации по дизайну»? Давайте проверим это.

Итак, когда бы вы выбрали монолит? Представьте, что у вас строгий бюджет, а ваша команда инженеров состоит из нескольких разработчиков, которые свободно владеют определенной структурой, например средой Java Spring. Более того, сроки поджимают, и вам нужно что-то построить в сжатые сроки.

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

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

Заключение

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

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

об авторе

Меня зовут Димитрис Поулопулос, я инженер по машинному обучению, работающий в Arrikto. Я разработал и внедрил AI и программные решения для крупных клиентов, таких как Европейская комиссия, Евростат, МВФ, Европейский центральный банк, ОЭСР и IKEA.

Если вы хотите прочитать больше сообщений о машинном обучении, глубоком обучении, науке о данных и DataOps, подпишитесь на меня в Medium, LinkedIn или @ james2pl в Twitter.

Выраженные мной мнения являются исключительно моими и не отражают взгляды или мнения моего работодателя.