Pull to refresh

Comments 12

Отказались от ec2 в сторону обычных VDS — значительно упали затраты, в гибкости не проиграли — т.к. раньше нужно было следить за парком в 30-40 виртуальных машин, а сейчас их работу спокойно выполняют 10 VDS, и намного быстрее, т.к. вычислительные мощности стали больше.

Да и вообще — что такого есть в облаках, что не может выполнить обычный VDS дешевле и быстрей?
crmMaster На самом деле, я бы сказал, что «облако» — это хороший маркетинговый термин. Более того соглашусь, что железный VDS быстрей чем виртуальная машина в облаке, но вот есть пару нюансов как использовать. Основное преимущество «облака» этого его апи, с помощью которого можно гибко управлять флотом машин, к примеру: когда надо добавить цать машин по необходимости или убрать когда нет смысла держать простаивающие машины, т.е. когда нужна эластичность. В случае, если эластичность и географическая распределенность не нужна и мы говорим о статической среде, то да, тут VDS может быть отличным решением.
> А что делать с серверами, если кризис случился и надо свернуть бизнес?
«Если случиться кризис» — это самый мощный аргумент за покупку своего оборудования или вечных лицензий на софт и самый мощный аргумент против модели подписки.

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

Оборудование тоже можно оптимизировать в кризис — перестать покупать продление поддержки, которые на брендовое оборудование стоят немало, перестать покупать новые версии софта и работать на старых, возможностей которых во многих компаниях достаточно на 98% и т.д.
phprus Соглашусь с вами, но сразу могу сказать, что если говорить про публичные облака аля амазон или ажур, то когда принимается решение развернуть там инфраструктуру надо предусмотреть сценарии действий, на случай потери данных или отключения. Если этого не сделали — то сами виноваты. Кстати микрософт и амазон об этом предупреждают и даже кучу практик публикую. Поэтому, когда принимается решение идти в публичное облако надо учитывать риски и готовить план действий на случай наступления рисков.

Ну и кстати, облака бывают не только публичные, но и компании вполне могут создать частное облако у себя и таким образом выжать из сервером по максимому.
> когда принимается решение развернуть там инфраструктуру надо предусмотреть сценарии действий, на случай потери данных или отключения
Конечно! Но покупаясь на цену многие об этом забывают, хотя в случае кризиса и отсутствия возможности платить потеря данных в облаке 100%-я. Кроме того возникает необходимость оценки затрат на такое резервирование и вопрос выгодности даже в терминах CapEx-OpEx становится значительно менее однозначным.

> облака бывают не только публичные
Частные облака — это не финансовый инструмент по превращению CapEx в OpEx и увеличению рисков, а исключительно техническо-организационное решение о распределении доступных ресурсов по задачам. Можно сервер на задачу выделять, можно виртуальную машину, можно процесс в контейнере и т.д. и все это может быть приватным облаком.
Ну и забыл добавить, оптимизировать в кризис можно дейстивительно по разному: можно использовать что есть, можно продать, можно просто подписку отменить. Тут кому как удобней на самом деле.
Подписку на сервис, который *aaS, а не который техобслуживание серверов, например, отменить будет нелегко и чем сильнее на это *aaS завязан бизнес, тем сложнее. Я уже много раз слышал о том, что это было одним из аргументов против использования модели «as service» на основных направлениях.

Еще один аргумент я часто видел в контексте ПО — а нужны ли обновления, которые которые даются в подписке, если для многих задач ПО десятилетней давности работает ни чуть не хуже самого современного, а покупка вечной лицензии дешевле, чем десять лет подписки.
Облака = дешевле. Единственная причина популярности.
</дискуссия>
Вот это спорное утверждение, что дешевле, они скорей дороже.
В глубоком внедрении под большой нагрузкой — да. В начале — дешевле. Простой вопрос — заданные ресурсы вы на облаке получите за сколько? А в коло/дедиках?

Порог вхождения ниже = дешевле при первичной продаже.
Про CAPEX и OPEX — это набор клише из периода «начальной пропаганды облаков» в 2010 году. Вроде сейчас его уже перестали повторять, хотя бы потому, что с таким обоснованием можно дойти максимум до фин.директора. А дальше он вам объяснит, что вы в «капексах», «опексах» и фин.менеджменте ничего не понимаете.
Все сильно зависит от реальных целей компании, которые айтишник вполне может и не знать.
Классический пример от cisco — вам (не вам, конечно, а владельцам) надо увеличить капитализацию компании. Это можно сделать в т.ч. прикупив дорогостоящего оборудования и повесить его на баланс предприятия.
Другой пример — у нас образуется прибыль (какое счастье) и нам надо платить налог на прибыль. А может лучше инвестировать в основные средства?
Отдельно вопросик на тему «а давайте посчитаем расходы на 5 лет с учетом ставки дисконтирования». Посчитав это мы неожиданно можем выяснить, что MS Lync в облаке уже через год-два аренды обходиться дороже, чем свой собственный. А когда в 2011 я по подобной схеме посчитал Exchange, то у финдиректора был один вопрос «А зачем вы пытаетесь вытянуть из компании дополнительные деньги»?
И это только часть ньансов в рамках которых никакого безусловного приоритета OPEX над CAPEX не наблюдается…
Думаю что тут надо глубже нырять в бухгалтерию и финансы отдельно взятой страны, чтобы считать выгодно или нет на облако.
Sign up to leave a comment.

Articles