За последние несколько лет популярность микросервисов и бессерверных вычислений, безусловно, сильно возросла. В наши дни все хотят повторить успехи таких компаний, как Netflix, и создать отказоустойчивую и отказоустойчивую систему в энной степени.

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

Бессерверные решения — преимущества

Представьте себе сценарий, в котором у вас есть новое требование, переданное вам высшим руководством. Это требование возникает неожиданно и не вписывается ни в одну из ваших текущих систем.

Варианты:

  • Внесите новые требования в одну из существующих систем
  • Разработайте новую систему, отвечающую этому требованию.
  • использовать подобные AWS Lambda

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

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

Вариант 3 кажется здесь фаворитом. Вы просто пишете код, который будет соответствовать этому требованию, развертываете его на AWS lambda и отмечаете Jira как завершенную. Это может сильно упростить разработку, но AWS lambda делает за вас чертовски много тяжелой работы, включая такие вещи, как отказоустойчивость, горизонтальное масштабирование и так далее.

Микросервисы — преимущества

Представьте себе второй сценарий, в котором у вас есть монолитная система, которая в настоящее время работает оптимально. Требование исходит от руководства, что вам нужно начать делать Х внутри вашего монолита.

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

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

Это позволяет вам:

  • Для независимого масштабирования «X», чтобы справиться с переменными требованиями к системе.
  • Чтобы снизить риск того, что «X» выведет из строя вашу систему в продакшене в 3 часа ночи.

Монолиты — преимущества

Скажем, вы стартап, время выхода на рынок невероятно важно, и вам нужно выпустить свой продукт как можно скорее. В данной ситуации преимущества:

  • Меньше времени на беспокойство о сложностях распределенных систем
  • Меньше времени на беспокойство о развертывании ваших систем
  • Упрощенная архитектура

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

Заключение

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

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

Мы должны предоставлять конструктивную обратную связь и, по словам Марка Уотни: "Работать над проблемой"