Когда несколько лет назад я начал заниматься serverless, разговор об этом редко обходился без фразы «привязка к поставщику».
Для тех из вас, кому посчастливилось не слышать эту фразу раньше, она означает, что, взяв на себя обязательство использовать определенного поставщика, вы привязываете себя к нему. Это означает, что вы не сможете отделиться от них, даже если захотите (или вам будет очень трудно это сделать).
Хотя в этом нет ничего плохого по отношению к serverless, имеет ли это значение? Мы привыкли называть блокировку поставщика принятием решения. Вы выбираете поставщика, используете его набор функций и создаете свое программное обеспечение.
Но это не устраивает некоторых людей, что вполне нормально. Однако вы должны принять решение при выборе поставщика облака для размещения и сборки вашего программного обеспечения. Некоторые делают все возможное, чтобы создать «вендор-агностические» решения, в которых они могут забрать свой код из AWS в понедельник и запустить его в Azure во вторник.
Похвально для тех, кто так поступает. Это добавляет сложности в решение, но они добавляют возможность переноса кода между поставщиками услуг в случае, если что-то пойдет не так (либо с точки зрения аварийного восстановления, либо с точки зрения сценария повышения цен).
Или нет?
В то время как код может быть перемещен, как насчет всех ваших данных? Как они будут перемещаться между поставщиками? Вы не можете начать с чистого листа, вы потеряете всех своих клиентов. Они должны перемещаться вместе с кодом.
Что такое гравитация данных?
По мере увеличения объема хранилища в вашем приложении перемещать данные становится все сложнее и сложнее. Это похоже на гравитационное притяжение, где чем больше объем, тем сильнее притяжение. Отсюда и название «гравитация данных».
По оценкам, каждый день создается 2,5 миллиона терабайт данных. Сегодня данные — это все. Объем данных во всем мире поражает воображение. Вы можете быть удивлены объемом данных и в вашем приложении.
В бессерверных приложениях гравитация данных исходит от нескольких различных вещей:
Записи баз данных — возможно, самый очевидный источник гравитации данных, будь то DynamoDB или Aurora, эти записи накапливаются при взаимодействии с вашим приложением. По мере того, как потребители используют ваши API, гравитация данных увеличивается по мере сохранения записей.
Хранение документов — в AWS, S3 — это сервис, который хранит все: от аналитических данных, видео и изображений до архивных данных. Он даже позволяет размещать на нем свои веб-сайты. Со временем объем объектов в S3 может вырасти до петабайтных, экзабайтных и более высоких масштабов, что приведет к значительной тяжести данных.
Журналы — По умолчанию ваши журналы хранятся в CloudWatch в AWS. Все журналы выполнения, ошибок и отладки ваших функций Lambda, рабочих процессов Step Function и шлюзов API консолидируются в одном месте. В бессерверных приложениях журналы являются ключом к успешному мониторингу и устранению неполадок. По мере работы приложения журналы будут расти, что приведет к появлению еще одного источника гравитации данных.
События — Согласно принципам проектирования serverless, вы должны строить свои приложения так, чтобы они запускали транзакции на основе событий. События поступают из многих источников, таких как SNS, SQS и EventBridge. В отказоустойчивом приложении вы должны сохранять события, чтобы их можно было воспроизвести в сценарии восстановления. Такие службы, как EventBridge, имеют архив событий, который именно это и делает. Это создает еще один источник притяжения данных, который необходимо учитывать.
Минимизация влияния гравитации данных
Как вы можете видеть, гравитация данных имеет довольно большой охват в бессерверных приложениях. Критически важные данные накапливаются в таком количестве мест, что кажется невозможным получить их из всех уголков вашего приложения.
Чтобы свести к минимуму количество усилий в случае, если вы действительно собираете вещи и меняете поставщика, начните с консолидации данных в как можно меньшем количестве мест. Вы можете сделать это, агрегируя содержимое в ведро S3 или храня дополнительные данные в базе данных.
Что касается журналов, вы можете легко экспортировать их непосредственно в S3. Поскольку обычно вы не хотите хранить журналы вечно, вы можете автоматически архивировать или удалять их, установив жизненный цикл хранения для ведра или отдельных элементов.
События не так просто консолидировать. Вам придется взять дело в свои руки, когда дело дойдет до консолидации событий в месте за пределами EventBridge. Одним из решений для резервного копирования событий является настройка общего правила для перехвата всех событий, передача их в функцию Lambda и запись содержимого события в DynamoDB.
BackupEventBridgeEventsFunction:
Type: AWS::Serverless::Function
Properties:
CodeUri: functions/backup-eventbridge-events
Policies:
- AWSLambdaBasicExecutionRole
- Version: 2012-10-17
Statement:
- Effect: Allow
Action:
- dynamodb:PutItem
Resource: !GetAtt EventBackupTable.Arn
Events:
EventFired:
Type: EventBridgeRule
Properties:
Pattern:
account:
- !Ref AWS::AccountId
Это сопоставляет все события, происходящие из вашего аккаунта AWS, и отправляет их в функцию BackupEventBridgeEvents, которая затем может записать содержимое в Dynamo таким образом, чтобы его можно было отсортировать в хронологическом порядке.
Резервное копирование журналов в S3 и событий в Dynamo позволит вам теперь учитывать только два места при переносе важных данных.
Стоит ли оно того?
Поскольку вы уже практикуете бессерверные технологии, вы уже достаточно привязаны к своему поставщику облачных решений. Вероятность того, что вы сможете успешно и своевременно сменить поставщика в случае катастрофы, довольно мала. И это нормально!
Одно из основных преимуществ, которое вы получаете, когда переходите на такого поставщика, как AWS, заключается в том, что все сервисы легко интегрируются друг с другом. Вы используете инструменты по максимуму, потому что не создаете обходных путей, чтобы избежать блокировки.
Это приводит к ускорению времени создания, увеличению количества инноваций и, в конечном счете, к снижению затрат на облако. Используйте службы так, как они были задуманы, и вы создадите лучшее приложение из возможных.
В конечном итоге, я бы сказал «нет, не стоит» реализовывать стратегию «бери и работай». Теперь, возможно, будет полезно создать резервную копию журналов и событий, если у вас произойдет настоящая катастрофа. Вам нужно будет воспроизвести события, произошедшие в системе, чтобы вы могли восстановить данные и соблюсти RPO.
Но, на мой взгляд, применение альтернативных мер из-за недоверия к поставщику облачных решений не стоит потраченного времени.
Для пуристов, не доверяющих поставщикам, никогда не существует сценария, в котором у вас действительно нет работы, которую можно было бы перенести на что-то другое. Если вы решили разместить свою собственную базу данных в экземпляре EC2, у вас все равно будет работа, которую нужно перенести куда-то еще. Тома EBS зависят от поставщика AWS. Вы не можете взять том как есть и просто начать использовать его в Azure. Чтобы успешно перенести данные, вам придется пройти определенный процесс резервного копирования/конвертирования/восстановления.
Заключение
Притяжение данных реально. Чем больше данных вы накапливаете со временем, тем сложнее их перенести на что-то другое. Это может быть ваш поставщик облачных вычислений или сторонний поставщик, предоставляющий коммунальные услуги.
Чем дольше вы пользуетесь чем-то, тем сложнее с этим расстаться.
Но это хорошая проблема. Ваши разработчики накопят опыт работы с поставщиком облака. Переход к другому провайдеру заставит ваших инженеров заново изучать нюансы работы, что влечет за собой определенные расходы.
Я считаю, что наибольшего успеха можно добиться, если идти напролом. Полностью посвятите себя своему решению. Колебания и сомнения внесут нестабильность в ваше решение. Построение всего приложения как гигантской модели провайдера приведет к повышению сложности и сложности обслуживания.
Итак, является ли гравитация данных проблемой для бессерверных приложений? Нет, для тех, кто делает это правильно.
Счастливого кодинга!