В этой рубрике я объясняю термины и процессы, которые общепринятые в IT-сфере, на простых примерах
Представьте, что у нас есть завод по производству автомобилей. Это маленький завод, который выпускает несколько моделей в год. Работники завода на все руки мастера и могут делать всё, что требуется. Так в нашем цехе производят полный цикл сборки автомобиля и самостоятельно делают все детали: от шин и двигателя, до обивки сиденья.
И вот владелец завода хочет увеличить количество выпускаемых автомобилей, чтобы обработать выросший спрос на них. Для начала мы можем модернизировать производство: улучшить станки и процессы, но мы всё же упрёмся в потолок ресурсов. Тогда нам нужно будет масштабировать предприятие и открывать второй такой же завод.
Но что, если внутри одного завода мы производим колёс больше, чем нужно для выпуска автомобилей на этом заводе? И нам бы не нужно было выпускать колёса на втором нашем заводе. Но мы не можем такое сделать, ведь весь процесс отлажен именно под такое взаимодействие. Получается мы недоиспользуем наш ресурс. Ещё при таком процессе, мы не можем отдать производство колёс в другую фирму, а сами сосредоточиться на сборке и производству более важных частей.
К счастью, эта проблема уже решена и используется на всех больших заводах. Нужно просто разделить ответственность по выпуску деталей и сборки автомобиля по разным цехам или даже компаниям. При таком подходе мы можем сосредоточиться только на главном, например, сборке и производству важных деталей, а колёса, магнитолу и т.п. пусть для нас делают наши партнёры, которые лучше в этом разбираются.
Такой же подход используется и в IT. Мы можем хранить весь код в одном месте и при запросе от пользователя наш "завод" будет самостоятельно выдавать ответ. Такой подход называется монолитная архитектура.
Плюсы подхода монолит ("делаем всё в одном месте"):
- Хорошо на первых этапах
- Виден весь процесс
- Не зависим от других, если что-то сломалось, можем быстро починить
- Работники обладают знанием о всей системе (если у нас небольшой продукт)
Минусы
- Сложно масштабировать
Если мы разбиваем работу на несколько заводов, в IT мы их называем сервисами, которые выполняют какую-то "одну" функцию, то такой подход в IT называется микросервисная архитектура.
Плюсы микросервисного подхода ("делим ответственность"):
- Легко масштабировать
- Правильное распределение ресурсов
Минусы:
- Дополнительные затраты на транспортировку
- Сложнее поддерживать
- Надёжность цепочки зависит от надёжности её самого слабого компонента
Все плюсы и минусы данных подходов сложно перечесть в одной статье, но теперь у вас есть инструмент с помощью которого вы можете дальше исследовать подходы.
Попробуйте подумать, какие подводные камни ещё может скрывать подход "всё в одном месте" или какие плюсы есть у микросервисной архитектуры? Напишите свои рассуждения или вопросы в комментариях.