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

Если вкратце - встал вопрос о создании внутреннего dedicated tenancy для наших Tier 1 клиентов.
Что это означает: у каждого клиента будет свой экземпляр базы данных, набор приложений, и возможно даже инфраструктура (отдельный кластер Fargate, VPC и т.д.).

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

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

Однако ответ на мой любимый вопрос “Какую проблему мы решаем?” поверг меня в ступор.
Оказывается, лид хочется застраховаться от ошибки разработчика, где из-за неправильного where в SQL запросе, клиент может получить доступ к данным, относящимся к другому клиенту.

Человеческий фактор в наше время это, конечно, бич (если не bitch). Вне зависимости от вашего опыта, вы можете руками и глазами в мыле наделать таких дел, что восстановление будет настолько болезненным, что вы задумаетесь о смене профессии или присоединении к FIRE (https://www.investopedia.com/terms/f/financial-independence-retire-early-fire.asp).
За примерами и далеко ходить не надо: чего стоят Gitlab (https://about.gitlab.com/2017/02/10/postmortem-of-database-outage-of-january-31/) и AWS S3 (https://aws.amazon.com/message/41926/)

Во избежание таких ситуаций в индустрии присутствуют такие прекрасные практики как Code Review, Pull request, Pair programming (тут я лукавлю, применение этой практики немного иное конечно).
Но нет, мы будем решать проблему топорно - ты не вытащишь чужие данные, есл в базе их нет.
О том, как деградируют компетенции разработчиков и понизится качество разработки продукта, я даже думать не хочу.

Я уже молчу про то, что даже работая с изолированными окружениями можно накосячить. Что если я (тот кто пишет стек CFN) опечатаюсь в url базы и направлю приложение клиента 1 в базу клиента 2?