Отсекая лишнее: плюсы и минусы использования микросервисов в веб-архитектуре
Микросервисы стали главным направлением в архитектуре веб-приложений и завоевали сердца многих известных экспертов и сторонников. Ведущие компании, такие как Facebook (проект Meta Platforms Inc., деятельность которой в России запрещена), Uber, OZON, VK, Amazon, Netflix, eBay и “Детский мир” с успехом применяют архитектуру микросервисов.
Однако важно понимать, что каждая компания, команда и ситуация могут существенно отличаться друг от друга, и особенно от мировых гигантов индустрии. Подходит ли архитектура микросервисов абсолютно всем, и является ли она действительно революционным новшеством — разбираемся в этом материале.
Суть архитектуры микросервисов
Давайте представим бескрайнюю пустыню, где каждая крупица песка, на первый взгляд незначительная сама по себе, объединяясь с ей подобными, чтобы создать единое целое. В этом и есть суть архитектуры микросервисов — сложной системы, составленной из множества маленьких, специализированных компонентов, каждый из которых выполняет свою узкую задачу, но в совокупности они образуют огромную единую систему.
Подходя к вопросу о выборе архитектуры, стоит понимать, что микросервисы, как и любое другое архитектурное решение, не обходятся без своих недостатков. Проектирование сложных бизнес-процессов является трудоёмкой задачей, согласование работы между службами требует дополнительных усилий, а сложность интеграций выходит на совершенно новый уровень. Автоматизация, являющаяся важной частью микросервисов, требует серьёзных вложений, и в это же время контролировать всю систему становится практически невозможно.
Что это на самом деле?
Микросервисы очень часто преподносятся как универсальное решение для различных проблем в разработке программного обеспечения. В этом контексте очень важно подчеркнуть, что несмотря на свою эффективность, микросервисы не всегда являются единственным оптимальным решением, а всего лишь одним из способов построения архитектуры.
В реальности они действительно предоставляют дополнительный уровень гибкости, однако внедрение этой архитектуры сопряжено с определёнными затратами, как на этапах разработки, так и на этапах обслуживания. И осмысленность инвестиций является здесь ключевым фактором в принятии решений.
Если проект действительно требует дополнительной гибкости, то стоит тщательно взвесить, превышают ли преимущества связанные с ней расходы.
И если это не так, если такой уровень гибкости в действительности не нужен, то следуя за “хайпом” вы рискуете чрезмерно усложнить технологическую платформу и снизить способность вашей команды эффективно управлять задачами.
Так что вопрос не столько в выборе между микросервисами и монолитом, сколько в том, какая архитектура наилучшим образом соответствует конкретным потребностям вашего проекта.
Сила масштабируемости: дилемма микросервисов
Привлекательность микросервисов заключается в их способности независимо выделять ресурсы для каждой функции приложения отдельно, предоставляя беспрецедентный контроль. Вы можете точно определить количество и тип ресурсов, выделяемых для каждой функции.
Но давайте остановимся и подумаем: действительно ли вам необходим такой детальный контроль? Различные функции в вашем приложении действительно сталкиваются с разными уровнями нагрузки или масштабируются по-разному? Требуют ли они различных ресурсов, таких как процессор, память, хранилище или графический ускоритель (GPU)?
Прежде чем уходить с головой в архитектуру микросервисов, стоит рассмотреть возможность устранения проблем с производительностью и узких мест в вашей монолитной системе. Скорее всего, такое решение окажется проще и менее губительно, чем переход к совершенно новому архитектурному шаблону.
Масштабируемость, безусловно, мощная концепция, но важно оценить, действительно ли микросервисы идеально подходят для ваших конкретных требований. Исследование альтернативных стратегий в рамках монолитной архитектуры и использование разумной маршрутизации трафика может помочь найти путь к масштабируемости, который не требует полной переработки архитектуры.
Обеспечение надёжной защиты от ошибок
Одним из ключевых преимуществ хорошо спроектированной архитектуры микросервисов является её способность ограничивать ошибки внутри отдельных компонентов, предотвращая их распространение и возможный сбой всей системы. Изоляция ошибок, один из важнейших аспектов микросервисов, способный обеспечить стабильность и устойчивость приложения. В качестве альтернативы микросервисной архитектуре здесь можно применить маршрутизацию трафика в изолированные кластеры в качестве проактивной меры для предотвращения сбоев. Для определения оптимальной стратегии маршрутизации необходимо изучить историю возникновения предыдущих ошибок. Идентификация источников проблем в прошлом может помочь принять обоснованное решение о том, как наилучшим образом направить трафик.
Но профилактика всегда лучше, чем лечение. Путём развития тестирования и придания приоритета автоматизированному тестированию, вы сможете сократить количество ошибок и смягчить их возможное воздействие. Очень важно быть уверенным в том, что создаваемый код не только выполняет нужную функцию, но и способен выдерживать нагрузку в условиях реальной работы.
Архитектура микросервисов также предоставляет преимущество в том, что она не зависит от языка программирования и технологии. И, хотя это может показаться преимуществом, на самом деле такая независимость способствует усложнению и ухудшению согласованности в техническом стеке. Отсутствие же избыточных языков и технологий помогает избежать фрагментации и излишне сложной системы.
Развенчиваем миф о независимости: монолиты против микросервисов
Независимое развертывание служб может показаться привлекательным преимуществом, но на практике оно часто является излишней сложностью и обременением. И хотя иногда оно действительно важно, управление множеством развёртываний в разных службах может усложнить и замедлить быстрое внедрение новых функций.
Даже внутри монолита всегда можно разбить сложные и рискованные обновления на отдельные этапы развёртывания. Например, можно создавать независимые миграции, которые можно легко внедрить и откатить, каждая с собственным запросом на изменения и процедурой развёртывания. Этот подход позволяет получить некоторые из преимуществ, которые предлагают микросервисы, при этом без значительного увеличения затрат и без усложнений процесса разработки.
Теперь давайте обратим внимание на управление зависимостями. Микросервисы позволяют использовать отдельные зависимости для каждого сервиса, но задайте себе вопрос: действительно ли вам это нужно? Управление зависимостями в большом монолите уже может быть достаточно сложной задачей. Фрагментация монолита на более мелкие составляющие упрощает управление каждым из них, но гарантированно добавляет сложности в систему в целом. В то время как микросервисы не обещают полностью избавить от проблем с зависимостями, а только лишь способствуют снижению вероятности конфликтов.
В реальной практике поддерживать актуальность зависимостей желательно, но это часто ускользает от внимания при занятости более приоритетными задачами. Нахождение на "пике" доступных версий может усугубить проблемы, поскольку зависимости могут развиваться с разной скоростью и новые версии пакетов могут иметь новые баги. Однако оставаться в курсе не обязательно означает всегда слепо переходить на самую последнюю версию. Поэтому важно находить баланс и внимательно обдумывать, когда и какие обновления применять.
Утверждение, что код в микросервисной архитектуре будет проще и понятней — в лучшем случае приукрашено, а в худшем случае является откровенной ложью. Хотя действительно каждый микросервис может показаться более простым и управляемым, в целом система становится намного более сложной. Вместо упрощения и ускорения работы, вы просто значительно усложняете процесс в другом месте.
Для того чтобы сделать код проще и более читаемым не обязательно использовать изолированные процессы. Разделение монолита на хорошо определённые модули с ограниченным функционалом может сделать его гораздо более простым и доступным для понимания, нежели система, состоящая из отдельных сервисов.
Монолиты и микросервисы обладают своими преимуществами и сложностями. Важно тщательно оценить конкретные потребности вашего проекта и найти баланс между сложностью, управляемостью и простотой в использовании. При выборе архитектурного подхода руководствуйтесь компетенцией вашей команды и стремитесь к наиболее эффективному обслуживанию ваших клиентов.
Проблемы монолита и поиск решения в микросервисах
Сталкиваетесь ли вы с проблемами, связанными с монолитной архитектурой? Прежде чем обвинять монолитную структуру, давайте взглянем поподробнее. Возможно, корень проблемы кроется не в самой монолитной архитектуре, а внутри монолита.
Создание программного обеспечения — это сложное занятие. Управление большими и сложными системами с множеством изменяющихся компонентов, которые обновляются со временем, представляет собой очень непростую задачу. Если у вас возникают трудности при работе с монолитной системой, это, вероятно, связано с её собственными недостатками, а не просто с тем фактом, что это – монолит.
Сейчас шумиха вокруг микросервисов может создать ложное впечатление, что они представляют собой волшебное решение для всех проблем с монолитом. Это, конечно, не так. Внедрение микросервисов без решения основных проблем может привести вас к ещё бóльшим сложностям, чем раньше.
Не попадайтесь на уловки новомодных течений, тщательно не оценив ваши потребности, ресурсы и возможные сложности. Вместо этого сосредоточьтесь на улучшении монолита. Помните, решение проблем с монолитом достигается не путём слепого следования последним тенденциям, а через вдумчивые инженерные практики, адаптированные к вашим уникальным обстоятельствам.
Поддержание роста бизнеса путём согласованной архитектуры
В динамичном мире электронной коммерции критически важно понимать сложные взаимосвязи между людьми, процессами, организацией, культурой и технологией. Взаимозависимость этих областей требует согласованности действий для успешного развития бизнеса с минимальными усилиями.
Для наглядности можно рассмотреть несколько сценариев:
Представьте себе ситуацию, где команда всего из трех разработчиков создает архитектуру микросервисов. Или вообразите огромную команду из 500 разработчиков, которым не хватает общей координации. Или же подумайте о нескольких командах, каждая из которых несет 50% рабочей нагрузки без взаимодействия и совместной поддержки. Примеров можно привести множество, но основное сообщение остается неизменным: все это приведет к неудачам, потому что важна согласованность.
На пути к оптимальному сочетанию технологических факторов для развития бизнеса
В постоянно меняющемся мире бизнеса, по мере развития компании, встает вопрос выбора наилучшей архитектуры. Важно понимать, что каждый этап развития требует своей уникальной технологической экосистемы для успешного функционирования и дело не в технологии как таковой а в балансе согласованности, который позволяет бизнесу гибко адаптироваться и развиваться.
Пусть модные технические новинки и манят своей привлекательностью, но именно эффективность и своевременное развёртывание программного обеспечения делают бизнес по-настоящему успешным.
Поэтому, перед тем как углубляться в последние архитектурные тенденции, стоит задуматься и выбрать то, что наилучшим образом подходит вашему бизнесу. Важно понимать, что "модульный монолит" и "минимальная архитектура" вновь становятся актуальными по причине своей практичности, эффективности и упора на высокое качество разработки.
В мире, где ключевыми факторами являются результаты, правильная архитектура, совмещенная с хорошо согласованной технологической средой, дает бизнесу возможность процветать.
Пост - вода водяная без какой-либо конкретики и смысла. Все содержание можно было уложить в одно-два предложения.
"Микросервисы - это новая штука, которая многим кажется крутой, но иногда и монолит - ОК."
в одно предложение эффект не тот..
можно и в 4 слова уложить:
микросервисы вам не нужны
вообще
вечно проблема с обоснованиям архитектурных решений
resume driven development )))
Facebook (запрещённая в РФ), eBay и... "Детский мир"! Мировые гиганты!!
"Давайте представим бескрайнюю пустыню, где каждая крупица песка, на первый взгляд незначительная сама по себе, объединяясь с ей подобными, чтобы создать единое целое."
Слушайте. Кто вам это придумал?
Мало того, что аналогия, мягко говоря, спорная, так ещё и изложено, как промпт для какой нибудь нейросетки. Вообще, конечно, вы правы.
Пустыня это масса хаотично взаимодействующих тонн песка. В них нет никакой логики и синергии.
В итоге получаем огромные безжизненные пространства (физические или информационные) которые отнимают оазисы изящных решений, и которые, надо постлянно разгребать.
А есть ещё и зыбучие пески говнокода.
Спасибо за комментарий! "Зыбучие пески говнокода" - это красиво!
да вот нейросетка текст и писала - денег на копирайтера, видимо, нет
Как раз с развертыванием у микросервисов проблем нет, так как это контейнеры. Главное сегодня (для любого размера бизнеса) - это масштабирование. Вот эту проблему микросервисы и решают, а чтобы ее решить как раз надо быстро развертывать, да еще с перманентной отказоустойчивостью, поэтому не может быть проблем с развертыванием там, где решения по автоматизации всего этого лежат в основе.
А если еще надо дешевого и сердито, то облачные вычисления рассчитаны как раз на микросервисы, так как позволяют адаптировать затраты под текущую нагрузку.
Ну а насколько это все эффективно и гармонично, прямиком зависит от кривизны рук архитектора всего этого оркестра (достаточно согласованности API, а там хоть десятки тысяч разработчиков будут пилить эти микросервисы).
И да, даже дорогой архитектор дешевле, чем потом все переделывать для масштабирования под нагрузку, и платить провайдеру за ошибки архитектуры.
P.S.
Основная проблема микросервисов, да и других архитектурных решений, излишняя строгость следования основным принципам архитектуры. Вот реально был пример, когда разработчик сервера не мог добавить время сервера в каждый ответ, так как SOLID у него :) Гибче надо быть, и вникать в суть решения, а не в формальности реализации.
"А если еще надо дешевого и сердито, то облачные вычисления рассчитаны как раз на микросервисы, так как позволяют адаптировать затраты под текущую нагрузку."
и будет дорого и плохо при любой нагрузке
Мажестик монолит!
В этом суть статьи, типа мы не устарели, вы не подумайте, монолит это тоже хорошо
Я то в курсе, сам таких же взглядов.
Вроде мысли правильные, но воды больше, чем было в моей дипломной работе
Про транзакции, про транзакции забыли. В монолите с единой базой данных транзакции реализуются элементарно. А попробуйте-ка сетку микросервисов заставить работать транзакционно.
Спасибо, что не слишком длинно. Воду можно лить гораздо дольше. И главное, с тем же отсутствием смысла и результата.
Нифигасе себе заявочка про необходимый годовой доход в 2 млрд долларов для оправданности микросервисов. Взять тот же Амазон (AWS), с их serverless решениями порог входа и развитие микросервисов стоит сущие копейки.
порог входа - это в том числе написать приложение под микросервисную архитектуру. отнюдь не копейки
бла-бла-бла, вода топового уровня + "закажите у нас монолитный интернет-магаз".
Во время прочтения текста не покидало ощущение того, что писал жпт. Видимо, в промте была упомянута психологическая травма автора от разработки МС-решений, поэтому теглайн явный "монолит - сила, МС - могила".
Отдельно проорал с того, что кто-то в конце 2023 считает МС "новомодным течением", ребят, вы этот текст случаем не в 2011 писали?
зачем вам горизонтальное масштабирование если сейчас вертикального масштабирования хоть обожрись и всего то за пару месячных з/п разработчика можно получить 100+ ядер и терабайт ОЗУ