Мы обратили внимание читателей на тот факт, что платформа Openstack не является продуктом непосредственно компании Mail.ru Group. Поставщику придется самостоятельно развивать компоненты данной платформы в случае, если комьюнити снизит интерес к Openstack. Дальнейшее самостоятельное развитие потребует дополнительных затрат со стороны поставщика, а, возможно, и перехода на новый стек технологий.
Яндекс в качестве компонентов облака использует собственные технические решения, которые он сам разработал и использует для своих сервисов. Внутри компании сформированы центры компетенции по развитию и поддержке данных решений. Их развитие не зависит от внешних факторов.
Согласны, что для Scalr IaCP будет достаточно Terraform провайдера, но мы имели в виду платформу управления облаком Scalr CMP, для которой в перечне поддерживаемых платформ Яндекс.Облака нет. Scalr CMP требует доступа к API продукта для построения каталога услуг, тарификации, квот, разграничения доступа и прочих функций управления гибридным облаком.
Как мы уже писали в самом начале статьи, решения, основанные на «коробочных продуктах» сторонних производителей, не позволяют гибко и оперативно внедрять новые сервисы, потому что они ограничены дорожной картой вендора. Например, Serverless, платформа IoT, сервисы Big Data и аналитика данных, отсутствуют у вендора VMware.
С другой стороны поставщики облачных услуг фактически предоставляют пакет Managed Services + аренда инфраструктуры, тем самым перекладывая на себя стоимость поддержки тех же технических решений, которые заказчик может использовать на собственной инфраструктуре. Бесспорно, это закрывает определенные потребности среди крупных заказчиков, но с точки зрения экономической модели стоимость таких решений будет выше за счёт значительной доли платежей в сторону поставщиков оборудования и ПО.
Можете описать какой уровень детализации Вы ожидали увидеть в подобном сравнении?
Нашими статьями мы преследуем две задачи. Во-первых, обратить внимание только на ключевые(!) различия между платформами для планирования миграции клиентских приложений на инфраструктуру Яндекс.Облака или MCS. Характеристики, которые у обоих поставщиков реализованы примерно одинаково, в эту статью не попали. Во-вторых, рассказать о том в каких направлениях у российских поставщиков есть пробелы по сравнению с возможностями AWS, Azure и GCP.
Также хочу напомнить, что это цикл статей, и мы рассказали пока только про IaaS. В следующих статьях мы остановимся на сетевых сервисах, PaaS, SaaS и других сервисах, о которых в первую очередь шла речь на Yandex Scale. Продолжение следует, оставайтесь на связи!
Яндекс в качестве компонентов облака использует собственные технические решения, которые он сам разработал и использует для своих сервисов. Внутри компании сформированы центры компетенции по развитию и поддержке данных решений. Их развитие не зависит от внешних факторов.
С другой стороны поставщики облачных услуг фактически предоставляют пакет Managed Services + аренда инфраструктуры, тем самым перекладывая на себя стоимость поддержки тех же технических решений, которые заказчик может использовать на собственной инфраструктуре. Бесспорно, это закрывает определенные потребности среди крупных заказчиков, но с точки зрения экономической модели стоимость таких решений будет выше за счёт значительной доли платежей в сторону поставщиков оборудования и ПО.
Нашими статьями мы преследуем две задачи. Во-первых, обратить внимание только на ключевые(!) различия между платформами для планирования миграции клиентских приложений на инфраструктуру Яндекс.Облака или MCS. Характеристики, которые у обоих поставщиков реализованы примерно одинаково, в эту статью не попали. Во-вторых, рассказать о том в каких направлениях у российских поставщиков есть пробелы по сравнению с возможностями AWS, Azure и GCP.
Также хочу напомнить, что это цикл статей, и мы рассказали пока только про IaaS. В следующих статьях мы остановимся на сетевых сервисах, PaaS, SaaS и других сервисах, о которых в первую очередь шла речь на Yandex Scale. Продолжение следует, оставайтесь на связи!