Сегодня в одном чате разгорелся вопрос "а кто этот ваш multi-dc вообще?". Как можно догадаться, многим это и не надо, далеко не каждый бизнес вырос до такого, что не помещается под Франкфуртом у Digitalocean. Но зачем-то они сидят с этим кактусом.
Как еще показывает практика, архитекторы видят в multi-dc больше позитива: у нас и uptime больше будет, и молнии нам не страшны, да и вообще все так делают, вон у FAANG посмотрите.
Проблема только в том, что ДЦ довольно себе живучие, ведь в них вливают денег больше, чем некоторые эти multi-dc фирмы зарабатывают в год (вот сейчас без шуточек). И найти среди друзей, у кого на каком-то небольшом хостинге есть виртуалка, с аптаймом в пару лет - не сложно (жмем F
https://t.me/cyberhermitage/491)
А что еще интересное, что количество причин и время недоступности сервиса чаще из-за софта, чем железа. Пруфнуть числами не могу, но скажу по опыту и опыту друзей. Сколько там раз в проде летели 500 из-за кривых хотелок и желания потестить? Ну и сколько раз падал AWS ?
Но и вот скрытая угроза - а что там со сложностью разработки и поддержки этого добра? Написать distributed инжир каждый может, только вместо "ну у нас конфиг на кластер-монги" и настоящими распределенными системами все еще существует разница. Дело даже не в том, чтобы это закодить, а в том, чтобы поддерживать и знать как лечить.
Уверен, что некоторые multi-dc воспримут как возможность скейлится и иметь гибкую архитектуру, но скейлится можно и в рамках одного ДЦ, и даже очень сильно.
(еще была мысль, что подавляющее большинство бизнеса это read-heavy вещи, эти ваши ютюбы, магазины, твиторы, что дает возможность что-то кешировать и/или заполнять старыми данными, пока ДЦ тупит, а соседние возвращают статику, и эту интересную тему хочется подумать больше)
PS. multi-dc вполне можно читать как multi-cloud.