Reasons to Build Monolithic Systems
И да, я имею в виду нарочно.
Рекомендовать монолитную архитектуру в наши дни звучит как кровотечение при лихорадке, но дослушайте меня. В долгосрочной перспективе для обеспечения масштабируемости, удобства обслуживания, гибкости и всех других положительных моментов (включая здравомыслие) вы, вероятно, захотите разработать и развернуть свое приложение на архитектуре микросервисов. Но если вы создаете новое приложение, ваша компания и ваша команда разработчиков могут быть еще не готовы к иронической сложности, связанной с разделением системы на простые сервисы. Скорость и время выхода на рынок могут превзойти элегантность … и это нормально!
Первая причина построить монолитную систему — помочь приручить неизвестные. Возьмите любую книгу или статью о начале работы с микросервисами, и в ней будет описан процесс разбиения системы на компоненты. Но если вы только начинаете, у вас еще нет системы, которая сломалась бы. Может быть довольно сложно просто выяснить, какие требования вам нужны в системе, тем более попытаться разложить эти требования на набор слабо связанных служб с четко определенными интерфейсами. При типичном начале уровня неизвестных вероятность получить этот анализ даже близко к праву очень мала.
Основная предпосылка, лежащая в основе развития методологий гибкого стиля, заключается в том, чтобы позволить требованиям обнаруживаться постепенно, потому что почти невозможно знать все заранее. Точно так же гораздо легче различить службы компонентов системы, когда у вас есть ощутимая версия или две под рукой. Итак, сначала просто начните! Создайте исходную систему, не беспокоясь о том, правильно ли вы это делаете… на данном этапе «правильного» нет. Искусство заключается в том, чтобы найти баланс между продолжением использования функциональности и началом выделения определенных услуг по мере того, как туман рассеивается, в идеале до накопления технического долга. Подходящий с мыслью и намерением, этот постепенный подход к архитектуре будет быстрее и успешнее, чем пытаться все сделать правильно, пока вы ничего не знаете.
Вторая причина для рассмотрения монолитной архитектуры, если команда не готова. Даже если система достаточно четко определена, разбить систему на сервисы компонентов не всегда просто. Стоит ли рисковать разрушить одну огромную Java-процедуру (у каждой системы), которая вышла из-под контроля? При рассмотрении услуги, насколько маленький является достаточно маленьким? В то время как обычная рекомендация — продолжать до тех пор, пока сервис логически не сделает только одну вещь, например, в мире высокоскоростных больших данных слишком малые данные могут иметь серьезные последствия для производительности.
Суть в том, что всегда нужно учитывать компромиссы, и команде нужен правильный набор навыков, чтобы успешно сбалансировать эти решения. Если ваша команда является новичком в микросервисах, имеет смысл инвестировать в обучение, время для изучения команды и, возможно, в набор новых навыков. Поскольку немногие компании могут позволить себе остановить развитие и переподготовку, тем временем команде, вероятно, придется продолжать строить, используя свои традиционные методы. Хотя это потребует некоторой доработки позже, вы все равно, вероятно, получите лучший результат, чем если бы команда вышла вперёд совершенно неподготовленной. Поверьте мне, в неопытных, ранних версиях микросервисов также есть много переделок.
Наконец, монолитная система может быть вашим самым быстрым путем на рынок, и во многих случаях эта скорость важнее, чем совершенная архитектура. Для многих компаний, особенно стартапов, работающих с ограниченным финансированием, доступ к продажам имеет первостепенное значение для выживания. В то время как микросервисы в конечном итоге облегчат жизнь, эта простота сопряжена с авансовыми затратами, которые вам могут понадобиться для достижения большей зрелости. Хорошая архитектура микросервисов элегантно проста, но это не легко, быстро или случайно. Сегодня существует множество отличных, зрелых, масштабных примеров микросервисов, включая Twitter, Amazon, Spotify, LinkedIn, но есть причина, по которой они все начинали как монолитные приложения, а затем развивались. Никогда не позволяйте стремлению к техническому совершенству мешать успеху в бизнесе. Прагматичная архитектура означает, что выбор технологий должен отвечать потребностям бизнеса, а не наоборот.
Хотя само собой разумеется, наличие противоположности каждого из этих сценариев является отличной причиной НЕ строить монолитную архитектуру. Если ваше приложение уже достаточно четко определено, ваша команда хорошо разбирается в микросервисах, и у вашей компании есть время и деньги, чтобы тратить на циклы разработки, то вам обязательно следует инвестировать в архитектуру микросервисов. Долгосрочные преимущества этого пути хорошо известны и хорошо документированы на данный момент. Но если вы еще не там, все в порядке. Признайте свое текущее состояние, спланируйте свой путь и итерируйте с намерением — вы все равно улучшите свою ситуацию, и со временем вы получите архитектуру, достойную технической беседы, готовую идти в ногу со всеми требованиями вашего бизнеса.
Translation: medium
Help us with your claps:)
