Спускаемся с небес: давайте просто посчитаем?

Нет, мы не говорим, что этот пост — руководство к действию :) Мы предлагаем задуматься, а не просто использовать калькулятор Amazon. Речь идет о том, чтобы задействовать дополнительный ресурс или хотя бы учитывать его, если не в построении инфраструктуры, то по крайней мере для её диверсификации.
Почему выбрали пример на AWS? Просто потому что этот вариант доступен и для него есть готовый калькулятор. Но даже с AWS облако бывает куда выгоднее. Для конкретных задач, конечно, нужно проводить расчеты с рядом потенциальных поставщиков сервиса. AWS в данном случае, так – первая прикидка.

Как упоминалось в посте, наш расчёт очень «сфероконичен». Это только пример. Можно посчитать процессорное время по тем же нормативам, что и дисковое пространство, накинуть время для загрузки данных, например, если из творческого порыва их вдруг захочется не генерить скриптом, а заливать все два-три терабайта каждый раз. Но даже при этом стоимость облака останется более привлекательной в сравнении с железкой.

Но ведь и ситуация, когда под задачу требуется один хост без обвязки, по нынешним временам скорее атипична, поэтому в реальности, скорее-всего, расчет будет посложней (как минимум, может потребоваться vpn в контур разработки). В случае построения частного/гибридного облака затраты для большинства сценариев будут отличаться в большую сторону, по сравнению с облаком публичным, и не факт, что будут оправданы для одной ВМ. А с точки зрения квалификации персонала на внедрение и сопровождение, если рассматривать вариант с частным облаком на инфраструктуре сервис-провайдера, то планка требований может оказаться заметно ниже, чем при организации и сопровождении эквивалентной инфраструктуры на своих мощностях.

Конечно, сложно не согласиться с тем, что при оценке возможности использования облачных решений следует рассматривать все их грани с учётом характерных им особенностей. Но мы не ставили задачу посчитать все «от и до». Мы хотели показать, как быстро прикинуть стоимость одного сервиса – для собственного понимания или для аргументации руководству.

Подразумеваются слабые кадры "на местах". Облаком управляют сотрудники IaaS провайдера (зачастую работающие из Москвы и СПб), да, криворучки попадаются и там, но если провайдер заботится о своей репутации и качестве оказываемых услуг, то и инженеров/саппортёров будут набирать квалифицированных и платить им хорошо, чтобы не "вымывались".

А если говорить про какую-нибудь крупную, но региональную компанию (то есть НЕ МТС, Альфа-банк и т.д.), то возможностей найти хорошего спеца и хорошо ему платить при этом у нее будет куда меньше…

Позвольте с вами не согласиться. Сопровождение зоопарка железа, сервисные контракты, ЗИП, инфраструктурное ПО, резервное копирование – весь этот слой и сопутствующая головная боль передаются (не безвозмездно) сервис-провайдеру. Кроме того, на местах, как правило, наблюдаются низкие зарплаты и высокая текучка кадров, особенно, если таковые действительно оказываются квалифицированы. То есть затраты на обучение оказываются постоянными. Кроме этого требования к информационной безопасности могут сопровождаться проверками соответствия этим требованиям. А это значит, что понадобятся существенные вложения в собственную инфраструктуру, в персонал. На этом фоне при использовании типичных консолей облачных сервисов, сопровождение оказывается более-менее тривиальным и требует минимального времени на освоение.

Не отрицая национальных особенностей, можно утверждать, что в нашей стране есть живые примеры, когда разработку выводят в облака, и их – немало. Если вы внимательно читали пост, то, наверное, заметили, что из 3 серверов с разными ролями мы допустили перевод в облако только разработки… поэтому рассматриваемый пример — вполне себе жизненный.

Но если уж зарываться в тему отношения к хранению критичной информации, как сдерживающего фактора для активного использования облачных решений, то со стороны операторов уже есть предложения сервисов, соответствующих по защите требованиям ФСТЭК и ФСБ. А при реализации должных мер защиты на уровне СУБД/серверов приложений, их расположение становится непринципиальным. Другое дело, что под такой сценарий программный стек должен проектироваться изначально. И поэтому мы пока предлагаем посчитать только машину разработчика/тестировщика. Остальное требует более детальной оценки.

По цене спорить сложно, хотя стоимость сервера взята из GPL, отпускная будет скорее-всего ближе к 20000$. Но оставим его в покое – действительно, сервер noname будет дешевле в двое. А когда надо «здесь и сейчас», а бюджет не резиновый (в примере из нашего поста таких серверов требуется три), то возможны варианты. Отобьётся ли он за год? Сомнительно. Хотя, просим расчеты в студию, если у вас своя точка зрения)

Мы не стремились рассматривать все возможные конфигурации и разводить эдакое многостраничное исследование, которое с большой вероятностью всё равно будет не полным. Суть поста в том, что облачные решения вполне применимы и могут использоваться и в качестве «костыля», и для растягивания или даже замены собственной инфраструктуры. Взяли для этого калькулятор – открытый и доступный. Вот и все.

К слову, чем содержать админа, пусть даже лишь изредка приходящего на свой пост, а также тратиться на закупку и поддержку самосборных серверов и СХД, лицензиями на инфраструктурное ПО, неопределённостью с резервными копиями и при этом отсутствием представления, что с этим всем делать, если, например, безвозвратно выйдет из строя какой-либо из аппаратных компонентов, малому бизнесу вполне имеет смысл посчитать, а сколько будет стоить то же самое в облаке, расписав для себя плюсы и минусы по обоим вариантам. Никто же не говорит «берите облако». Речь идет о «давайте посчитаем»)