3 слова. Это все, что они есть, но они в значительной степени суммируют мир современной разработки программного обеспечения. Не так давно сервис-ориентированная архитектура (SOA) была новаторским архитектурным паттерном, угрожающим поколебать устоявшиеся основы разработки программного обеспечения. Затем, практически как только преимущества стали широко осознаны, разрабатываемые сервисы становились все меньше. С каждой итерацией мы перемещались в мир, где оборудование было менее важным (поскольку рабочая нагрузка была менее интенсивной), пока мы не придумали парадигму, в которой оборудование можно практически игнорировать! Добро пожаловать в мир бессерверных приложений.

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

Надеюсь, вы пойдете со мной в небольшое путешествие по моему мозгу (извините за беспорядок), чтобы увидеть, как я приду на компромисс - потому что в конце концов эти 3 варианта представляют собой эти 3 варианта - которые привели меня к выбору шаблона дизайна , как я избегаю ловушек и стараюсь строить будущее, не упуская из виду настоящее.

Ваш выбор шаблона дизайна (почти) никогда не будет связан с функциональными проблемами. В большинстве случаев вашему пользователю все равно! Независимо от того, создаете ли вы сервис потокового видео, торговую платформу или решение для электронной коммерции, ваш пользователь хочет неизменно хорошего опыта. Им нужна отзывчивость, погружение и простота использования. Достижение такого баланса - невероятно непростая задача, и, хотя плохой выбор может повредить вашей способности обеспечить этот баланс, хороший выбор не принесет его косвенно. Это нежелательный парадокс системного дизайна. Решения, над которыми вы трудитесь, могут иметь минимальное влияние на положительный функциональный опыт, но неправильный выбор все равно может убить ваш проект из-за нефункциональной проблемы.

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

  • Скорость разработки: продукт должен выйти на рынок как можно быстрее без ущерба для качества. Ваши пользователи или спонсоры могут не заботиться о базовой архитектуре, но они будут полностью заботиться о скорости первоначальной доставки, скорости последующих изменений и общего опыта. Быстрая доставка приводит к более быстрой окупаемости инвестиций. Бизнесу (обычно) это нравится. Хороший опыт радует пользователей и сохраняет их при себе.
  • Ремонтопригодность: может ли команда реализовать то, что я разрабатываю? Может ли служба поддержки (если она есть) поддержать. Что произойдет, если компонент выйдет из строя? Как мы узнаем, что он потерпел неудачу и насколько сильно он потерпел неудачу? Каждая из трех парадигм несет в себе свои проблемы, которые вам нужно будет смягчить. То, как вы справитесь с ними, повлияет на то, насколько успешным будет ваше приложение.
  • Гибкость: хорошая архитектура решает сиюминутную проблему, которую вам представляют, не ограничивая выбор в будущем. Меняются проблемы, меняются пользователи, меняются приоритеты бизнеса. Ни одно из этих изменений не будет остановлено вашим выбором архитектуры программного обеспечения, но негибкая архитектура может вызвать трение, когда изменение неизбежно произойдет. Примите тот факт, что изменения произойдут, но трение сделает адаптацию к ним неприятной. Всегда следует избегать трения. Путь наименьшего сопротивления - почти всегда лучший путь.
  • Политика. Это немного горячая картошка, но ее нельзя игнорировать. Вам необходимо понять мир, в котором вы живете. Если бизнесу не нравится идея слабого контроля или зависимостей в облаке, микросервисы или бессерверная архитектура вряд ли получат большую популярность. Если бизнес хочет быстрой доставки и придерживается менталитета «быстрого сбоя», микросервисы, скорее всего, получат зеленый свет без особых «усилий по продажам» с вашей стороны.

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

Итак, что вам, как архитектору, следует делать? Всегда стремитесь к пути наименьшего сопротивления и прокладывайте этот путь к целям деловой культуры. Например, если бизнес существует в области, где стабильность имеет первостепенное значение, а проекты находятся под строгим контролем, обратите внимание на макросервисы. Их нелегко изменить, а развертывание может быть непростым (если не забыть о гибкости проектирования, это поможет справиться с этим), но они обеспечивают стабильность и предсказуемость. Эти системы часто настолько стабильны, что инженеры, проработавшие с ними какое-то время, могут даже предотвратить сбои в определенных ситуациях. Это по-прежнему пример стабильности в архитектуре макросервисов. Маловероятно, что вы бросите курить, и обходные пути станут «обычным делом».

