Comments 154
Что то банки не согласны. Держат свою инфраструктуру с сисадминами, бедолагами и прочим геммороем. Наверное в банках не умеют считать деньги! Или нет? Ну хоть бы часть перенесли… Опять нет?
Может все дело в защищённости данных? И гарантии, что кроме авторизованных юзеров туда никто не имеет физически доступа? Уж сколько раз сливали данные с этих ваших облаков.
А может, дело в мнимой надёжности? Времени реакции (у нас регламент… Пишите письма мелким почерком) и прочим финтам ушами в виде пропалания каналов связи… И высрким требованиям к ним.
Запустить кучу разработчиов, которые юзают сверхбольшие бд и тд.
Для небольших проектов может и сойдёт… И то… Надо смотреть цену вопроса… А в остальном — так себе затея
Хотя существуют ЦОДы предлагающие «частное облако» сертифицированные по всяким ГОСТ
и виртуальные криптошлюзы к ним. Просто сами сервисы у них пока не особо приучены к контейнеризации и динамическим изменениям инфраструктуры. Хотя тенденция в этом направлении потихому прослеживается.
И среди зарубежных финансовых институтов движений в облака очень много. Хотя, разумеется, есть и «ретрограды». Это нормально.
Многие Российские банки и финансовые институты имеют проекты движения в эту сторону.
Сначала среды разработки, тестирования (не базы данных на десятки терабайт, конечно).
Потом какой-нибудь VMware Cloud в виде расширение on-prem, чтобы когда ресурсы в ЦОД закончились, поднялись виртуалки в облаке, а не просто «отказ в осблуживании» случился…
Да, у облаков много проблем и рисков. Особенно у зарубежных в нашей стране.
Тем не менее, я предпочитаю не ерничать, а въезжать в тему.
Прошли все круги ада пока разместили на своем SaaS банки класса Wells Fargo и JPMC. JPMC до 2019 хостил у себя. Причина простая — регуляторы.
Банки обставлены вешками по хранению PII и чтоб получить разрешение хранить данные за пределами своего дата центра, нужно приложить массу усилий.
Еще причины:
— страх потери данных и последующие штрафы.
— усложненный аудит.
Какой кошмар, своя инфра стоит денег! А облака, что, бесплатно раздают?
Amazon высадились первыми, и они продолжают занимать около половины рынка. Microsoft Azure присоединились с большим опозданием, но сейчас каждый пятый клиент пользуется именно ими. Google Cloud Platform немножко от них отстают, но в принципе незначительно.
«Есть другая информация» (с) ГИБ
«Как я уже упоминал ранее, мне непонятно, почему так много аналитиков и людей в средствах массовой информации до сих пор называют AWS беглым лидером или доминирующим игроком в облаке. Как ясно показывают цифры, облачный бизнес Microsoft почти на треть больше, чем Amazon.
Существенная разница в размерах Microsoft и Amazon в облаке не новость; посмотрите на квартальные различия в доходах от облачных вычислений в течение 2020 года:
Первый квартал: 10,22 млрд долларов AWS, 13,3 млрд долларов Microsoft
Второй квартал: 10,81 млрд долларов AWS, 14,3 млрд долларов Microsoft
Третий квартал: 11,6 млрд долларов AWS, 15,2 млрд долларов Microsoft
Четвертый квартал: 12,74 млрд долларов AWS, 16,7 млрд долларов Microsoft
Полный год: 45,4 млрд долларов AWS, 59,5 млрд долларов Microsoft»
Взято здесь.
Аналогичный по ресурсам DELL R640 c трехлетним ProuspportPlus (4hour) ~ 31700$, ну пусть еще по 100$ в месяц (3600$) за 1U-коло в TIER3 ЦОДе.
«feel the difference» ©
feel the difference.
hyper-threading is enabled, and one vCPU as equivalent to one Oracle Processor license if
hyper-threading is not enabled.»
Надо быть очень альтернативно одаренным, чтобы вытаскивать оракл в облако на таких условиях.
feel the difference again
Единственно с чем не поспоришь, так это с тем что можно себе и мгновенный прирост ресурсов обеспечить, и через месяц от этих ресурсов отказаться.
А дальше начинается куча нюансов о которых в таких статьях умалчивают:
серверов не хватало, а новых заказать не давали — бюджета нетЕсли бизнес что то не хочет покупать, значит оно ему не требуется. Не дают денег на железо? Внезапно это не проблема сисадминов, хотя и доставляет им некоторые неудобства. Зато учит рационально подходить к распределению ресурсов, и очень прокачивает понимание того сколько и чего для каких процессов нужно.
один инженер работал за десятерыхНе совсем понятен аргумент. А что изменится от того что сервера будут в облаках? Теперь он будет не сервера с прошивками тыкать, а искать оптимальные решения в облаках, что бы лишние центы не жрались. Это я про инфраструктурников.
поддержка флота съедала всё время, его не оставалось на развитиеТе кто живет на самосборе на своем болту вертели облака. Те кто живет на вендорских решениях обычно покупают его в комплексе с инсталляцией от интегратора. Плюс модные облачные аналитики и мониторинг, когда твои СХД, сервера и прочие вещи обновляют и чинят без участия админа. Что то пошло не так? Инженер вендора уже с утра будет на проходной тебя ждать вместе с зип-комплектом. Можно вообще не заморачиваться.
разработчики плохо оценивали нагрузку на инфраструктуру… и загнали баланс конторы на облачном сервисе в дикие минуса, контора не смогла найти бабла оперативно = бизнес встал колом. Прекрасный пункт, люблю когда про него и AWS рассказывают.
заказанные с горем пополам серверы ехали по несколько месяцев.Ну тут вот не поспоришь — ровно это в начале я и сказал.
управленцы: постоянно приходилось искать деньги на новое оборудованиеКак будто облака ничего не стоят. Ну вы взяли из капитальных затрат переложили в операционные. В разрезе 5+ лет операционные всегда превышают капитальные.
и одновременно — нормальных людей в командуКак я понимаю, с облаками можно и идиотов нанимать?
Админы не развивали инфраструктуру, а только патчили текущий флотНу да. Они делают свою работы. Развитием занимаются начальники Отдела/Управления/Департамента ИТ и CIO. Админы как был техперсонал, а развитием должны заниматься те кто выступает связующим звеном ИТ направления и бизнеса. Если у вас таких нет, то и в облаках вам делать нечего.
БД работала медленно, клиенты были недовольны; сложно было оценить, сколько железа нужно под новый проект.По личному опыту могу сказать, что говнокоду совершенно без разницы сколько железа вы ему отдадите, можете скалироваться в облаках бесконечно и будет тормозить.
Высокая стоимость и низкая надёжность. Система либо хрупкая, либо очень дорогая. А часто и хрупкая, и дорогая.AWS вообще самый дорогой. Удобный, но очень дорогой. И возможностей накасяпорить там просто великое множество.
Отсутствие гибкости по географии.Как бы это странно не звучало, но подавляющему большинству она не нужна.
Если данные размещены в одном дата-центре, приложение нельзя назвать отказоустойчивым.Катастрофоусточивыми его тогда назвать нельзя. Отказоустойчивость другой процесс с другими задачами.
Отсутствие гибкости по производительности. Свои серверы либо простаивают ¾ времени, либо в час пик не хватает мощностей, и всё лежит.Все верно. Но ведь мне ничто не мешает это спланировать и взять оборудование в аренду или добрать это теми же облачными ресурсами? Это для тех у кого высокие сезоны в бизнесе. А для у кого этого нет — они просто в ночь ставят конвертации/перепроведения/расчет аналитики/тестирования и прочие вещи.
С точки зрения инженеров — когда при первой необходимости есть возможность поднять новое окружение и грохнуть его, как только отпадёт нужда.Но на земле та же самая виртуализация, оркестрация и прочие вещи. Какая разница системе управления конфигурацией где поднимать виртуалки: у себя на серверах или в облаке?
Я не против облаков.
Я к тому что статья однобоко нам выпячивает проблемы малого и среднего бизнеса, а решает это инструментами для уже зрелых бизнесов. Нет парни, эта херня так не работает.
Проблемы поддержки своей инфраструктуры:
Высокая стоимость и низкая надёжность
amazon RDS: single az, db.m6g.8xlarge (виртуалка), 32 vCPUs, 128GiB озу, 1800GiB Provisioned IOPS (SSD), 3000 iops. Стоймость — 2732$ в месяц.
Частые проблемы, тормозит, тех поддержка отвечает очень долго и невнятно, надо доказывать что ты не верблюд.
hetzner: AX161(железка), AMD EPYC 7502P 32-Core "Rome" (Zen2), 128 GB DDR4 ECC RAM, два локальных nvme диска на 1.92 TB (NVMe SSD Datacenter Edition). Стоймость 109 + 53(диски) = 162€. Берем таких три, для построения отказоустойчивости. Итого 162*3 = 486€ в месяц.
Не тормозит, 50,80,90,95 перцентли по времени запроса гораздо лучше(ниже) чем в RDS, в случае проблем с железом тех. поддержка отвечает за 10-30 минут, довольно подробно отвечают в случае проблем.
Масштабируем на мой кейс, таких СУБД около 9.
AWS RDS: 9 * 2732 = 24 588$ в месяц.
hetzner: 9 * 486 = 4374€ в месяц.
Разница в ~5 раз. При этом rds проигрывает по производительности.
На оба случая нужны devops инженеры и примерно одинаковое количество. Спецы по облакам стоят дороже.
Можно посчитать остальную инфраструктуру, и порядок разницы увеличивается всё больше, особенно за трафик. Если требуется горизонтально масштабировать приложение, это можно делать и на таких хостерах как hetzner, так как там можно создавать виртуалки через api.
Я несколько раз считал во сколько обойдется в amazon инфраструктура компании где я работаю, и это всегда примерно в 5-8 раз дороже. А везде пишут должно быть дешевле. Скорее всего я где-то допускаю серьезную ошибку.
«При поддержке своего парка серверов компании сталкивались и продолжают сталкиваться с несколькими крупными проблемами.
Медленные изменения. Расширение, масштабирование, добавление мощностей — на всё это нужно время. Оборудование надо заказывать за несколько недель или даже месяцев, оплата вперёд. Можно взять в аренду, но минимальный срок аренды — месяц, даже если сервер нужен на один день.»
Это пожалуй единственное преимущество облаков. Работа по принципу муж на час. С динамическим выбором массо-габаритных показателей ;)
Для реальных сервисов «в долгую» — экономическая эффективность своих серверов десятикратная.
Мне не нравится что в статье категорично сравнивают две крайности облако и свой цод куда железки везут месяц.
В том же hetzner стоковые железки ты получаешь через 15 минут после заказа. Если надо автоматически быстро масштабироваться, берёшь у них же виртуалки через api.
Также мне не нравится что всегда говорят облако дешевле, но реальных цифр не приводят. Потому что мои подсчёты на конкретном кейсе говорят об обратном. Наверняка есть кейсы когда облако действительно дешевле, например при сочетании маленьких нагрузок и очень сложной инфраструктуры, когда за обслуживание инфраструктуры бизнес платит больше чем за саму инфраструктуру. То есть хотелось бы не маркетинга, а истории вот мы перешли в amazon с servers.com, с экономили 20 000$ на таких-то вещах. Или подробный и честный разбор всех нюансов. Просто сейчас складывается ощущение, что в сообществе априори облака считаются дешевле, а если ты начинаешь разговор об этом, тебя считают маргиналом.
Полезных — может быть, удобных после профессиональной настройки — возможно, но вот опять же не бесплатных. Особенно заметно, если сервис из разряда не особо нужных на железках (просмотр логов — tail+grep есть и т. п.) или условно бесплатный (redis или memcached для кэша в пару сотен мегабайт можно и не заметить на средненагруженном сервере с 16Гб рам)
Ну и пока ограничиваешься EC2, да создаваемых из вебui, никакого вендор-лока особо, а как пошёл в сервисы...
Некоторые бизнесы начитаются/насмотрятся/наслушаются про прелести облаков, все эти "плати только за то, что используешь", ставят задачи на переезд, а потом на админов, его осуществивших, наезжают из-за счетов
а потом на админов, его осуществивших, наезжают из-за счетовпросто эффективно пользоваться облаками — надо уметь. И ни один админ без опыта не сможет этого сделать
Бизнесу в маркетинговых материалов облаков не объясняют же что им нужно разогнать существующую команду и набрать новую, с опытом в облаках. Админам что, им сказали переехать, они EC2 нашли, подобрали по характеристикам аналогичное имеющемуся, подняли, связали, в мир выставили, задеплоили, потестили — тормозит, потому что скорость дискового ио зависит от объёма — увеличили диски — работает, можно в прод.
SaaS сервисы в разы дороже виртуалок, бо они на тех же виртуалках
Тоже могу сказать "глупости": за несколько лет SQL SaaS могут сжечь на порядок больше чем тройка дедиков и пара толковых админов
Кто ради экономии, а кто готов переплачивать за отказоустойчивость.
Если простой сервисов не умеют считать, либо он приносит убытки с которыми ваш бизнес готов мирится за определенный промежуток времени, то собственно тогда и есть мнение что нафиг мне свой машзал с вендорским железом на поддержке.
Если простой в течение 1го часа стоит больше годовой стоимости аренды вычислительных ресурсов в облаках на AWS, то никаких проблем с переходом в облако или закупкой железа в свой корпоративный ЦОД не будет.
Высокая доступность и скэйлинг ресурсов — за этим идут в облака.
А некоторые идут свято веря, что принцип "платишь только за то, что используешь" уменьшит их расходы, не вдаваясь в нюансы того, что облака считают использованием и использованием чего.
Где об этом упоминается в презентациях об облаках для бизнеса? Наоборот продвигается мысль, что разберётся чуть ли не ребёнок со всем — администраторов можно вообще разогнать.
Где об этом упоминается в презентациях об облаках для бизнеса?Если технический руководитель, который отвечает за будущий возможный переход, безусловно верит презентациям, то у меня для вас плохие новости. И я говорю не о сисадмине
Сисадмина могут назначить техническим руководителем проекта перехода бизнес-руководители, верящие презентациям. Постоянного технического руководителя может вообще не быть в небольшой компании, а могут назначить самого опытного технаря, например, далекого от маркетинга и прочих бизнесовых штучек.
Тогда руководитель фирмы/компании ССЗБ. Что тут еще можно добавить
Но не потому что нет техрука, а потому что принял решение идти в облака без озвучивания исполнителям своих реальных требований и ограничений. Админам что — техническую задачу переезда они решат, но хотел-то бизнес не переехать, а улучшить какие-то бизнес-метрики, не ухудшая (или не сильно ухудшая) другие
Админам что — техническую задачу переезда они решат, но хотел-то бизнес не переехать, а улучшить какие-то бизнес-метрики, не ухудшая (или не сильно ухудшая) другиеНапример, я руководитель фирмы и на встрече коллег/друзей я услышал, что облака это круто и стильно/модно/молодежно. Допустим, я далек от тех деталей и разницу AWS от GCP не понимаю от слова совсем.
И первый вопрос который должен задать себе любой руководитель — «Перенести в облака чтобы что»?
Первое чтобы я сделал — дал задачу человеку, пусть это будет условный сисадмин без опыта работы с облаками — «Рассмотреть возможность переноса инфраструктуры в облака, с целью уменьшения затрат на поддержку и развитие инфраструктуры. Повысить надежность и качество работы»
И здесь уже все зависит от конкретной цели. Если ответ на «чтобы что» — экономия затрат. То следующая задача сисадмину — привести сравнительные затраты на текущую инфраструктуру и на такую же, но в AWS/GCP. Описать плюсы и минусы, возможные риски и потенциальные проблемы. Затраты при росте инфраструктуры и т.д. и т.п.
А сможет ли он без опыта сравнить адекватно? Посчитает, например, стоимость EC2 инстансов плюс-минус аналогичных имеющимся, укажет в минусах сложность доступа (роли и вот это вот всё), в плюсах автоматическое поднятие при аварии и всё. Но забудет (если это слово уместно) про стоимость трафика, публичных IP/LB и прочего, просто потому что не привык, что надо за каждый чих платить отдельно. Вы примете решение переезжать, сроки будут превышены (тот же LB настроить надо), надежность получите выше, но счета будут превышены многократно, может на порядки, а о возможности ограничении расходов (забудем, что она кривовато работает) ни вы, ни админ не знаете.
А сможет ли он без опыта сравнить адекватно?Если он умеет читать, анализировать и делать выводы — то сможет. При условии конечно что задача не вида — завтра переезжаем, чтобы утром были результаты сравнения.
Посчитает, например, стоимость EC2 инстансов плюс-минус аналогичных имеющимсяпри этом как минимум на AWS он должен упомянуть, что есть:
1. Поминутная тарификация EС2
2. Различные способы аренды: on-demand, reserved instances, dedicated, spot instances
3. Различные виды инстансов: t2/t3 vs другие (в контексте cpu кредитов)
4. Для каждого инстанса входящий/исходящий трафик оплачивается отдельно (справедливо почти для каждого сервиса)
5. AWS Lambda (serverless computing)
Но забудет (если это слово уместно) про стоимость трафика,…если есть сомнения насчет умственных возможностей человека — всегда есть аутсорсовые компании, которые сделают такой анализ профессионально. Но естественно — не за спасибо
Причём тут умственные способности, если речь о нюансах биллинга и задачи оптимизировать затраты не ставилось? Как и перехода на serverless вычисления
Вся информация есть на офф сайте. Поэтому если человек умеет читать, анализировать и думать — не вижу никаких проблем
Прочитать весь офсайт — не проблема? Почему вообще админ должен погружаться в нюансы биллинга, если в задаче этого явно не сказано? Переход на серверлесс или даже spot instances требует архитектурных изменений, близких к проектированию cloud native систем
Прочитать весь офсайт — не проблема?
Не весь, а раздел по EC2. А в чем проблема?
Почему вообще админ должен погружаться в нюансы биллинга, если в задаче этого явно не сказано?
А с чего вы взяли что в задаче не сказано? А если таки не сказано — то все притензии к тому, кто ставил задачу
Переход на серверлесс или даже spot instances требует архитектурных изменений, близких к проектированию cloud native систем
Я нигде и не утверждал о бесшовном переходе ;) Хотите экономить — сначала придется "вложиться"
Не весь, а раздел по EC2. А в чем проблема?
Там ссылки на другие разделы, от управления ролями и пользователями до бухгалтерии
Хотите экономить — сначала придется "вложиться"
Вот про это и забывают в презентациях.
Там ссылки на другие разделы, от управления ролями и пользователями до бухгалтериидля этого у человека на плечах есть голова, которой надо думать. Я тоже в свое время был без опыта и тоже много читал. Так что не вижу тут ничего непосильного для любого технического специалиста
Вот про это и забывают в презентациях.это актуально практически для любой сферы
Так что не вижу тут ничего непосильного для любого технического специалиста
Для мотивированного и имеющего время на это
Для мотивированного и имеющего время на этотак можно сказать про любого человека и задачу, так что не специфично для данной конкретной задачи.
Если человек не хочет ничего делать или нет головы на плечах, то он вам и через месяц не сделает. Не вижу смысла рассматривать какие то крайние случаи
Вы передергиваете. Тут речь о том, что, скорее всего, подобная задача будет недостаточно полно описана, а если исполнитель не мотивирован развиваться в этом направлении, считая подобный переезд очередной блажью начальства, поддавшегося на сказки маркетологов, то глубоко, особенно в личное время, рыть он не будет и пробелов в задаче объективно заметить не сможет.
Формально задача будет решена, но, скажем так, лучшие практики в области экономической эффективности применены не будут, потому что ни постановщик, ни исполнитель о них не знают: для постановщика переезд означает автоматическое уменьшение затрат при автоматическом увеличении надежности, а для исполнителя — просто смена поставщика VDS, причём на объективно более дорогого
Иначе бы не было товарищей, специализирвующихся именно на оптимизации счетов за облака.
Простой пример:
Я радуюсь, что в Azure можно легко поднять кластер Kubernetes (AKS), при этом Azure за управление денег не берет. Т.е. надо платить только за воркеры, но им я делаю Scale = 0, когда не пользуюсь. Т.е. рассчитываю, что у меня будет в облаке кластер, с готовой конфигурацией, подами и т.п., и я буду немножко платить только когда реально надо что-то протестировать.
Реальность: при этом разворачивается балансировщик, который остановить нельзя, и который ощутимо кушает.
Держать в таком режиме кластер, чтобы запускать его на несколько часов в месяц меня не устраивает.
Пробую другой вариант — создаю кластер не со стандартным Load Balancer, а с Basic.
Все супер, каши не просит.
И опять нюанс — когда я добавляю nodepool, причем на Spot instance, оказывается, что Basic LB несколько пулов не поддерживает.
По-моему, даже дефолтный пул я не могу увеличить с 1 до 3.
Так что я с трудом могу представить человека, который сможет это все учесть просто почитав документацию в свободное от работы время. Даже если он очень старательный.
Так что я с трудом могу представить человека, который сможет это все учесть просто почитав документацию в свободное от работы время. Даже если он очень старательный.где вообще речь шла о свободном от работы времени? Подобного рода задачи даются как основные и приоритетные. Ну и время должно выделяться соответственно.
И опять таки, никто не заставляет сразу все переносить. Перенеси 1-2 сервиса, посмотри как оно будет работать, какие подводные камни. Так что не вижи никаких проблем
Я радуюсь, что в Azure можно легко поднять кластер Kubernetes (AKS), при этом Azure за управление денег не берет. Т.е. надо платить только за воркеры, но им я делаю Scale = 0, когда не пользуюсь. Т.е. рассчитываю, что у меня будет в облаке кластер, с готовой конфигурацией, подами и т.п., и я буду немножко платить только когда реально надо что-то протестировать.кубик это уже априори не простой пример
Реальность: при этом разворачивается балансировщик, который остановить нельзя, и который ощутимо кушает.все через это проходили и набивали шишки. В свое время аналогично было с beanstalk. Я даже совет на stackoverflow оставлял, как полностью погасить окружение, чтобы не тратились ресурсы
Держать в таком режиме кластер, чтобы запускать его на несколько часов в месяц меня не устраивает.
Пробую другой вариант — создаю кластер не со стандартным Load Balancer, а с Basic.
Все супер, каши не просит.
И опять нюанс — когда я добавляю nodepool, причем на Spot instance, оказывается, что Basic LB несколько пулов не поддерживает.
По-моему, даже дефолтный пул я не могу увеличить с 1 до 3.
Если человек не хочет ничего делать или нет головы на плечах, то он вам и через месяц не сделает.Для меня разговоры про мотивацию вызывают подозрения, что от человека ожидают существенно больше, чем предусматривается служебными обязанностями. И задание «а прикинь-ка нам экономическую эффективность переезда в облако» может быть дано. А вот «а от такой-то твоей работы мы тебя освобождаем» — вряд ли.
Ибо а «че такова стоимость пары EC2 посчитать».
Ну ОК, возможно я не прав.
Хотя я даже согласен, что посчитать тупой Lift and Shift для пары сервисов не особо сложно. Только зачем?
Если не пользоваться расширенным функционалом облака, тот же Hetzner, который не предлагает ничего, кроме условных виртуалок, будет, безусловно, дешевле.
Это если кому-то нужно иметь возможность оперативно получить дополнительные вычислительные мощности.
А если не нужно — тогда докупить пару серваков под утилизацию «под завязку» будет выгоднее, чем любое облако.
Для такой задачи выделять человека смысла нет.
Чтобы облако стало выгодным, надо использовать преимущества, которые оно дает. А для этого нужно влезать в особенности.
Причем зачастую вылезают еще особенности лицензирования 3rd party решений в этом самом облаке.
И учесть такие тонкости требует ресурсов (знаний, времени, опыта) не в разы, а на порядки больше.
Возможно поэтому я часто вижу не теоретические сравнения, на базе которых принимаются решения, а реальные минипроекты.
«Давайте перенесем в облако тестовую среду такого-то сервиса, посмотрим реальную стоимость, набьем шишек...»
Для меня разговоры про мотивацию вызывают подозрения, что от человека ожидают существенно больше, чем предусматривается служебными обязанностями.it depends. Когда я работал сисадмином и хотел вырваться в devops, то подобный случай — был бы подароком судьбы просто. А так да — если работаешь от звонка до звонка — то какие такие облака ))
Если не пользоваться расширенным функционалом облака, тот же Hetzner, который не предлагает ничего, кроме условных виртуалок, будет, безусловно, дешевле.до первого сбоя или выхода из строя винта
А для этого нужно влезать в особенности.например? Стоимость той же венды уже включена в почасовую стоимость EC2 и не надо высчитывать отдельно что то. Аналогично и для субд — mssql/oracle. Или о каких таких хитрых 3rd party идет речь?
Причем зачастую вылезают еще особенности лицензирования 3rd party решений в этом самом облаке
Для такой задачи выделять человека смысла нет.так никто и не говорил о выделении человека. Возможно имеет смысл, если вы собрались переводить сотни серверов
Чтобы облако стало выгодным, надо использовать преимущества, которые оно дает.заменив облако на любое слово, например ЯП или фреймворк, смысл не изменится ;)
Разве что прокомментирую свою мысль про лицензии.
Я хочу шлюз безопасности/фаервол не родной облачный, а продвинутый, возможно того же производителя, что использую on-prem.
В «железном исполнении» я привык гонять его в режиме High Availability (один активен, второй синхронизируется, готов мгновенно подхватить трафик без потерь сессий).
При этом один реально работает, второй «бездельничает».
Теоретически есть возможность сделать Load Sharing, но это и всякие мультикасты на сетевом оборудовании надо настраивать, и производительность отнюдь не пропорционально растет…
И вот прихожу я в облако, и думаю, какой бы режим мне выбрать — HA или VMSS?
По идее VMSS выгоднее. Если в HA я должен брать машину, чтобы в норме загрузка не превышала 50% (а 60-70% — это уже прям тревога), то в VMSS я вполне могу взять машинку помедленнее. Ничего страшного, если в случае отказа загрузка одного модуля составит 70, или даже 80%, оперативно же второй снова поднимется. А вот в обычном режиме загрузка каждого будет всего-то 35-40%.
Т.е. машинка слабее (дешевле), а загрузка даже ниже (т.е. меньше задержки...)
Теоретически есть доп плюшки (можно и третью легко добавить, при внезапном росте трафика а вот с HA так не сделать). Но сейчас речь не об этом.
И тут вспоминаем про лицензии.
При HA я приношу купленные BYOL. При VMSS действительно «лицензия включена в час работы».
Только вот если посчитать этот самый PAYG на год работы, окажется, что BYOL чуть ли не в три раза выгоднее. И повышенная стоимость PAYG не перекроет выгоду VMSS.
Я не спец по лицензированию. Я привожу примеры лишь нюансов, с которыми столкнулся на практике.
И, поскольку моя практика небогатая, я и подозреваю, что в реальности этих нюансов еще больше.
Например, может оказаться, что для Windows или SQL тоже существенно дешевле принести свою обычную корпоративную лицензию со скидками, нежели использовать «включенную в час работы».
С другой стороны уже сопровождать надо самому, а не Azure DB по модели PaaS.
Если же учитывать стоимость сопровождения по сравнению с PaaS, тогда и при сравнении экономической эффективности надо не только считать стоимость EC2 против собственного сервера, но и вот это вот все. Вплоть до портов на сетевом оборудовании.
Будет это делать админ, которому про между делом поручили прикинуть эффективность переезда?
Сомневаюсь.
Немножко резюмирая — какую бы вы позицию ни занимали (облако выгодно или облако не выгодно), я ни в коем случае не спорю.
Облако — не серебряная пуля. В каких-то случаях выгодно, в каких-то нет.
Я, скорее, утверждаю, что посчитать эту самую выгоду от переезда в облако для конкретной организации довлльно сложно. И уж тем более я бы не стал доверять результатам такого анализа, выполненного админом.
Если только в качестве неких исходных данных.
Немножко резюмирая — какую бы вы позицию ни занимали (облако выгодно или облако не выгодно), я ни в коем случае не спорю.как и все в этом мире. Я это и пытаюсь донести. И приводил примеры админу игрового сервера, который с пеной у рта кричал, что его игровой сервер уделывает все облака, но аргументов против облаков привести так и не смог )))
Облако — не серебряная пуля. В каких-то случаях выгодно, в каких-то нет.
Из ваших постов создаётся впечатление, что облако не выгодно только тем, кто не умеет его готовить по причине идиотизма. ) Ну или в каких-то совсем граничных случаях.
Из ваших постов создаётся впечатление, что облако не выгодно только тем, кто не умеет его готовитьв большинстве случаев да. Это же приминительно и к большинству ЯП/фреймворков/СУБД.
При этом я нигде не утверждал, что облака это прям серебрянная пуля и решение всех проблем. Конечно нет. Если у вас кривые sql запросы, база без индексов, а трудоемкая операция осуществляется за O(n^2) вместо O(n), то при переезде в облако индексы чудесным образом не появятся, запросы не оптимизируются и сложность с O(n^2) не станет O(n) ;)
Сколько было случаев, когда горе архитекторы начитались обзоров, что mongodb это стильно/модно/молодежно и вообще решение всех проблем, переводили продукты с sql на mongo и получали кирпичи. И потом кричали и писали гневные обзоры, что mongodb это вселенское зло.
Так же есть случаи когда содержание своего ЦОДа становится выгоднее, незря множество гигантов ушли с облаков.
Если резюмировать — прежде чем куда то переходить, необходимо как можно тщательнее изучить продукт. И это справедливо не только для облаков.
Да какая разница какие запросы и индексы? Есть приложение, успешно работающее на, например, bare metal или VDS. Но принято решение перевезти его на облако Amazon c целью сокращения операционных или капитальных (следующих периодов) затрат. Необходимости переписать всё приложение под cloud native не обозначено. Максимально использовать сервисы самого облако вместо уже развернутых self hosted тоже.
С какого перепугу техспециалист должен делать что-то больше чем перевод с вручную созданных дроплетов DO на вручную созданные инстансы on-demand EC2, если первые почти полные аналоги вторых, только дешевле? Кто должен уточнить задачу?
Да какая разница какие запросы и индексы?Очень даже большая разница. У вас локально оно крутится на 24 ядерном intel, а при переходе на 4х/8ми ядерную виртуалку на AWS все станет очень пичально. А виноват конечно же будет AWS.
Много раз сталкивался с подобным. Или когда DBA/developer говорит — а у меня локально все работает и даже быстро. Тебе что сложно добавить 100500 Гб памяти на виртуалке? Поэтому никто не заморачивается с какой то там оптимизацией
Необходимости переписать всё приложение под cloud native не обозначено.в большинстве случаев его и не надо переписывать. А вот оптимизировать, написать нормально — желательно. Смотри выше почему
С какого перепугу техспециалист должен делать что-то больше чем перевод с вручную созданных дроплетов DO на вручную созданные инстансы on-demand EC2, если первые почти полные аналоги вторых, только дешевле?у вас какое то странное представление о тех специалисте. При зп 5к$+ — да должен не только уметь запускать виртуалки на AWS/GCP
На продакшен сервере железном оно крутится на 16 ядерном интеле, EC2 такой же выбирается, я ж говорил про аналогичное железо.
5к$+ это мой аргумент против облаков — не должна зп специалиста по обслуживанию облачной инфраструктуры быть в разы больше чем экономия от перехода с железа к облаку в случае близком к идеальному. Грубо говоря, сейчас тратим 1000$ в месяц на железо и админ за 2500$ следит за ним. 5000$ в месяц человеку, который сумеет на облаке выжать пускай даже 500$ в месяц на те же задачи, выглядит несколько нерационально. Равно как и переход в облако силами имеющегося админа, если затраты с 500$ вырастут до $1500$ при той же за админа
На продакшен сервере железном оно крутится на 16 ядерном интеле, EC2 такой же выбирается, я ж говорил про аналогичное железо.Ну там есть нюансы и один в один нельзя так сравнивать. имхо. А при должной оптимизации вы могли бы взять 8ми ядерный, и получить экономию
5к$+ это мой аргумент против облаков — не должна зп специалиста по обслуживанию облачной инфраструктуры быть в разы больше чем экономия от перехода с железа к облаку в случае близком к идеальному.Если у вас 1-10 серверов, то скорее всего особого смысла не будет. А если сотни, то уже надо смотреть. Ну и условно специалист за 2к будет вам только виртуалки запускать, а за 5 уже будет находить и внедрять новые способы оптимизации инфраструктуры.
5000$ в месяц человеку, который сумеет на облаке выжать пускай даже 500$ в месяц на те же задачи, выглядит несколько нерационально.естественно, что такого спеца надо нагружать. Аналогично того же сервера, вы купили супер мощный сервер с запасом на будущее, так вот пока у вас он будет нагружен на 5-10%, по сути вы не рационально используете железо
Равно как и переход в облако силами имеющегося админа, если затраты с 500$ вырастут до $1500$ при той же за админано при этом у вас простой в год условно уменьшился на 100 часов. А час простоя у вас 1000$. Вот и посчитайте
А при должной оптимизации вы могли бы взять 8ми ядерный, и получить экономию
Считаем что уровень сотрудников от перехода в облако автоматом не растёт и если не было индексов, то облако их не сделает
Если у вас 1-10 серверов, то скорее всего особого смысла не будет.
Вот это вот гораздо ближе к реальной жизни чем всё, что вы писали ранее
но при этом у вас простой в год условно уменьшился на 100 часов.
А если на 2? С 3 до 1
Считаем что уровень сотрудников от перехода в облако автоматом не растёт и если не было индексов, то облако их не сделаетмы это уже обсуждали. Хотите экономить — нужно вкладываться.
Например, php 7 давал очень хороший прирост по сравнению с 5кой. На хабре даже была статья.
В итоге они вложились (переписали код с 5ку на 7ку) и получили профит. Если верить заголовку — экономия $1M. Кто хочет — тот делает, кто не хочет — ищет отговорки
Вот это вот гораздо ближе к реальной жизни чем всё, что вы писали ранееа у нас 100ни. А в тестах — тысячи. И что теперь
А если на 2? С 3 до 1либо вы что то делаете не так, либо облака не эффективны для вашей инфраструктуры. Все просто
В итоге они вложились (переписали код с 5ку на 7ку) и получили профит.
Я переписывал несколько проектов, но к экономии это не приводило явной. Отложило покупку новых серверов наверное, но это не точно. И причём тут облака?
Вы как-то с одного на другое перескакиваете постоянно. Сделать индексы, оптимизировать код, обновить софт — это нужно делать в любом случае, независимо от переезда в облака.
а у нас 100ни. А в тестах — тысячи. И что теперь
Не думаю, что у вас обычный проект. Только и всего. Молчу уж про Баду. Субъективно у подавляющего большинства компаний затраты на сервера меньше 1000 долларов. Даже если переезд в облака позволит снизить их раза в два, издержки на переезд окупятся ой как нескоро, если вообще окупятся.
либо вы что то делаете не так, либо облака не эффективны для вашей инфраструктуры. Все просто
Просто у нас почти не бывает простоев по причинам, которые закрывают облака. Ошибки кода или конфигурации облака не исправят, несовместимость при обновлении ОС на EC2 не выявят — тут процессы менять нужно для минимизации простоев, а не место размещения этого кода.
Я переписывал несколько проектов, но к экономии это не приводило явной. Отложило покупку новых серверов наверное, но это не точно. И причём тут облака?Вы то ли не читаете мои ответы или читаете по диогонали, то ли не понимаете смысла написанного ))
Вы как-то с одного на другое перескакиваете постоянно. Сделать индексы, оптимизировать код, обновить софт — это нужно делать в любом случае, независимо от переезда в облака.на железном сервере многое прощается, а вот когда за каждый ресурс вы платите деньги, тут же находятся методы и способы оптимизации ;)
Субъективно у подавляющего большинства компаний затраты на сервера меньше 1000 долларов.откуда данные? есть статистика?
Даже если переезд в облака позволит снизить их раза в два, издержки на переезд окупятся ой как нескоро, если вообще окупятся.инфраструктура это всегда про расходы
несовместимость при обновлении ОС на EC2 не выявят — тут процессы менять нужно для минимизации простоев, а не место размещения этого кода.не отменят, но позволят минимизировать простой. За счет использование тех же снепшотов/autoscaling group/availability zones/load balancer и т.д. и т.п.
Естественно если у вас час простоя ничего особо не стоит, а у некоторых и день простоя не критичен. То облака вам особо и не нужны.
У нас был например кейс — для POC нужна была сотня виртуалок (на пару часов в день) на день-два. Я думаю, ответ очевиден — что в таком случае облако позволяет очень сильно экономить. Про распределенное тестирование на 2-3к серверов вообще молчу
Вы то ли не читаете мои ответы или читаете по диогонали, то ли не понимаете смысла написанного ))
У вас мысли скачут, так что логической связи не видно )
тут же находятся методы и способы оптимизации ;)
Да они почти всегда на виду. Что там искать особо?
откуда данные? есть статистика?
Слово "субъективно" заметили или по диагонали читаете? )
инфраструктура это всегда про расходы
Некоторые перед тем как нести эти расходы прикидывают сроки их окупаемости.
За счет использование тех же снепшотов/autoscaling group/availability zones/load balancer и т.д. и т.п.
Про что я и говорю. Хоть какой-то технический смысл переезжать в облако есть, если кроме вложения ресурсов в собственно переезд, вкладывать ресурсы в дополнительные сервисы от этого же облака. Как разово — работы по исследованию, проектированию, подключению, настройке, обучению — так и постоянно, постоянно платя за использование.
У нас был например кейс — для POC нужна была сотня виртуалок
Опять вы про сотни серверов на пару часов. Тут-то всем понятно, кто не совсем в вакууме живет, что или облако, или постоянная переплата за эти сотни в резерве. Но задача необычная, и далеко не все даже с облаком её смогут решить за разумное время: времени на их создание может уйти на порядки дольше и пару часов только последний просуществует, а первый сотни возможно. Я ж говорю, сначала с процессами надо разобраться, а потом об облаке думать, если цель — экономия.
У вас мысли скачут, так что логической связи не видно )– Видишь суслика?
– Нет.
– Вот и я не вижу. А он есть. ( с )
Да они почти всегда на виду. Что там искать особо?практика показывает — что пока петух не клюнет, не особо то и находятся
Слово «субъективно» заметили или по диагонали читаете? )проехали
Некоторые перед тем как нести эти расходы прикидывают сроки их окупаемости.и в облаках все для этого есть, и даже больше
Опять вы про сотни серверов на пару часов. Тут-то всем понятно, кто не совсем в вакууме живет, что или облако, или постоянная переплата за эти сотни в резерве.я если что не в гугле работаю, а обычная продуктовая компания. Поэтому не вижу ничего сверх в такого рода задачах
Но задача необычная, и далеко не все даже с облаком её смогут решить за разумное время: времени на их создание может уйти на порядки дольше и пару часов только последний просуществует, а первый сотни возможнокакие часы, вы о чем вообще?! На terraform + ansible это все поднимается и настраивается за 15-20 минут
практика показывает — что пока петух не клюнет, не особо то и находятся
Не согласуется с
и в облаках все для этого есть, и даже больше
Или калькуляторы показывают верные сроки окупаемости и петух не клюёт, или счета превосходят ожидания и бросаются оптимизировать, чтобы их снизить
я если что не в гугле работаю, а обычная продуктовая компания.
Я тоже не в Гугле, а в обычной продуктовой — и десятка серверов не наберется на два страны присутствия. Мне бы больше хотелось, чтоб по уму всё сделать, но даже на 40$ в месяц траты увеличивать прокатывает только когда жареный петух клюнет.
какие часы, вы о чем вообще?! На terraform + ansible это все поднимается и настраивается за 15-20 минут
Я не один раз говорил, что процессы сначала надо выставить, а потом об облаках думать. Особенно в расчёте на задачи типа "надо сотни серверов на пару часов", а не "перевести 10 серверов в облако за минимальное время"
Или калькуляторы показывают верные сроки окупаемости и петух не клюёт, или счета превосходят ожидания и бросаются оптимизировать, чтобы их снизитькалькулятор и не может показать точную сумму расхода. Например вы не знаете какой трафик у вас будет. С помощью калькулятора вы можете прикинуть порядок цен. Например, вы запустили акцию и трафик возрос в 10 раз, вам пришлось увеличить кол-во инстансов на пару недель в 2-3 раза. Такое калькулятор вам не посчитает ;)
Если для компании +-1000$ это критикал — облака точно не для нее
но даже на 40$ в месяц траты увеличивать прокатывает только когда жареный петух клюнет.ну что тут сказать — вам не повезло
Особенно в расчёте на задачи типа «надо сотни серверов на пару часов», а не «перевести 10 серверов в облако за минимальное время»прежде чем переводить, надо ответить на вопрос — «Перевести чтобы что?»
Например, вы запустили акцию и трафик возрос в 10 раз, вам пришлось увеличить кол-во инстансов на пару недель в 2-3 раза. Такое калькулятор вам не посчитает ;)
От него это и не требуется, особенно если количество инстансов не увеличивать — пока согласуешь увеличение бюджета, уже и акция кончится :) Но вот задать все вопросы — должен, а не так что считаешь стоимость инфраструктуры для веб-приложения, а вопроса про трафик вообще нет, а потом ещё оказывается, что лоадбалансер за отдельные деньги нужен, чтоб вообще в мир выйти и тп
Если для компании +-1000$ это критикал — облака точно не для нее
Вот постепенно набираем критерии, когда облака противопоказаны:
+- 1000$ — критикал
нет спеца по облакам с зп 5000$
что ещё вспомните?
прежде чем переводить, надо ответить на вопрос — «Перевести чтобы что?»
Чтобы не уволили за невыполнение поставленной руководством задачи "перевести" )
а потом ещё оказывается, что лоадбалансер за отдельные деньги нужен, чтоб вообще в мир выйти и тпне поверите — но LB не нужен для выхода в мир, а public ip у них бесплатный, но если вы добавляете какой-либо сервис в свою инфраструктуру и даже не умудрились посмотреть цены на него — ССЗБ. Причем тут облака?
+- 1000$ — критикалцифра условная, я бы сказал так если для компании 500-1000$ критикал, то IT и уж тем более облака не для нее
нет спеца по облакам с зп 5000$спец по облакам не обязательно стоит 5к
Чтобы не уволили за невыполнение поставленной руководством задачи «перевести» )так пусть переводит, кто ж ему мешает
не поверите — но LB не нужен для выхода в мир, а public ip у них бесплатный,
Пример условный.
но если вы добавляете какой-либо сервис в свою инфраструктуру и даже не умудрились посмотреть цены на него — ССЗБ.
Речь не о неизвестной цене на момент добавления (хотя может оказаться сюрпризом что трафик платный с первого байта, например)
Речь о том, что некоторые сервисы могут внезапно оказаться практически бесполезными или неподдерживаемыми без некоторых других от того же вендора без возможности заменить их на "классические" свои.
цифра условная, я бы сказал так если для компании 500-1000$ критикал, то IT и уж тем более облака не для нее
Не согласен в части "ИТ". Компания может эффективно тратить на ИТ и по 30000$ в месяц, но это фиксированный бюджет, утвержденный собственниками/инвесторами на год. И увеличение расходов на серверную инфраструктуру до 1500$ в месяц с утвержденных 500$ могут привести к, например, сокращению одного джуна
спец по облакам не обязательно стоит 5к
Пускай 3, суть тезиса "для эффективного использования облачной инфраструктуры вам нужен специалист по облакам, одна зарплата которого может оказаться выше ваших текущих расходов на необлачную в разы, а без него просто расходы вырастут в разы"
хотя может оказаться сюрпризом что трафик платный с первого байта, напримертолько если не читать документацию от слова совсем
Речь о том, что некоторые сервисы могут внезапно оказаться практически бесполезными или неподдерживаемыми без некоторых других от того же вендора без возможности заменить их на «классические» свои.для этого — умные люди сначала делают анализ и изучают продукт. На основе комплексных данных анализа — принимают решение о возможности/невозможности миграции и ее целесообразности и эффективности.
Если же решение принимается на основе презентации или нам надо на вчера — ССЗБ
Не согласен в части «ИТ». Компания может эффективно тратить на ИТ и по 30000$ в месяц, но это фиксированный бюджет, утвержденный собственниками/инвесторами на год. И увеличение расходов на серверную инфраструктуру до 1500$ в месяц с утвержденных 500$ могут привести к, например, сокращению одного джунаесли речь об одном всплеске — никто никого не будет увольнять
Пускай 3, суть тезиса «для эффективного использования облачной инфраструктуры вам нужен специалист по облакам, одна зарплата которого может оказаться выше ваших текущих расходов на необлачную в разы, а без него просто расходы вырастут в разы»я админом без знания облаков получал не намного меньше, и это 5-7 лет назад в Харькове.
Опять таки если речь о 10 серверах, то условно облачный админ/архитектор/devops вам не нужен
Например, на одном из мест работы у нас было сотрудничество с wargaming, теми самыми, танчики все дела.
Так вот — одно из условий сотрудничества были облака, а мы на тот момент использовали hetzner. Причем облака не просто для галочки, а грамотная распределенная и отказоустойчивая архитектура, с подробным планом disaster recovery на случай полной смерти облака. Причем все это надо было показывать и объяснять.
Так что разные случаит бывают
только если не читать документацию от слова совсем
Документация касательно оплаты зачастую составлена так, что вводит в заблуждение, смотришь сколько платить за виртуалку, а там хорошо если ссылка будет на "трафик тарифицируется отдельно". То же с калькуляторами.
если речь об одном всплеске — никто никого не будет увольнять
Я о постоянном росте. Это результаты того самого анализа по переводу нашей инфраструктуры на AWS — трехкратный рост стоимости плюс-минус, если пользоваться managed сервисами типа mysql, двухкратный если тупо переехать на EC2
я админом без знания облаков получал не намного меньше, и это 5-7 лет назад в Харькове.
Ну так к обычному админу нужен будет ещё и облачный
Опять таки если речь о 10 серверах, то условно облачный админ/архитектор/devops вам не нужен
Да ладно не нужен, а кто будет определять, что в облако переносим, а что нет, потому что очень дорого получится, настраивать всё, интегрировать в имеющуюся инфраструктуру, пайплайны?
Документация касательно оплаты зачастую составлена так, что вводит в заблуждение, смотришь сколько платить за виртуалку, а там хорошо если ссылка будет на «трафик тарифицируется отдельно». То же с калькуляторами.Ничего там никуда не спрятано. Открываем — aws.amazon.com/ec2/pricing/on-demand и там прямо по пунктам
On-Demand Pricingеcли человек не в состоянии прочитать одну страницу и сделать выводы — он проф непригоден и дальше нет смысла дискутировать на тему — «А что если ...»
Data Transfer
Elastic IP Addresses
Elastic Load Balancing
…
Amazon Elastic Block Store
Я о постоянном росте. Это результаты того самого анализа по переводу нашей инфраструктуры на AWS — трехкратный рост стоимости плюс-минус, если пользоваться managed сервисами типа mysql, двухкратный если тупо переехать на EC2если компания постоянно растет, соответственно и рост расходов на инфраструктуру это нормально. В чем проблема?
Ну так к обычному админу нужен будет ещё и облачныйзачем?
Да ладно не нужен, а кто будет определять, что в облако переносим, а что нет, потому что очень дорого получится, настраивать всё, интегрировать в имеющуюся инфраструктуру, пайплайны?в нормальных компаниях уж точно не devops принимает такие решения ))
еcли человек не в состоянии прочитать одну страницу и сделать выводы — он проф непригоден
Анализировать цены вообще не входит в его обязанности.
если компания постоянно растет, соответственно и рост расходов на инфраструктуру это нормально. В чем проблема?
Я не о росте компании, я о том что затраты на инфраструктуру при переезде в вырастут не временно, а постоянно.
зачем?
Облачный сервисами облака заведует, обычный внутренностями тех же EC2. Девопс и опс, если угодно.
в нормальных компаниях уж точно не devops принимает такие решения ))
Девопс может оказаться самым квалифицированным техническим специалистом в компании. По крайней мере их тех, что что-то понимают в облаках.
Анализировать цены вообще не входит в его обязанности.его никто и не заставляет анализировать, а лишь собрать и предоставить данные ;)
Я не о росте компании, я о том что затраты на инфраструктуру при переезде в вырастут не временно, а постоянно.it depends
Девопс может оказаться самым квалифицированным техническим специалистом в компании. По крайней мере их тех, что что-то понимают в облаках.если да кабы… Я что то сомневаюсь что в условной фирме с одним девопс и 10ю серверами задумают переезд в облака.
Все конечно может быть — просто не вижу смысла рассматривать крайние случаи. Или случаи, когда фирма просто не созрела для облаков
его никто и не заставляет анализировать, а лишь собрать и предоставить данные ;)
Не совсем понял, что это означает.
«Просто собрать и предоставить цены» = «перевести написанное на сайте» (ну там же все это описано уже)?
Или прикинуть, во сколько обойдется переезд?
Если последнее, то нужно уже вникать в кучу тонкостей. Например, позволительно ли с точки зрения бизнеса использовать spot instance, поддерживает ли этот софт такой режим, сколько инстансов зарезервировать для сниждения цены…
Так-то калькуляторы «введи сколько и каких инстансов, сколько какого трафика и т.п.» у всяких AWS есть.
Не так-то просто решить, что туда вводить…
Если этот условный админ знает ответы на все такие вопросы, то, скорее всего потому, что и спросить не у кого, он один, чуть ли не эникейщик). И такой фирме облака — ну разве что базовый пакет а-ля AWS LightSale с понятной ценной.
А в более крупной организации такое собирать по разным службам надо. А они тоже ответа не знают, надо из них вытрясать.
Это проект получается, а не просто «ну-ка посчитай».
Не совсем понял, что это означает.консолидировать все данные и предоставить в удобном виде, для дальнейшего анализа
«Просто собрать и предоставить цены» = «перевести написанное на сайте» (ну там же все это описано уже)?
Так-то калькуляторы «введи сколько и каких инстансов, сколько какого трафика и т.п.» у всяких AWS есть.
Не так-то просто решить, что туда вводить…
но проще чем онпермис лицензии посчитать. попробуй посчитать онпермис лицензии оракла, там то калькулятора нет, а нюансов только по субд больше чем во всех сервисах облака.
Я что то сомневаюсь что в условной фирме с одним девопс и 10ю серверами задумают переезд в облака.
Задумать — легко ) Особенно, если где-то прочитают, что облака экономят деньги и делают ненужным админа
Задумать — легко )один раз обожгутся, в другой раз возможно и задумаются — а стоит ли и если стоит — то чтобы что ;)
О том и речь, что чтобы проект по переезду в облако считать успешным должно выполниться чуть ли не с десяток условий одновременно, если цель проекта не "нам надо переехать в облако, чтобы не выглядеть лохами, а понты дороже денег" "создать впечатление у клиентов/инвесторов, что мы в курсе современных трендов и не экономим на инвестициях в них". ))
Так ничего удивительного же, ровно наоборот — удивительно когда переезд в облака и затраты снизил, и надежность повысил, а не затраты увеличил, надежность снизил, зато "мы в тренде"
Это если грамотно и продумано. Когда идея "нам надо в облако" спускается сверху и имплементация ставится задачей человеку, который об облаках только маркетинговые или близкие к ним статьи читал, то хорошо если быстро получится.
Давайте не о сферических. Как сэкономить при, например, переезде с 10 серверами с вордпрессами (разные сайты, на каждом nginx+php-fpm+mysql) со средней нагрузкой в 50% и админом с ЗП в 1000$, ничего кроме LEMP не знающего особо? Переписывать — не вариант, отключать на ночь не вариант. На EC2 перенести можно, может MySQL вынести на Amazon RDS. Что ещё?
Давайте не о сферических. Как сэкономить при, например, переезде с 10 серверами с вордпрессами (разные сайты, на каждом nginx+php-fpm+mysql) со средней нагрузкой в 50% и админом с ЗП в 1000$, ничего кроме LEMP не знающего особо?в таком сетапе облако вам не нужно. Или как минимум не нужно, если ваша основная цель — сэкономить. А вот если простой любого из этих 10 сайтов стоит 1000$ в минуту — то уже надо смотреть, что и как
При зп 5к$+ — да должен(Улыбаясь)
Вот, пошли конкретные числа.
А то
(без облаков) операции требуют участия людей, а толковых всегда не хватает
(с облаками)
админов для поддержки нужно меньше
У инженеров освобождается время на развитие…
А тут ясно-понятно. Задумались об облаках: первое, что вы должны сделать, это нанять толкового специалиста за пять килобаксов.
Если бы, скажем, такая фраза прозвучала в обсуждаемой статье, много вопросов отпало бы сразу.
А тут ясно-понятно. Задумались об облаках: первое, что вы должны сделать, это нанять толкового специалиста за пять килобаксов.это ваши умозаключения, притянутые за уши )))
Не первое? Только когда счета и/или скорость работы неприятно удивят? )
Если серьезно, то дискуссия облака vs собственная инфраструктура ничем не отличается по смыслу от своего дома против съемной квартиры, или своей машины против такси — с минимальными поправками на специфику задачи.
Собственная инфраструктура — это собственный дата-центр? а лучше несколько, если один сгорит (
Ну и полный cloud native и собственные ДЦ — это крайности и всегда есть промежуточные варианты типа аренды (V)DS и построения инфраструктуры на них
Собственная инфраструктура — это собственный дата-центр?Если ваша компания доросла до масштабов собственного дата-центра — я полагаю, ее счета за какой-нибудь AWS устремляются к космосу гораздо увереннее Blue Origin.
А так все дело в модели использования, а она бывает разной. Тут везде рекламируют очень специфичную задачу, вам внезапно нужны сотни серверов на пару дней. Логично, это облачная задача. Пионерлагерю тоже нет смысла держать десять автобусов, чтобы использовать их три раза в год для заезда смены, и еще три для выезда.
Из этого не следует ненужность служебного автотранспорта вообще. И даже в пионерлагере еду и прочие простыни в прачечную могут возить на своем раздолбанном ЗИЛе.
Если ваша компания доросла до масштабов собственного дата-центра — я полагаю, ее счета за какой-нибудь AWS устремляются к космосу гораздо увереннее Blue Origin.расскажите это netflix
Netflix использует AWS практически для всех своих потребностей в области вычислений и хранения данных, включая базы данных, аналитику, механизмы рекомендаций, транскодирование видео и многое другое – сотни функций, которые в общей сложности используют более 100 000 серверных инстансов на AWS.и ничего, никто не разорился, чувствуют себя очень даже хорошо
расскажите это netflixЯ не вижу, как из цитированного вами следует, что netflix платит три копейки. Я подозреваю, что месячный чек netflix за AWS с легкостью отправит какой-нибудь средний бизнес в долговую яму на ближайшие пару веков.
Еще раз. Из статьи в статью кочуют стандартные рекламные штампы.
— Облака экономят ваши деньги
Нихрена. В общем случае облака — это дорого. Иногда, причем внезапно — шокирующе дорого. Но есть ситуации, когда они действительно экономят ваши деньги.
— Облака экономят вам специалистов
Нихрена. Вам нужен отдельный, и недешевый специалист хотя бы для того, чтобы облако внезапно не стало для вас шокирующе дорогим.
— Облака — это надежность
Нихрена. Вы попадаете в зависимость от чужой инфраструктуры со всеми вытекающими последствиями. Ваши инстансы могут удалить по ошибке (ваш админ тоже может накосячить, разумеется). Ваше облако может внезапно закрыться по своим внутренним причинам. Вас могут отключить или заблокировать по сугубо политическим резонам. Как Parler, или как службы AWS в России во времена телеграмомахии.
Но при этом есть куча ситуаций, когда облака действительно выгоднее. И вот если бы СММщики сосредоточились на этих ситуациях с проведением четкого различия между пользой и вредом: хотя бы как с рекламой лекарств — имеются противопоказания, проконсультируйтесь с врачом — вот тогда все эти замечательные статьи, которые я читаю уже много лет, перестали бы иметь столь отчетливый привкус, простите мой французский, налюбилова.
Я не вижу, как из цитированного вами следует, что netflix платит три копейки. Я подозреваю, что месячный чек netflix за AWS с легкостью отправит какой-нибудь средний бизнес в долговую яму на ближайшие пару веков.из моей цитаты следует как раз наоборот — 100к инстансов это как раз не три копейки. И как следствие опровергает ваше утверждение — «ее счета за какой-нибудь AWS устремляются к космосу».
Или вы считаете, что в компании такого уровня не умеют считать и при возможности экономии условно в 5-10 раз, как тут многие уже утверждали, правда без каких либо фактов, они не переехали бы в свой ДЦ?
Я думаю конечно бы давно переехали, но видать не все так однозначно, раз они до сих пор активно используют AWS ;)
из моей цитаты следует как раз наоборот — 100к инстансов это как раз не три копейки. И как следствие опровергает ваше утверждение — «ее счета за какой-нибудь AWS устремляются к космосу».А я вообще не вижу противоречия в этих двух фразах. Нетфликс может себе позволить оплатить космические счета — он их и оплачивает.
Или вы считаете, что в компании такого уровня не умеют считать(Терпеливо)
Если вы все-таки прочтете мой коммент до конца, в начале последнего абзаца вы найдете фразу «при этом есть куча ситуаций, когда облака действительно выгоднее» Я не вижу ни единого повода утверждать, что ситуация Нетфликса не попадает в эту кучу. И не утверждаю, что характерно.
Единственное, что я утверждаю — это то, что не все вокруг Нетфликсы, и отнюдь не все ситуации означают однозначную выгоду от использования облаков. Какую бы лапшу на уши не вешали их рекламщики.
Нетфликс может себе позволить оплатить космические счета — он их и оплачивает.нет. Это показывает, что облака позволяют экономить даже при таких масштабах. А привел лишь netflix для наглядности. Можете загуглить тысячи других компаний, которые используют облака. Следуя вашей логике получается что netflix сидит в амазоне и тратит миллионы потому что может, а не потому что это выгодно
Единственное, что я утверждаю — это то, что не все вокруг Нетфликсы, и отнюдь не все ситуации означают однозначную выгоду от использования облаков. Какую бы лапшу на уши не вешали их рекламщики.как и я утверждаю, что облака не для всех и они не панацея. Но тут же прибегает админ игрового сервера и начинает доказывать, что облака не выгодны от слова совсем
Следуя вашей логике получается что netflix сидит в амазоне и тратит миллионы потому что может, а не потому что это выгодно(Очень терпеливо)
Теперь вы пропустили второй абзац с конца в моем комментарии. Это в конце концов даже обидно: я думал, слова подбирал, понимаете...
как и я утверждаю, что облака не для всех и они не панацея.Тут мы с вами солидарны.
Но тут же прибегает админ игрового сервера и начинает доказывать, что облака не выгодны от слова совсемЕму с его задачами — скорее всего, да. Вас это удивляет?
Когда он станет СЕО нетфликса, тогда либо он пересмотрит свои взгляды, либо Амазону придется проститься с ежемесячными миллионами от нетфликса, или сколько он там получает.
Не вижу вообще никакой проблемы.
Нетфликс может себе позволить оплатить космические счета — он их и оплачивает.Это исходя из какого инсайда такой вывод?
нет. Это показывает, что облака позволяют экономить даже при таких масштабах.
Вполне может быть, что расходы в облаке условно, на 20% выше. Но другие преимущества (масштабирование по запросу, time-to-market и т.п.) позволяют зарабатывать на 70% больше.
Но это не экономия. Облако не дешевле.
Это выгода от умения считать и использовать дополнительные преимущества, появляющиеся при использования облака.
Когда дополнительные затраты перекрываются полученными преимуществами.
Тупой пример — таксист купил более дорогое авто, и теперь оказывает услуги Комфорт+ вместо Эконом.
Оно может быть выгодно.
А если кто-то не сможет этим воспользоваться, и не сможет зарабатывать больше — ну сорян.
Но говорить, что новое авто высокого класса «позволяет экономить» странно.
Вполне может быть, что расходы в облаке условно, на 20% выше. Но другие преимущества (масштабирование по запросу, time-to-market и т.п.) позволяют зарабатывать на 70% больше.это и есть экономия :D
Но это не экономия. Облако не дешевле.
Например затраты на AWS — 1 kk$ в месяц, а свой ДЦ — 250k$. Но в свой ДЦ вам надо нанять еще 100 техников только для обслуживания серверов. А еще десяток DBA, десяток developer'ов + qa + managers, которые будут писать web gui и rest api, а еще не забываем про саппорт.
Итого ~150 человек обслуживающего персонала, со средней зп 5000$ в месяц (и это я еще очень скромно по зп). Итого: 250к + 750к = 1кк. И это мы еще не посчитали расходы на офис, корпоративы, печеньки и головняк с увольнениями и т.п.
И в итоге мы получаем, что облако таки выгоднее. И позволяет тебе полностью сконцетрироваться на решение бизнес задач, а не борьбе с оборудованием и прошивками. Что в итоге ведет к экономии расходов ;)
В US проблем с увольнением сотрудников нет никаких.
Я правильно понимаю, что могу уволить всех админов и девелоперов с менеджерами, взять AWS… и софт в нем будет разрабатываться и наполняться фичами сам?
Конечно можете, как только объясните взаимосвязь между облачной инфраструктурой и написанием кода :D
В US проблем с увольнением сотрудников нет никаких.
Я нигде не утверждал, что они есть. А вот найти хорошего спеца в US все так же хлопотно, как и у нас. А теперь умножьте это на 150 ;)
Например затраты на AWS — 1 kk$ в месяц, а свой ДЦ — 250k$. Но в свой ДЦ вам надо нанять еще 100 техников только для обслуживания серверов. А еще десяток DBA, десяток developer'ов + qa + managers, которые будут писать web gui и rest api, а еще не забываем про саппорт.Или вы предлагаете их задействовать для написания софта для работы с системами в своем ДЦ? Но зачем? Система виртуализации уже все умеет, инструментов управления ко всему этому буран. терраформам, ансиблам и кубикам совершенно всеравно где все находится, в облаке или на земле.
Что вот же? Это только обслуживающий персонал, чтобы ваш ДЦ работал. А софт у вас будут писать другие люди. И да, терраформ не заработает в вашем ДЦ, пока не напишите своего провайдера, а это время и деньги.
Система виртуализации стоит много денег, а из бесплатного мало функционала. У нас же речь шла о 100к виртуалках. Еще забыл добавить отдельную группу обслуживания систем хранения данных. Емс всякие, а там цены очень кусаются и bash скриптом уже не обойтись :D
Плюс еще обслуживающий персонал самого ДЦ — электрики, сантехники, охраники, уборщики и вот это вот все. Еще +50 людей. Все еще хотите свой ДЦ и считаете что он намного дешевле и выгоднее? :D
— Облака экономят ваши деньгиопыт netflix и других показывает, что таки экономит. Иначе они уже давно уехали оттуда
Нихрена. В общем случае облака — это дорого. Иногда, причем внезапно — шокирующе дорого. Но есть ситуации, когда они действительно экономят ваши деньги.
— Облака экономят вам специалистовв большинстве случаев да, ибо если вам нужна СУБД, то вам не надо нанимать крутого DBA
Нихрена. Вам нужен отдельный, и недешевый специалист хотя бы для того, чтобы облако внезапно не стало для вас шокирующе дорогим.
— Облака — это надежностьа при своем ДЦ что то меняется?
Нихрена. Вы попадаете в зависимость от чужой инфраструктуры со всеми вытекающими последствиями.
Ваши инстансы могут удалить по ошибке (ваш админ тоже может накосячить, разумеется). Ваше облако может внезапно закрыться по своим внутренним причинам.Так то и MS/Google/Apple/etc могут внезапно закрыться, но вероятность этого --> 0
Вас могут отключить или заблокировать по сугубо политическим резонам. Как Parler, или как службы AWS в России во времена телеграмомахии.просто надо подальше держаться от политики в любом государстве
ибо если вам нужна СУБД, то вам не надо нанимать крутого DBAА когда не-крутой ДБА напишет кривой запрос и сожрет 100500 денег на процессорное время, вы опять элегантно разведете руками и скажете, что хотите экономить — нужно вкладываться?
а при своем ДЦ что то меняется?Мне немножко неловко говорить очевидные вещи, но да.
Одни угрозы исчезают, другие появляются.
Так то и MS/Google/Apple/etc могут внезапно закрыться, но вероятность этого --> 0Так-то да.
Только вероятность закрытия MS и вероятность того, что лично вам MS услугу более не предоставляет — это две очень разных вероятности.
Я могу умереть, а могу не придти чинить вам компьютер. Вероятность первого события на завтра достаточно невелика, зато второго — строго единица. Не надо их смешивать.
просто надо подальше держаться от политики в любом государствеДа, желательно не попадать с политикой в один диапазон IP.
А когда не-крутой ДБА напишет кривой запрос и сожрет 100500 денег на процессорное время, вы опять элегантно разведете руками и скажете, что хотите экономить — нужно вкладываться?один раз оббожетесь, в следующий раз будете тестировать прежде чем выкатывать в прод. А на стадии POC так и вообще часто бывает не нужны DBA, но нужен грамотно настроенный СУБД
Мне немножко неловко говорить очевидные вещи, но да. Одни угрозы исчезают, другие появляются.в результате условный 0
Только вероятность закрытия MS и вероятность того, что лично вам MS услугу более не предоставляет — это две очень разных вероятности.если мы не касаемся политики или каких то противозаконных вещей — то вероятность этого одна и та же и она --> 0. Или есть конкретные примеры, когда AWS/GCP/MS прекращали предоставление услуг без причин?
один раз оббожетесь, в следующий раз будете тестировать прежде чем выкатывать в прод.То есть, крутой ДБА все-таки нужен.
И спец по собственно облакам тоже.
Какие еще ненужные специалисты нужны при переходе в облако?
не нужны DBA, но нужен грамотно настроенный СУБДЭта проблема тоже решается совсем необязательно облаками.
в результате условный 0Мне еще более неловко вам говорить, что конечно же нет, и что компании уровня нетфликса решают связать свою судьбу с облаками — а компании уровня ФБ строить свои датацентры не путем подкидывания монетки в воздух, как было бы при условном нуле.
В разных обстоятельствах может быть выгоднее облако или свой ДЦ.
Или есть конкретные примеры, когда AWS/GCP/MS прекращали предоставление услуг без причин?Я вам напомню, что когда РКН блокировал телеграм по всему интернету, пулы адресов публичных облаков под раздачу попадали только так. AWS вроде бы и не отказывала в обслуживании, вот только заблокированным клиентам было не легче.
А уж ситуации, когда более мелкие облачные провайдеры внезапно меняли условия/закрывались, они довольно штатные вообще-то.
Хотя произошедшее с Parler мне все равно видится гораздо показательнее — и чоужтам, страшнее.
Или есть конкретные примеры, когда AWS/GCP/MS прекращали предоставление услуг без причин?
Смотря что считать причинами. Санкции США — это причина?
В «железном исполнении» я привык гонять его в режиме High Availability (один активен, второй синхронизируется, готов мгновенно подхватить трафик без потерь сессий).и причем тут облака? Нужна железка, а не виртуалка — они у них есть. Ну и какое отношение имеют способы лицензирования хитрых продуктов к облакам?
При этом один реально работает, второй «бездельничает».
High Availability или VMSS — это варианты создания «кластера» шлюзов безопасности в виде «виртуалок в облаке».
В железном исполнении было бы High Availability и Load Sharing, к примеру.
Впрочем, нет смысла разбираться с конкретным кейсом. Если уж конкретный нюанс вылез, значит могут быть и другие, и с другим софтом.
В разделе People Perspective. Вообще весь CAF — очень толковая штука.
в случае проблем с железом тех. поддержка отвечает за 10-30 минут, довольно подробно отвечают в случае проблем.
Ну да, конечно. Рассказывайте какой классный сапорт у hetzner и как быстро они реагируют. Я за 5 лет нахлебался. До сих пор хватает.
За свои деньги они хорошие. Но когда у вас простой 15-30 минут неприемлим, то с hetzner вам точно не по пути. Единственный выход на хецнере — дублировать все, что только можно. Но это все равно вас не защитит от ситуаций, когда у них весь дц валяется. За 5 лет раза 3-4 точно сталкивался с таким на хецнере
Сапппорт в hetzner не классный, но он в разы лучше ботов в амазон. Да весь дц может стать недоступен, как и az в амазон, что я тоже наблюдал. Что в амазон, что в hetzner надо все дублировать в разных az/дц.
Согласен, если нужна хорошая надёжность и sla 99.999 то с hetzner не по пути
Мне не нравится что в статье категорично сравнивают две крайности облако и свой цод.
В том же hetzner стоковые железки ты получаешь через 15 минут после заказа. Если надо автоматически быстро масштабироваться, берёшь у них же виртуалки через api.
Также мне не нравится что всегда говорят облако дешевле, но реальных цифр не приводят. Потому что мои подсчёты на конкретном кейсе говорят об обратном. Наверняка есть кейсы когда облако действительно дешевле, например при сочетании маленьких нагрузок и очень сложной инфраструктуры, когда за обслуживание инфраструктуры бизнес платит больше чем за саму инфраструктуру. То есть хотелось бы не маркетинга, а истории вот мы перешли в amazon с servers.com, с экономили 20 000$ на таких-то вещах. Или подробный и честный разбор всех нюансов. Просто сейчас складывается ощущение, что в сообществе априори облака считаются дешевле, а если ты начинаешь разговор об этом, тебя считают маргиналом.
P. S. Промахнулся ответом, извините.
Плюсы по сравнению с любым облаком/хостингом:
+ «Пакет услуг» (набор и настройка ПО, вычислительные мощности) определяем самостоятельно, а не выбираем между тарифами
+ Спокойно заводим очень и очень специфичное ПО, с которым на том же VPS было бы весьма проблематично
+ Из ежемесячных расходов лишь электроэнергия и безлимитный интернет со static IP. Ваши облака тратят всё это же плюс штат менеджеров, техподдержки и техобслуживания, а также денёжка в широкий карман хозяина вот этого всего заведения. В нашем случае, правда, ещё скоро сисадмин прибавится (своих рук уже не хватает).
+ У облака огромный и толстый болт на проблемы клиентов. Нравится — базируйтесь и платите, не нравится — скатертью дорожка. У нас непосредственный интерес содержать бесперебойные сервера, что случись — за 6 часов всё верх дном перевернём. Не представляю, что должно произойти, чтобы также активно работал техперсонал облака. Разве что повалившийся ЦОД, но никак не 1-2 клиента.
+ Финансовая безопасность. Один косячный бесконечный цикл на облаке и счёт в пару десятков тысяч долларов вместе с пожизненным рабством обеспечен. Локально — от небольшого перебоя в работе до погоревшего железа, без всякого рода штрафов и прочего.
Мы на игровом ПК сервер держим, ничего, прекрасно работает
Ну началось. Сейчас начнут писать — а у меня сайт на малинке. Зачем мне ваши облака.
А SLA у вас есть? А сколько времени уйдет на замену cpu/ram/бп/etc? А сколько интернет каналов? А если через час мне надо будет еще 100 серверов, за сколько вы их поставите и настроите? А через день-два они мне будут не нужны. Что будете с ними делать? А ups есть? А сколько времени продержит? А генераторы есть, если мне надо 24х7?
Мне продолжать?
1) Речь о сравнении стоимости обслуживания
2) В облаке они не с неба падают, техперсонал ставит такие же сервера. А содержание простаивающих (как раз на случай, если клиент срочно 100 серверов захочет), огорчу вас, входит в эту же цену. Увы, деньги, как и сервера, тоже с неба дождём не летят.
3) В SLA пока нужды не было
4) Если за час нужно перейти с ПК на 100 серверов, это под сколько тысяч процентов рост потребностей должен произойти?) Полагаю, вместе с потребностями появились и денёжки, придётся раскошелиться и чутка подождать. В долгосрочной перспективе выгода обеспечена. А если деньги не появились, то о сотне облачных серверов и мечтать не стоит.
Если проводить аналогию с бытовой жизнью, Вы сейчас сравниваете съёмную квартиру и собственную, как думаете, что можно получить здесь и сейчас, а что хорошо и на долго?
Просто вы пытаетесь натянуть сову на глобус. И зачем то интерполируете свой опыт с одним сервером на облака. А облака это про другое
Речь о сравнении стоимости обслуживанияэто вы так захотели? А для меня важны — удобство/скорость/гибкость/надежность/масштабируемость. Вам рассказать на каком месте будет ваш игровой сервер?
Сколько будет стоимость обслуживания, когда парк выростет до 10/100/1000 серверов?
В облаке они не с неба падают, техперсонал ставит такие же сервера. А содержание простаивающих (как раз на случай, если клиент срочно 100 серверов захочет), огорчу вас, входит в эту же цену. Увы, деньги, как и сервера, тоже с неба дождём не летят.откуда дровишки? Можно пруфы?
В SLA пока нужды не былоНет, давай до свидания. Как только будет SLA — мы поговорим
Полагаю, вместе с потребностями появились и денёжки, придётся раскошелиться и чутка подождать.пару месяцев? :D Мне нужно через час. Обеспечите? Нет, давай до свидания. А для одного теста на пару часов мне нужно 10 arm серверов. Через полчаса сможете обеспечить?
долгосрочной перспективе выгода обеспечена.через день они мне будут не нужны. Деньги вернете за 99 серверов?
Если проводить аналогию с бытовой жизнью, Вы сейчас сравниваете съёмную квартиру и собственнуюаналогия вообще не к месту. Вы про car sharing слышали? Вот это и будет аналогия
P.S.
без обид, но когда человек с одним сервером начинает рассказывать как все удобно и классно и дешево, то просто смешно становится. В прошлом году проводили распределенно масштабное тестирование продукта (репликация, все дела). В пиках количество нод было ~3000. Как думаете сколько стоило бы такое тестирование на железках и сколько заняла бы подготовка?
Сколько будет стоимость обслуживания, когда парк выростет до 10/100/1000 серверов?
Не выше, чем те же 100 серверов на облаке.
откуда дровишки? Можно пруфы?
Пахнет очень жирным байтом. На содержание любой техники требуется n-ная сумма денег. Сомневаюсь, что найдётся добренький дяденька, который просто так будет за свой счёт её вносить. Первый приходящий в голову пруф — «Основы экономических знаний» Любимова, глава 2 (Микроэкономика).
аналогия вообще не к месту. Вы про car sharing слышали? Вот это и будет аналогия
Одно и то же. И в случае с серверами, и в случае с каршерингом, и в случае с недвижимостью Вы или берёте на «попользоваться», принимая все условия и ограничения в обмен (условия пользования сервером/авто, условия проживания и ремонт в квартире), но зато сразу быстро, или настраиваете всё под свои требования, это дольше, но дешевле в долгосрочной перспективе.
Серьёзно, от Вас за 30 километров байтом несёт. Вам говорят, что очевидно дешевле содержать своё, Вы говорите что очевидно быстрее платить за право пользование? С биноклем ищу логику Ваших аргументов и связь с моими.
И для кого я там букАвы какие-то напечатал непонятные, неизвестно…набор букв — еще не есть аргумент. Хотя возможно для вас и есть
Текст предыдущего сообщения содержал в себе те самые аргументы, которые Вам, увы, развидеть не удалось. Причины могут быть самые разные, от весьма печальных до банального нежелания читать, но факт остаётся фактом.
Текст предыдущего сообщения содержал в себе те самые аргументы, которые Вам, увы, развидеть не удалось.
Потому что их там нет, от слова совсем :D
Что ж, просвещу. Буквы объединяются в слоги, слоги — в слова, слова — в словосочетания и грамматические основы, словосочетания и грамматические основы — в предложения, предложения — в абзацы, абзацы — в текст
Если я сейчас процитирую часть 'Война и мир' — это будет аргументом? Следуя вашей логике — будет. А я считаю что не будет. Дальше нет смысла продолжать с вамт беседу
Я же посоветовал не весь учебник (хотя для общего развития не мешало бы), а конкретную его главу, которая от начала и до конца отвечает на столь очевидный вопрос с точки зрения микроэкономических законов. Полагаю, Вас опять смутило "многа букаф".
Если объяснять на уровне "чтобы даже школьнику было понятно" (я не называл Вас школьником, не надо поднимать бучу), всё в этом мире стоит денег, и все расходы покрываются доходами. Откуда у облачного сервиса доходы, которыми можно покрыть расходы содержание простаивающих серверов? Верно, из карманов клиентов. Так что Ваше право требовать "чтобы через час 100 серверов выделили" по умолчанию уже включено в стоимость тарифа. За подробностями, опять же, посылаю в учебник, т. к. в противном случае объяснение вытянется на 10-20 страниц текста.
к 20 для чего люди ставят пожарную систему, к 24 годам что жечь 24х7 виртуалку невыгодно, на фоне SaaS.
«Облака были созданы, потому что все задолбались»: в чём отличие облачной инфраструктуры от своих серверов