Comments 15
Недавно ovh отправился в облако буквально. Как вы защищены от подобных инцидентов?
Первая: техническая безопасность здания. Тут сложно будет ответить вместо инженеров обслуживающих ДЦ. Кажется, что для клиентов раньше делали экскурсии, и на подобные вопросы отвечали прямо во время оной. Думаю можно устроить разведопрос и рассказать как все устроено, если это интересно конечно.
Вторая: инфраструктурная безопасность сервисов. Тут все просто и сложно одновременно. Есть сервисы, которые сразу живут в нескольких дата центрах. Такие сервисы разрабатываются с установкой — жить без одного ДЦ в аварийной ситуации. И в случае «учений», живут. Однако вопрос доступности это ответственность не только провайдера, но и клиента.
Например. Бывает, что вместо кластера Managed Service for PostgreSQL с узлами в трех зонах доступности и регулярными бекапами клиент сколхозил все на одной виртуалке без бекапов. Очевидно, что риски в такой ситуации весьма приличные. У каждого крупного провайдера, каждый день умирает некоторая часть железа, ибо железо не вечно и всякое случается.
Но вопрос большой, и одним коментом на него не ответить. Хорошая идея для большой статьи, спасибо.
Вроде всё круто звучит, пока не погрузиться в детали этого серверлесс и не поймёшь, что для использования одной функции надо приобретать у этого же провайдера другие сервисы, что, впрочем, видно и из текста уже: гейтвей, очередь (поднять на виртуалке раббит не прокатит же?) и тд и тп
Допустим есть где-то на DO виртуалки: приложение, база, очередь (RabbitMQ например, или на базе Redis), воркер который слушает очередь 24/7, а работает от силы 1/7. Всё это обмазано мониторингом на prometheus и логами на elk. Решили сэкономить с помощью функции вместо воркера. Что кроме самой функции надо брать у облака, чтобы функция триггерилась на сообщение в раббите и хотя бы логи в эластик отдавала?
Допустим. Допустим даже что не надо будет писать свой адаптер для отправки сообщений в YMQ и безопасность от того, что сообщения будут выходить за пределы защищенного периметра, не пострадает. А с мониторингом и логами что? Очередь и триггер смогут отдавать метрики для нашего прометеуса и писать логи в наш эластик без космических счетов?
Угу, когда читаешь общее описание принципов serverless, кажется что переизобрели то ли cgi, то ли dynamic fpm, что php идеально должен ложиться ибо stateless идеологически, рожден чтобы умирать, но на практике оказывается, что php не поддерживаемый официально язык, если можно запустить, то с холодным стартом в разы большим чем у поддерживаемых python или js, соответственно и дороже в разы.
Ну, что тут удивительного? Может все-таки стоит прикопать php?
Никто же не жалуется, что под каждую задачу надо брать соответствующую технологию/инструмент?
А с Java/c# — меня пугает время старта, потому что JVM бывает реально долго стартует. Golang/Python более предсказуемы в этом плане…
Но я бы все равно не обольщался с тем же голангом — потому что если провайдеру вдруг взбрендит запускать код на армах, то ты приплыл (((
Удивительно, что язык, как будто специально создававшийся под serverless модель, с современными фреймворками, заточенными под функциональную модель ($request, $env) => $response без всяких внутренних стейтов между запросами, в итоге не поддерживается толком.
Погружение в Serverless. Функции как основной элемент системы