С другой стороны, ваш бизнес может существовать в сфере, где сбои являются обычным делом. Стартапы Web 2.0 - отличный пример того, как хитрый разрушитель может потрясти авторитетных игроков в пространстве, и они могут сделать это быстро. Это способствует культуре «разрушать или разрушать». Архитектура микросервисов возникла из-за необходимости быстро повернуть бизнес и его стек приложений в другом направлении. Эта способность изменять направление оплачивается сниженной ремонтопригодностью. За микросервисами сложно ухаживать! Лучшие микросервисы - это самонастраивающиеся, самовосстанавливающиеся, самообнаруживающиеся автоматы, но они все равно должны быть изменены инженером при изменении бизнеса, и это изменение должно быть сделано таким образом, чтобы не вызывать каскадных сбоев.

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

Так что насчет бессерверного? Это непростой вопрос, и я могу высказать только свое мнение. Мне очень нравится безсерверная архитектура. Идея передать большую часть / все обслуживание ваших компонентов поставщику - это как сбывшаяся мечта! Никаких накладных расходов на обслуживание! Ура!

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

Некоторые люди осуждают привязку к продавцу как причину не использовать бессерверную версию, но я бы высказал другое мнение. Наиболее часто используемые технологии начинаются как проприетарные и постепенно становятся открытыми. Такие вещи, как Serverless Foundation, стремятся сделать точки входа более совместимыми со стандартами, а там, где они не могут, разрабатываются инструменты для минимизации накладных расходов. Я бы сказал, что до того, как вы начнете использовать бессерверные функции, вы уже выбрали облачного провайдера, блокировка уже произошла. Работа против становится еще одним источником трений.

Пройдя через точку входа вашего бессерверного приложения, вы попадаете в зависимости своего приложения. Скорее всего, если вы строите на AWS Lambda, вы также используете DynamoDB, Elasticache или S3. Выбор использования компонентов AWS внутри вашего приложения не имеет ничего общего с бессерверным режимом. Предложения облачных провайдеров дополняют друг друга, пытаясь абстрагироваться от них на случай, если бизнес перевернет всю свою модель на другого поставщика, является чрезвычайно суеверным и маловероятным, если вы не услышите об этом за несколько месяцев вперед. Выбери путь наименьшего сопротивления!

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

  • Timeboxing: бессерверные функции выполняются в строгих временных рамках. Время выполнения заканчивается, и прогресс теряется. У вас есть небольшой контроль над этим, но предоставление длительной рабочей нагрузки в виде бессерверной функции может оказаться нестабильным.
  • Ограничения параллелизма. Одновременно можно запускать только ограниченное количество функций. Этот предел вряд ли станет проблемой, если вы используете бессерверные функции для обработки крайних случаев в вашей архитектуре Micro / Macroservice, но в среде, где весь стек является бессерверным, ограничение на параллелизм работает против созданной вами парадигмы, управляемой событиями. .
  • Стоимость: хорошо задокументировано, что бессерверные функции (на момент написания) стоят больше за секунду использования, чем эквивалентное обычное оборудование, используемое в той же сумме в течение определенного периода времени. Это то, что может быть поглощено, если бессерверные функции исправляют крайние случаи в существующей архитектуре, но бессерверное приложение с полным стеком может стать дорогостоящим ...

Эти три архитектуры сейчас преобладают в разработке программного обеспечения, но стоит добавить, что всего 15 лет назад фундаментальной идеей микросервисов был антипаттерн («крайняя SOA» не одобрялась как чрезмерная фрагментация проблемной области) и бессерверная - нет ». т где угодно даже на горизонте.

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

Приложите все усилия, чтобы понять людей - бизнес, инженеров и пользователей. Людям нужно программное обеспечение, люди его создают и используют. Без людей у ​​вас нет роли, поэтому держать их в центре внимания - залог вашего успеха или неудачи. Невероятно сложно сделать все три группы по-настоящему счастливыми, но между ними можно найти хороший баланс удовлетворенности.

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

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

По словам дяди Боба:

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

«Легко» наполнено контекстом, но если вы сможете его доставить, у вас все получится.