Это ведь вопрос репутации провайдера. В конечном счёте провайдер рискует всем своим бизнесом, достаточно одной-двух серьёзных ошибок, и клиенты начнут отворачиваться. Наверное, выбирая провайдера, который борется за свою репутацию, можно минимизировать риски.
В конечном счёте стоило, так как развивать легаси уже физически не представлялось возможным. Но от хорошей жизни таким точно заниматься не будешь. То есть я бы точно в будущем не пошёл на такой проект из соображений «станет поудобнее» или «пора обновляться». Только если очень хорошая очевидная выгода по TCO, даже с учётом многократной перезакладки по рискам. Или если старую систему больше действительно невозможно поддерживать.
Несколько лет назад я участвовал в проекте, когда в одну систему сводили несколько разных систем. В том числе замещали сравнительно старые системы, которые были разработаны ещё во времена MS DOS. По сути за три с лишним года просто написали всё заново. Сложно, долго, очень тяжело в процессе внедрения, когда замещаешь старые системы, но точно стоит того. Одна из самых сложных задач в этом процессе была — перенос и очистка старых данных в новую систему.
Многие провайдеры в России как раз с этого начинали. Посмотрите на ТОП-5 провайдеров в России, у каждого заявлен как минимум аттестованный сегмент. Плюс, конечно, все делают виртуальные частные облака. Сложного тут как раз ничего нет, моё личное мнение, нужно как раз вырастать в хороший автоматизированный публичный сервис, а не концентрироваться на гос. сегменте.
Другое дело, что в зависимости от классификации информации и модели угроз и действий нарушителя будет сильно меняется набор технических средств, которые придётся использовать в таком сегменте. И в этом случае, вы абсолютно правы. Ничего кардинально сложного нет, но с какого-то момента экономическая целесообразность вызывает вопросы.
Так как раз не сторонник, сам понимаю и на опыте сталкивался с проблемами таких унаследованных архитектур. Но, к сожалению, переписать их на что-то современное заказчик часто не готов, и проект этот, действительно, не самый простой, требует и денег и времени. А что делать — срочно искать того, кто хоть что-то помнит про этот продукт и после устранения аварии снова идти к руководству за бюджетом на переписывание ПО ))
Спасибо за обзор, как человек, имеющий непосредственное отношение к одному из сравниваемых провайдеров, прочитал с интересом.
При нагрузочном тестировании с небольшими файлами имеет смысл сравнивать существенно большее количество файлов, при этом размер файла можно брать в несколько раз меньше (сотни килобайт). Обычно мы наблюдаем именно такой профиль нагрузки при использовании хранилища частого доступа (сайты в первую очередь).
Уже не первый год обсуждается мульти облачная стратегия как нечто базовое для любого крупного заказчика, особенно предоставляющего собственный публичный сервис на базе IaaS. Почему Битрикс не идёт по этому пути непонятно, даже сейчас решение — переезд в AWS. Но, минуточку, AWS ведь тоже в прошлом падал и достаточно серьёзно. Потом в Google Cloud Platform будет переезд за три дня? Почему сразу не подумать о резервировании?
Конечно, такая атака возможна. Просто, кажется, что её ценность ниже. Ведь на одной физической машине размещается не так много заказчиков, далеко не каждый из них — интересный кому-то вэб-проект, может так случиться, что большинство виртуальных машин окажутся либо служебными, либо какой-нибудь test средой и так далее.
Наконец, каждый заказчик в облаке подписывает договор, известны его установочные данные (как минимум через оплату счёта). Значит атаковать со своей машины рискованно. Перед атакой нужно будет ещё и взломать чью-то чужую виртуальную машину, размещённую в облаке.
Безусловно, в любом случае защищаться от этой уязвимости нужно, потенциально она очень опасна. При этом вероятность пострадать конкретному заказчику, размещённому в облаке, не очень высока.
Другое дело, что в зависимости от классификации информации и модели угроз и действий нарушителя будет сильно меняется набор технических средств, которые придётся использовать в таком сегменте. И в этом случае, вы абсолютно правы. Ничего кардинально сложного нет, но с какого-то момента экономическая целесообразность вызывает вопросы.
При нагрузочном тестировании с небольшими файлами имеет смысл сравнивать существенно большее количество файлов, при этом размер файла можно брать в несколько раз меньше (сотни килобайт). Обычно мы наблюдаем именно такой профиль нагрузки при использовании хранилища частого доступа (сайты в первую очередь).
Может возникнуть вопрос: а почему это не считать одной системой просто? Определение ИС достаточно широкое.
Наконец, каждый заказчик в облаке подписывает договор, известны его установочные данные (как минимум через оплату счёта). Значит атаковать со своей машины рискованно. Перед атакой нужно будет ещё и взломать чью-то чужую виртуальную машину, размещённую в облаке.
Безусловно, в любом случае защищаться от этой уязвимости нужно, потенциально она очень опасна. При этом вероятность пострадать конкретному заказчику, размещённому в облаке, не очень высока.