Управляющий слой и слой данных

Большинство инфраструктур делится на две половины, которые стоит называть по отдельности. Управляющий слой — это поверхность управления: консоль, конфигурация, то, что решает, сколько обработчиков существует, какие ключи действительны и каковы правила маршрутизации. Слой данных — это путь, по которому идёт реальный запрос: обработчики, которые отвечают, сеть, которая несёт ответ, хранилище, где лежит то, из чего ответ собран. Различие не умозрительное: половины отказывают независимо, и разница решает, что вы скажете клиентам. Сбой управляющего слоя обычно означает, что ничего нового нельзя выделить или изменить, тогда как всё уже запущенное продолжает обслуживать. Это плохой час для ваших инженеров и, если вы отработали его тихо, обычный час для пользователей. Сбой слоя данных — противоположность: обслужить никого нельзя, но систему, которая отказывает, вы по-прежнему видите и настраиваете. Называть обе ситуации словом лежим — верный способ выпустить сообщение о статусе, неверность которого клиенты запомнят. Это же разделение лежит в основе нескольких схем, которые предложат покупателю. Поставщик может держать у себя поверхность управления, тогда как нагрузки и данные остаются в собственном облачном аккаунте клиента; именно это и делает такую модель возможной. Поставщик видит конфигурацию и метаданные, клиент удерживает путь запроса. Граница осмысленная, и спрашивать о ней стоит точно, потому что пересекает её разное: в одних конструкциях в одну сторону идёт только конфигурация, а в другую — сигналы состояния, в иных тихо уезжает и сама работа. Для начала хватает двух вопросов. Если поверхность управления поставщика недоступна, продолжает ли идти наш трафик? И когда мы вносим изменение, к нашим системам едет команда — или к их системам едут наши данные? Задайте ту же пару вопросов о собственном продукте до того, как их вынудит задать инцидент: ответ решает, будет ли неудачная выкладка из консоли событием, которое видят клиенты, или останется внутренним.