Первые 5 "ЗА" очень звучат как "Против". Нужно учесть, что корпоративный клиент или выберет нормального интегратора или будет иметь возможность создание полноценной сервисной службы для создания частного облака. Также стоит учесть, что на базе СПО продуктов, готовятся множество дистрибутивов, которые являются законченной платформой.
| Первый довод “против”: якобы слабая техническая поддержка Клиенты, решившие создавать облака с открытым исходным кодом, используя полностью открытое ПО, попадут в зависимость от соответствующих проектов с открытым исходным кодом в плане технической поддержки. Поддержка будет оказываться в форме краудсорсинга — через форумы, чаты IRC, перечни вопросов и ответов или журналирования дефектов системами выявления ошибок. Пользователям придется стать активными членами сообщества и вносить свой вклад в развитие проекта. В мире патентованного коммерческого ПО в этом нет необходимости. С другой стороны, клиенты могут выбрать для создания облаков коммерческое открытое ПО. В этом случае слабости технической поддержки будут не столь ощутимы. |
Второй довод “против”: привязка к определенному производителю Каким образом пользователь может оказаться привязан к определенному производителю, если среди доводов “за” мы говорили об отсутствии такой привязки? Некоторые пользователи могут предпочесть комфорт и безопасность, которые они получают, если полагаются на решение одного производителя, а также на его услуги в вопросах технической поддержки, тестирования и интеграции системы. Клиенты могут обладать опытом работы с одним патентованным решением и, расширив свой выбор, запутаться, что в действительности приведет к замедлению осуществления стратегических проектов из-за отсутствия необходимого опыта. |
| Третий довод “против”: затраты Верно, что облака с открытым исходным кодом дают существенную экономию на лицензионных отчислениях по сравнению с конкурирующими патентованными решениями. Но есть и другие “мягкие” затраты, которые невозможно игнорировать. Для обслуживания инфраструктуры облаков с открытым исходным кодом могут потребоваться штатные опытные разработчики и администраторы. Кроме того, может возникнуть необходимость в привлечении консультантов или программистов со стороны. |
| Четвертый довод “против”: незрелость технологий Поскольку экосистема облаков с открытым исходным кодом продолжает развиваться, клиенты могут усомниться в зрелости проектов с открытым исходным кодом. При создании открытого облака выбор технологии, сделанный менеджером сегодня, в будущем может стать преследующим его кошмаром. В условиях конкуренции различных проектов с открытым исходным кодом и при наличии множества вариантов выбора обычному клиенту трудно разобраться, в каком направлении следует двигаться. |
| Пятый довод “против”: оно того стоит? Пользователи хотят, чтобы облачная инфраструктура обладала высокой доступностью, была простой в использовании и достаточно подвижной, чтобы развиваться в ногу с бизнесом. Прежде чем создавать облачную инфраструктуру (на основе решений с открытым исходным кодом или проприетарных), необходимо проанализировать цели бизнеса и рационализировать используемую ИТ-инфраструктуру. В конечном счете может оказаться, что вам не следует создавать свое облако, а стоит присмотреться к альтернативным решениям, включая аутсорсинг и услуги типа “инфраструктура как сервис” (IaaS) или “платформа как сервис” (PaaS). |
Тут я могу согласиться, особенно если в компании "слабый" специалист, который часто встречается именно у любителей ППО, то ставить им собственно облако категорически не стоит. А вот если специалист или группа специалистов профи, да и облако требуется не маленькое, то вряд ли стоит платить за облако чужому специалисту.
Подводя итог. Я лично вижу, что модель ППО воспринимается большинством клиентов понятной, а модель СПО воспринимают как кучку альтруистов, которые не способны что-то сделать. Причем маркетологи ППО раздувают этот миф, начиная с автора статьи.
AWS, OpenStack, vCloud, Azure и т.д. - вариантов много, но чтобы не выбрали внедрять систему должен профессионал, с учетом всем слабых и сильных сторон каждого отдельного решения, а не выбором между ППО или СПО.
Правильный СПОшный подход
Если у вас есть некоторые принципы, которые вы советуете другим, но нужно и самому их придерживаться.
А то я помню в одном ИТ-журнале лет 15 назад, была теме "про пиратство". Там были две статьи одного автора. В одной он говорил, почему "тырить" ПО от MS - вполне нравственно, а в другой - возмущался тем, что его статью перепечатали в другои издании без его разрешения.
А вот перепечатка статьи - это уже неуважение к автору. Если я категорически не хочу, чтобы моей работой пользовалась какая-нибудь "Новая газета", то имею на это полное право.