Что выбрать для дипломного проекта — монолит или микросервисы?

Question

[Никита]

Здравствуйте!

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

Не могу определиться с архитектурой приложения: монолит или микросервисы? С одной стороны, монолитная архитектура позволит быстро создать приложение, с другой – популярность сейчас имеет микросервисная архитектура. Если сделать на микросервисах, то я тогда смогу изучить что-то новенькое для себя. К тому же будет что показать в портфолио.

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

Тогда встаёт вопрос: стоит ли для портфолио и в качестве дипломного проета делать веб-приложение, основанное на микросервисной архитектуры? Или это будет слишком сложно для одного человека, а для его портфолио вполне себе сойдёт монолит?

Проект планирую выложить в Github.
Планирую использовать стек:
Монолит: Python / Django
Микросервисы: Python / Flask или GoLang. Транспортные протоколы пока не выбирал.

Comments

[d'Ivan]

Прочел статью лишь после того как написал ответ. Она подтверждает мои слова.

[Толстый Лорри]

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

[Никита]

Всем спасибо за ответы! Пожалуй, поступлю именно как описывает Роман Мирр: начну с простой архитектуры – монолита, а уже потом начну выявлять на нём узкие места по необходимости и писать микросервисы под них.

Толстый Лорри, тема дипломной будет прикладной, т.е. решать некоторые проблемы с текущим инструментом. Будет крутой инструмент, решающий проблемы прикладного характера. Как раз этот инструмент и будет распределённым. Вопрос был в том, стоит ли мне тогда всё приложение распределённым делать.

Answer 1

[d'Ivan]

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

Comments

[profesor08]

Я бы добавил, что для дипломки не надо пилить тучу микросервисов, достаточно сделать пару, чтоб было просто и наглядно.

Answer 2

[Immortal_pony]

Если сервис разрабатывает команда из 30+ человек, то тогда имеет смысл подумать о том чтобы разделить его на микросервисы.
Это не ваш случай, спокойно пишите монолит.

Answer 3

[Amffore]

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

Answer 4

[Иван Шумов]

Я не соглашусь с Immortal_pony. Монолит проще, несомненно, особенно если с нуля, но всегда есть популярный ныне Serverless (AWS/Azure/GCP). Все зависит от сложности приложения, которое вы собираетесь делать.

Comments

[Immortal_pony]

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

[Иван Шумов]

Immortal_pony, вообще-то все зависит от приложения. Порой сделать простую api и клиент на js гораздо проще. Как правило технологий изучать надо даже меньше. Ну и сразу хорошие и правильный подходы

[Immortal_pony]

API и клиент - это не микросервисы.

[Иван Шумов]

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

[d'Ivan]

Иван Шумов, и какие "сервисы" тогда должен в таком случае предоставлять клиент на js?

[Immortal_pony]

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

[Иван Шумов]

Роман Мирр, клиент на js просто должен отражать функционал. Это всего лишь мордочка

[Иван Шумов]

Immortal_pony, микро означает размер, но нет такое единицы измерения, которая это описывает. Микросервисом может быть любое количество функционала, изолированное логически. А на счет "Ы" ... может быть микросервиС) один и все.Это самое начало.

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

[Immortal_pony]

А чем тогда этот "микросервис" отличается от монолита?

[Иван Шумов]

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