Не убедили. Плавающие ip стоят денег, и требуют обслуживания, особенно в bare-metal инфраструктуре. Да даже с ними я ставлю ttl пять минут, на всякий случай, чтобы быть точно уверенным что я смогу перенести основную часть трафика на резерв, в разумное для бизнеса время.
DNS GeoIP — а что если у пользователя будет не провайдерский DNS? Например он делает запрос из Австралии, а DNS'ы у него прописаны США?
Не совсем понял как дела обстоят с автоматизацией? То есть настройка происходит как описано в статье? Руками надо выполнять команды в powershell, прожимать галочки, кнопочки и т.д.? А если дропнуть все сервера, за сколько времени поднимите аналогичную настройку?
На мой взгляд гораздо проще и выгодней было поднять, тоже самое но на: linux + nginx, и все это автоматизировать ansilble (или другой scm).
Надо было им хитрее поступить, скомпилировать такую же версию, а вместо скрытия всего конфига, утаить только свою часть. Но интересно, как же рута получили. Вдруг дыра на сайте, и если даже дыра, бэкенд наверняка от обычного пользователя работает, то есть ещё и права подняли.
Помню на одном из серверов, который я админил, как оказалось было уязвимое веб-приложение, через post запрос, можно было запустить любой php файл на сервере, злоумышленник это нашёл, но способа залить бэкдор к него не было. Но он увидел, что есть доступ к логам веб-сервера, сформировал так запрос, чтобы в логи попал валидный php код, а потом просто выполнил этот код через раннее найденную уязвимость, php интерпретатор успешно выполнил код из логов, и так он залил бэкдор. Сервер был тестовый для разработки, поэтому для удобства, логи доступны пользователю от которого бэк запущен. Мораль — логи надо защищать, не такая уж это безобидная вещь.
Я не уверен, что Ваш ответ адресован мне, но про звонки никто больше не писал. Видимо Вы невнимательно прочитали, но я наоборот писал, о том, что мне удобно посмотреть цены на сайте, а не кому-то звонить, а если приходится кому-то звонить, чтобы выяснить цены, то вероятнее туда просто я не буду звонить. Также я не уверен, что у них нет цен на сайте (возможно я просто плохо искал).
И по людям тоже прокомментирую — в том то и дело, что вместо того чтобы содержать в штате сотрудников, которые занимаются администрированием серверов, СХД, сети — вы можете сосредоточится на «админах», которые нужны для работы core бизнеса, а не поддержания парка оборудования.
Но ведь это не так, основная нагрузка на админов это как-раз поддержка infrastructure as code, ci/cd, деплоя. И в облаке это все остается, и не сильно легче, а на поддержку оборудования, как раз и отвечает поставщик, единственное что требуется, это мониторить в том числе и железо и создавать во время тикеты (и это минимальная нагрузка на админов).
Я не говорю, что во всех кейсах железо лучше, я лишь утверждаю, что в большинстве случаев облака на порядок дороже, причем не на малый. Хотя часто говорят наоборот про сокращение расходов, что на мой взгляд миф. Удобство — да, быстрое масштабирование — да (хотя ничего не мешает основную нагрузку держать на железе и быстро масштабировать нагрузку в облака когда это требуется), построить отказоустойчивое решение легче — да, сокращение расходов и штата админов — нет.
А касательно цены на Облако — уверен что наше предложение при одних и тех же данных на входе и конечного желаемого результата не будет в 12 раз дороже.
А давайте посчитаем, правда я не нашел возможности у вас это сделать. Нет ни калькуляторов цен, ни какого-то прайса. Например на вашу услугу «DF Cloud On Demand» (как я понял это виртуалки как EC2) не нашел расценок. Это кстати очень плохо, на мой взгляд, мало того, что если мигрировать в облака, то хочется конечно использовать проверенные решения AWS, Google cloud, Azure или как минимум с OpenStack совместимым API, но даже если рассматриваем другие варианты и не можем банально сравнить во сколько это обойдется (для этого потребуется совершать доп. действия звонить или писать), то этот вариант скорей всего просто не будет рассмотрен.
Арендуем железки, все почти устраивает. Захотелось нам удобных виртуалок как в облаке, и решили может просто использовать публичные облака, ведь цены то говорят «доступные». Взял один наш проект: 5-7k запросов в секунду на бэкенд. Статика на CDN, ее не учитываем. Посчитал во сколько это обойдётся, получилось 12 кратное увеличение затрат в сравнении с арендованным железом. Не очень понятно как это бизнесу продать, сказать что там надёжней? А если текущая SLA на железе полностью устраивает? Для бизнеса это выглядит как: а давайте платить в 12 раз больше, чем сейчас. Да и проектов таких ещё несколько, а ещё неизвестно во сколько базы с нагрузкой в 50k запросов в секунду там обойдутся. Многие скажут, что можно сократить админов, засчет облаков, но это неправда, в облаках для админов не меньше работы чем на железе, ci/cd, infrastructure as code, мониторинг, и т. д никуда не денутся, и с такими расценками, можно ещё с десяток админов нанять и это будет дешевле чем в облаке.
А каким образом факты team, project, tier, role — попадают на сервер? Используете кастомные факты? Если да, то на основе каких данных вы формируете указанные вами факты?
Мне очень интересно узнать, так как я тоже формирую кастомные факты group, subgroup на основе hostname. Например если имя сервера php10-1.example.com, то group = php, subgroup = 10.
Не совсем понял как дела обстоят с автоматизацией? То есть настройка происходит как описано в статье? Руками надо выполнять команды в powershell, прожимать галочки, кнопочки и т.д.? А если дропнуть все сервера, за сколько времени поднимите аналогичную настройку?
На мой взгляд гораздо проще и выгодней было поднять, тоже самое но на: linux + nginx, и все это автоматизировать ansilble (или другой scm).
Но ведь это не так, основная нагрузка на админов это как-раз поддержка infrastructure as code, ci/cd, деплоя. И в облаке это все остается, и не сильно легче, а на поддержку оборудования, как раз и отвечает поставщик, единственное что требуется, это мониторить в том числе и железо и создавать во время тикеты (и это минимальная нагрузка на админов).
Я не говорю, что во всех кейсах железо лучше, я лишь утверждаю, что в большинстве случаев облака на порядок дороже, причем не на малый. Хотя часто говорят наоборот про сокращение расходов, что на мой взгляд миф. Удобство — да, быстрое масштабирование — да (хотя ничего не мешает основную нагрузку держать на железе и быстро масштабировать нагрузку в облака когда это требуется), построить отказоустойчивое решение легче — да, сокращение расходов и штата админов — нет.
А давайте посчитаем, правда я не нашел возможности у вас это сделать. Нет ни калькуляторов цен, ни какого-то прайса. Например на вашу услугу «DF Cloud On Demand» (как я понял это виртуалки как EC2) не нашел расценок. Это кстати очень плохо, на мой взгляд, мало того, что если мигрировать в облака, то хочется конечно использовать проверенные решения AWS, Google cloud, Azure или как минимум с OpenStack совместимым API, но даже если рассматриваем другие варианты и не можем банально сравнить во сколько это обойдется (для этого потребуется совершать доп. действия звонить или писать), то этот вариант скорей всего просто не будет рассмотрен.
Но Вы же в итоге создаете пользователя, который через sudo имеет все рутовые права, не очень понятно чем эта идея лучше, чем просто делать от рута?
Мне очень интересно узнать, так как я тоже формирую кастомные факты group, subgroup на основе hostname. Например если имя сервера php10-1.example.com, то group = php, subgroup = 10.