В последние годы очень много говорилось о том, что значительную часть ИТ в компаниях, а возможно даже и целиком, скоро можно будет передать в публичное облако. Одним из наиболее активных сторонников этой позиции была компания Amazon, естественно предлагавшая для замены свое публичное облако AWS.
Аргументы в пользу публичных облаков сводились к следующему: а) ИТ-сопровождение дешевле, чем через корпоративный ЦОД; б) они безопасней благодаря применению универсальных решений; в) позволяют ИТ-инженерам компании больше времени уделять качеству создаваемого ПО, а не тратить время на технические проблемы при обслуживании собственных ЦОДов.
Аналогичную позицию высказывала недавно Диана Грин, вице-президент Google, отвечающая за развитие корпоративных облачных разработок. Она указала на рост использования публичных облачных решений в банках и компаниях с повышенными требованиями к безопасности, назвав в качестве главных публичных облачных площадок AWS, Microsoft Azure и Google Cloud Platform.
Однако Грин также заявила, что имеются и скептики, которые придерживаются противоположных взглядов. По их оценкам, публичное облако не годится для реального бизнеса: предоставление облачных услуг выросло до масштабов крупного бизнеса, который стремится иметь свою долю в получаемых заказчиком доходах. При этом компании, отдавая данные, все чаще хотят получать больше информации об их безопасности, не ограничиваясь только экономическими вопросами.
Microsoft, третий среди основных игроков на рынке публичных облаков, пока воздерживается от высказываний в пользу переноса корпоративных приложений в публичное облако. Нейтралитет корпорации легко объясняется: многие клиенты используют продукты Microsoft в корпоративных ЦОДах.
Форрестер против
Джейсон Форрестер относится к числу экспертов в области облачных решений, со мнением которых считаются. Еще год назад он работал в Apple, где руководил поддержкой сети глобальных дата-центров компании, а до этого 10 лет проработал в IBM.
Как недавно написало издание Fortune, Форрестер заявил, что слухи о назревающем упадке корпоративных ЦОДов сильно преувеличены. Более того, они в корне ложны. По его мнению, приложения, играющие для компаний стратегическое значение, обязаны работать внутри корпоративных ЦОДов, а не в публичных облаках.
Год назад Форрестер покинул Apple, уведя с собой большую группу сотрудников инфраструктурного подразделения компании. Они создали стартап, получивший название SnapRoute. Его цель — выпуск продуктов, способных обеспечить гибкость при развитии сетевой инфраструктуры внутри компаний.
Как считает Форрестер, публичные облака должны применяться только для «простого контента» — корпоративной электронной почты, Web-приложений, других программных систем, у которых нет жестких ограничений на время отклика. Приложения, играющие для компании стратегическое значение и реализующие ее «фирменные фишки», должны оставаться в корпоративных ЦОДах.
Примерами таких приложений Форрестер называет сервис виртуального помощника Siri для Apple, Apple TV, картографическую службу обслуживания заказов Uber. Эти службы останутся в корпоративных ЦОДах, считает он, даже при самых заманчивых предложениях со стороны поставщиков публичных облаков.
«Многие корпоративные приложения в значительной степени адаптированы под особенности внутренней ИТ-инфраструктуры. Их перенос в публичное облако никогда не будет простым. Поэтому компании, имеющие на балансе крупные бухгалтерские системы и программы инвентарного контроля оборудования, совершенно не торопятся переносить их в публичное облако. Когда речь заходит о системах, на которых построен бизнес, благодаря которым создается финансовая прибыль компании, она стремится иметь полный оперативный контроль над ними. Удовлетворить таким требованиям невозможно при размещении в публичных облаках, когда провайдеры, например Amazon, даже не позволяют корпоративным заказчикам подходить к оборудованию в облачных ЦОДах», — пояснил Форрестер.
Новые «старые» решения
Есть еще одна причина, заставляющая компании не выводить часть своих приложений за пределы корпоративного ЦОДа. Это — использование оборудования noname для серверов, систем хранения, сетевого оборудования. Стоимость этой аппаратуры значительно ниже, чем у брендированных моделей HP, IBM, Cisco и EMC. С появлением открытого проекта Open Compute Project и других инициатив появилась возможность найти решения, позволяющие комплектовать ЦОДы подходящим оборудованием, работоспособным в реальных условиях.
В последнее время на рынке появились несколько продуктов, нацеленных на совершенствование сетевых решений в новых условиях. Так, в начале лета из тени вышла компания, представившая свою новую технологию маршрутизации Secure Vector Routing. По мнению специалистов, это — фундаментальное решение, способное повысить производительность сети при снижении затрат даже там, где бессильны существующие сегодня технологии программно-определяемых сетей (SDN) и средства сетевой виртуализации (NFV).
Для гибкого использования оборудования разных вендоров SnapRoute предложила свое решение FlexSwitch, развиваемое в рамках Open Compute Project. В этом решении нашел воплощение опыт, накопленный бывшими сотрудниками Apple.
«Когда я пришел в
Достижения McQueen как раз и стали основой для FlexSwitch, разрабатываемой SnapRoute как часть операционной системы OpenSwitch.
Свое решение предлагает компания Nicira, являющаяся подразделением VMware. Она создала платформу сетевой виртуализации Nicira Network Virtualization Platform (Nicira NVP), предложив рынку собственное решение для создания программно-управляемой сетевой среды. Однако платформа Nicira ориентирована на управление «зоопарком» ранее купленного сетевого оборудования от разных производителей. Решение SnapRoute имеет другую направленность, оно нацелено на умелое управление недорогими, небрендированными сетевыми устройствами, которые сейчас закупаются компаниями.
Сторонники публичных облачных решений шутят, что корпоративные сетевые администраторы любят возиться «вокруг серверной рухляди». Как бы то ни было, но новые решения, такие как FlexSwitch, дают серьезный шанс компаниям успешно решать свои задачи в будущем, опираясь на собственные корпоративные ЦОДы, не прибегая к необходимости отдавать их в публичное облако.