Вот примерно так я себя и чувствовал, когда начал разбирать этот стек.

Знаете, бывают технологии, которые изучаешь — и сразу понятно, куда шли и чем закончили, но OpenStack — это не просто технология, это целая эпоха. Причём такая, где на одной временной шкале у тебя NASA, Rackspace, Mirantis и Red Hat и десятки других крупных компаний, каждая из которых решила, что надо объединиться чтобы сделать свой, «домашний» AWS.

Кстати, да, меня зовут Эдгар Сипки, я девелопер-адвокат в MWS Cloud Platform, и сегодня мы поговорим об OpenStack.

В начале 2010-х казалось, что OpenStack — тот самый путь, который позволит компаниям перестать зависеть от AWS, построить современное облако на собственном железе, дать разработчикам self-service и инфраструктуру как в Amazon, но без миллиардных счетов и вендорской зависимости.

Спустя годы хайпа, конференций и гигантских проектов некоторые облачные провайдеры всерьёз используют фразу «мы не на OpenStack», и это выставляется как киллер-фича. То есть всё настолько сильно поменялось (но даже тут не всё так однозначно, о чём мы с вами ещё поговорим).

Давайте начнём с самого начала. Думаю, что для многих будет неожиданным открытием, что у истоков OpenStack стояло NASA. Реально NASA. Агентство, которое должно запускать ракеты в космос, но они решили в этот раз: «Запустим серверные стойки».

Когда начинаешь разбираться, зачем им это было нужно, становится понятно — это не просто open source проект, а серьёзная попытка решить очень реальные, очень тяжёлые проблемы в мире инфраструктуры.

А что было до OpenStack и какую проблему пытались решить

Если откатиться назад, одним из первых (и самых успешных) облаков было облако AWS. Но перед тем как дойти до него, давайте поймём: а почему OpenStack вообще возник и какую проблему хотели им решить? Что было не так до 2006 года и что заставило Amazon вдруг начать разрабатывать инфраструктуру как сервис? Ответ кроется в том, что весь мир IT страдал от одной и той же боли — боли, которая достигла точки кипения именно в начале 2000-х.

Эпоха мейнфреймов и time-sharing (1950–1980-е)

История облачных вычислений начинается не с AWS, а намного раньше — с идеи централизованных вычислений. Мейнфреймы 1950–60-х годов представляли собой огромные и дорогие машины, доступные только крупным корпорациям и правительствам.

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

Чтобы сделать их доступнее, даже придумали целую концепцию time-sharing — технологию, которая позволяет множеству пользователей одновременно работать с общим компьютером через терминалы.

И первой ОС с time-sharing стала CTSS в MIT в 1961 году — это позволило сразу трём пользователям одновременно работать на модифицированном IBM 709. По сути, это были первые облака — где были централизованные ресурсы, к которым пользователи подключались через сеть терминалов — тонких клиентов.

Но в 1980-е рынок сильно стал меняться: клиентские устройства стали всё мощнее, а с появлением доступных персональных компьютеров (IBM PC, Apple II) и дешёвых x86-серверов компании стали массово отказываться от мейнфреймов в пользу клиент-серверной архитектуры. Для индустрии мейнфреймов это стало катастрофой — спрос рухнул (тут можно ещё вспомнить наступление Apple на IBM).

Но проблемы на этом не закончились. Компании начали активно  строить собственные дата-центры (on-premise) — многие стремились обеспечить приватность внутренней инфраструктуры  и иметь полный контроль над данными. И вот тут начался уже другой кризис, менее очевидный. Давайте разберёмся, о чём речь.

Дело в том, что компании, которые занимаются работой и настройкой своей инфраструктуры, вынуждены брать железо с учётом пиковой нагрузки, а не с учётом «средней». Часто  это приводит к тому, что половина ресурсов простаивает, а реально утилизируемая мощность оказывается не более 40–50% от заложенной.

К каким проблемам это привело с точки зрения влияния на бизнес? 

Проблема 1: Procurement Hell

Когда вы запускаете новый продукт, что вам нужно в начале? Начать писать код? Как бы не так, в первую очередь надо заняться инфраструктурой. И дело было не только в закупке серверов — всё куда глубже. Нужно было обеспечить закупку, логистику, монтаж, кабели, даже помещение, где всё это будет находиться, — арендовать (или закупить/построить). Всё это убивало инновации — стоимость запуска продукта в компании, да что там, стоимость запуска новой компании становилась невероятной — цена ошибки не просто потерянные дни/недели/месяцы, нет, цена ошибки могла достигать миллионов долларов — бизнес строился не по принципу «проверки гипотезы», а по долгоиграющим и сложно подготовленным планам.

Проблема 2: ловушка CapEx

Компании покупали оборудование, ориентируясь на пиковые нагрузки, но это только верхушка айсберга, ведь компания платила полную стоимость сервера, электричества и охлаждения, даже если использовала всё это на 5%. Одно дело — купить железо, которое в итоге не пригодилось, другое — продолжать его обслуживать.

Проблема 3: «недифференцированная тяжёлая работа»

Недифференцированная тяжёлая работа (undifferentiated heavy lifting) — термин, позже популяризированный самим Amazon. До 70% времени инженеров уходило не на создание бизнес-ценности, а на «сантехнику»: настройку сетей, бэкапы, патчинг серверов, борьбу с перегревом — то есть инфраструктурные задачи. Это была работа, которая сама по себе не давала конкурентного преимущества. Любая компания, ведущая бизнес в IT, обязана заниматься инфраструктурой и железом — без этого просто невозможно реализовывать основные продукты и сервисы.

Но при этом качество управления инфраструктурой и оборудованием редко определяет успех бизнеса напрямую. Это необходимое условие для работы, а не фактор, который сам по себе делает компанию сильнее конкурентов.

И тут пришёл AWS

AWS в два счета  превратил инфраструктуру в API. Нажал кнопку — получил VM. Написал скрипт — получил десять. Запустил автоскейлер — и вообще забыл, что под капотом, ведь всё становилось автоматически масштабируемым.

И разработчики такие:

• Далеко не всё можно вынести в публичное облако из-за регуляторики, ПДн и прочих ограничений.

• Многие компании понимали: зависимость от AWS вдолгую может стать очень дорогим удовольствием.

И о чём могли подумать все остальные компании, которые хотели иметь у себя AWS дома?

И тут рождается мечта: сделать AWS у себя дома (во внутреннем контуре), чтобы были API, self-service, виртуалки, сети, диски — всё по запросу. И чтобы это всё было open source и без vendor lock. Эта мечта стала причиной появления OpenStack и создала целую эпоху.

NASA и Rackspace: странный дуэт, который оказался вместе в интересное время

История OpenStack — это сотрудничество двух очень разных компаний, которые независимо друг от друга пришли к одной идее. С одной стороны — космическое агентство, которое запускает роверы на Марс, а с другой — хостинг-провайдер из Техаса, который сдавал серверы в аренду. И вот эти компании решили вместе создавать будущее облаков.

NASA: когда ракеты летают, а инфраструктура нет

Примерно в 2007 году NASA столкнулось с кризисом инфраструктуры, и это был не тот кризис, который можно решить, просто докупив серверы:

• 140 000+ изображений и видео из космических миссий — и это число росло каждый день.

• Гигантские научные датасеты — земные наблюдения, климатические модели, данные телескопов.

• Сотни исследовательских коллективов по всему миру, каждый со своими требованиями.

• Суровые требования безопасности — данные должны оставаться на территории США.

Главная боль: NASA не могло просто «закинуть» свои данные в AWS. Это же NASA — федеральное агентство. Данные о спутниках, климатические модели, результаты миссий — всё это чувствительная информация, которая не может храниться  на серверах коммерческой компании. Регуляция не позволит, здравый смысл не позволит, американский конгресс не позволит точно.

Проект Nebula: NASA пытается сделать свой AWS

Крис Кемп, который на тот момент занимал должность CTO IT в NASA (между прочим, первый в истории агентства человек на подобной должности), получил задачу: «Стандартизируй нашу инфраструктуру». Вместо того чтобы патчить старое железо, команда решила построить облачную платформу с нуля. Так в 2008–2009 годах родился проект Nebula — внутреннее облако NASA, развёрнутое в Ames Research Center — исследовательском центре в Кремниевой долине.

Изначально команда Кемпа взяла open source проект Eucalyptus — это был один из первых клонов Amazon EC2/S3 для приватных облаков, созданный в University of California. На бумаге, как обычно, всё выглядело идеально: берёшь готовый опенсорс, ставишь на своё железо, получаешь приватный AWS, но реальность, как обычно, беспощадна, и, кстати, к этой мысли мы ещё позже снова вернёмся.

Почему Eucalyptus не взлетел в NASA

Когда инженеры NASA начали дорабатывать Eucalyptus под свои масштабы (а им нужно было гонять тысячи виртуалок),  они столкнулись с тем, что не могут внести свои улучшения обратно в проект. Почему? Потому что Eucalyptus Systems (коммерческая компания, которую основали создатели проекта во главе с бывшим CEO MySQL Мартеном Миккосом) использовала модель open core — часть кода была открытой, а часть закрытой, доступной только в платной версии.

Инженеры NASA писали патчи, которые улучшали масштабирование, но их вклад конфликтовал с закрытым кодом коммерческой версии. То есть буквально: ты вложил время и ресурсы в улучшение open source проекта, а тебе говорят «извини, но это сломает нашу платную версию, мы не можем это принять». Для Кемпа это стало принципиальным моментом. Он позже говорил: «Проект, который не является по-настоящему открытым, не может быть фундаментом для государственной инфраструктуры». NASA не собиралось строить критическую систему на платформе, где часть кода контролируется одной коммерческой компанией. Эта история, кстати, стала потом классическим примером того, почему open core — это не то же самое, что open source.

Рождение Nova

Тогда Кемп принял решение, которое оценят все прогеры: переписать compute-компонент с нуля.

Под эту цель он на шесть месяцев задействовал всю команду Nebula. Так родился проект Nova — новый Cloud Fabric Controller.

Начальная версия — всего 9000 строк кода, полностью открытых под Apache 2.0:

• Запуск VM по запросу через API.

• Управление жизненным циклом виртуальных машин.

• Поддержка гипервизоров KVM и Xen.

• Архитектура, рассчитанная на масштабирование до тысяч, а в перспективе — до миллиона (!) узлов.

Забавный факт: Кемп так верил в потенциал Nebula, что продвигал идею облака, способного масштабироваться до миллиона машин. В 2009 году это звучало как научная фантастика, но ведь это NASA — они и должны творить научную фантастику.

Rackspace: хостинг-провайдер, предвидевший будущее (и свой конец)

Тем временем Rackspace — один из крупнейших хостинг-провайдеров мира на тот момент — переживал кризис. Чтобы понять контекст: компания Rackspace десять лет занималась managed hosting — то есть ты приходишь, арендуешь выделенный сервер и Rackspace заботится о том, чтобы он работал. Это был огромный и прибыльный бизнес. Но в 2006 году запустился AWS, и мир начал меняться. Компании, которые раньше арендовали серверы у Rackspace, начали уходить на EC2 и S3. Зачем платить за выделенный сервер, если можно нажать кнопку и получить виртуалку за копейки?

Rackspace был в сложной позиции, и руководство видело два пути:

Вариант 1. Запустить закрытую облачную платформу и конкурировать с Amazon на его поле. Но это дорого, долго и Amazon уже выиграл 4-летнюю фору. 

Вариант 2. Открыть исходный код и построить открытую альтернативу AWS. То есть не пытаться быть лучше Amazon, а изменить правила игры.

К этому моменту у Rackspace уже был собственный облачный продукт — Mosso. Его основали Джонатан Брюс и Тодд Мори, два сотрудника компании, ещё за четыре года до этого. Позже Mosso переименовали в Rackspace Cloud, и платформа включала три компонента:

• Cloud Servers — виртуальные серверы на гипервизоре Xen (внутреннее кодовое имя — Ozone).

• Cloud Files — объектное хранилище (ранее CloudFS).

• Cloud Sites — PaaS с поддержкой LAMP- и .NET-стеков

Rackspace выбрала второй путь — open source — и решила открыть:

• Cloud Files → переименовали в Swift (объектный сторидж, аналог S3).

• Cloud Servers / Ozone → compute на Xen.

Джонатан Брюс позже объяснял логику: «Мы не софтверная компания. Мы не собираемся зарабатывать на продаже лицензий. Мы зарабатываем на хостинге. А если мы откроем код, к нам придёт экосистема. Экосистема привлечёт клиентов. Клиенты — это деньги».

Но тут был один нюанс, у Rackspace был отличный storage (будущий Swift), но их compute-компонент (Ozone) имел сложности масштабирования. Им нужен был мощный compute-движок, а разработка с нуля заняла бы годы. И вот тут случилось то самое совпадение — кто-то в Rackspace узнал про NASA Nebula и Nova.

И именно в тот момент, когда NASA заканчивала работу над Nova, — Rackspace решил открыть свой код. Две организации, абсолютно независимо друг от друга, на разных концах страны, разрабатывали open source облако. И их технологии идеально дополняли друг друга, как пазл из двух кусочков:

• NASA Nova = compute (виртуальные машины) → аналог EC2.

• Rackspace Swift = storage (объектное хранилище) → аналог S3.

Nova копировала EC2, Swift копировала S3. Вместе — скелет полноценного облака.

По словам Джима Карри, вице-президента по корпоративному развитию Rackspace, именно Rackspace вышли на контакт с NASA, когда узнали про открытый код Nova. Rackspace изначально планировала просто открыть свой Ozone, но когда увидела Nova — поняла: зачем делать своё, если NASA уже написало что-то лучше? 

Когда Крис Кемп и Джонатан Брюс наконец встретились лично, они пришли к логичному выводу: «Давайте объединимся». По легенде, ключевая встреча произошла в тайском ресторане рядом с NASA Ames Research Center в Маунтин-Вью. Два человека, которые никогда раньше не работали вместе, из абсолютно разных миров (космос и хостинг), сидели за лапшой и рисовали архитектуру будущего open source аналога AWS. И знаете что самое крутое? Крис Кемп позже говорил, что успех OpenStack во многом связан с тем, что люди хотели помочь NASA. 

«Многие из участников OpenStack глубоко внутри были вдохновлены космической программой и хотели написать код для проекта, который поможет NASA исследовать Солнечную систему». То есть open source проект получил бесплатный маркетинг уровня «помоги NASA исследовать космос» — да я сам бы влетел в такой проект.

19 июля 2010: день рождения OpenStack

19 июля 2010 года на конференции OSCON (Open Source Convention) в Портленде Лью Мурман, президент Rackspace Cloud, вышел на сцену и объявил о запуске OpenStack — объединённого проекта. Код от NASA. Код от Rackspace. Одна лицензия — Apache 2.0. Одна цель — открытое облако для всех. В тот же день к проекту присоединились более 25 компаний: Citrix, Dell, Intel, AMD, NTT Data и другие. Это была не история про двух одиночек в гараже — OpenStack с первого дня стал индустриальной коалицией.

Марк Колье из Rackspace (который позже стал операционным директором в OpenStack Foundation) вспоминал, что он сыграл ключевую роль в построении альянсов: именно он договаривался с более чем 25 организациями о поддержке проекта ещё до публичного анонса. Когда OpenStack вышел на сцену, у него уже была армия сторонников.

Почему это была революция

Момент 1: лучше чем AWS для enterprise 

OpenStack открыл то, что AWS никогда не откроет — исходный код. Компании могли:

• Аудировать код (важно для безопасности и compliance).

• Модифицировать под свои нужды.

• Не бояться vendor lock.

• Запустить на своём железе без зависимости от провайдера.

И тут важно понять контекст. В 2010 году компании реально боялись vendor lock. Amazon мог в любой момент поднять цены, изменить API или — что ещё страшнее — сам стать твоим конкурентом (что, кстати, потом и произошло с некоторыми стартапами).

Момент 2: поддержка с момента запуска
OpenStack анонсировали с поддержкой более 25 компаний. Это не был pet project одного человека в гараже — это была коалиция гигантов, которые поставили на OpenStack как на стратегическую ставку.

Момент 3: спасение для зарегулированных отраслей

Для банков, госучреждений, страховщиков и телеком-операторов OpenStack был спасением:

• Банк не может хранить данные в AWS → запускает OpenStack в своём ДЦ.

• Госучреждение не может в AWS → OpenStack в стране.

• Телеком-оператор хочет NFV (Network Functions Virtualization) → OpenStack на своём железе.

• Компания не хочет vendor lock → OpenStack, портируемо между облаками.

Момент 4: культурный сдвиг
Но была ещё одна вещь, которую многие упускают. OpenStack стал символом. Символом того, что open source может конкурировать с самым крупным облаком в мире. Linux победил Windows на серверах — может, OpenStack победит AWS в облаках? 

Золотая эра ожиданий: OpenStack — «будущее всех облаков»

Атмосфера революции

Когда я смотрел архивные видео OpenStack Summit 2013/2014 годов, я удивился атмосфере, это было похоже на технологическую конференцию уровня Highload, люди реально верили: «Мы меняем индустрию». Первый OpenStack Design Summit в июле 2010 года в Остине собрал всего 75 человек. К 2014 году саммиты собирали более 4600 человек. А в 2016-м — более 7500. Рост в 100 раз за 6 лет — от школьного класса до стадиона.

К OpenStack присоединились монстры индустрии, и каждый зашёл с деньгами, инженерами и стратегическими ставками:

• Mirantis (2011) — первая pure-play OpenStack company, основанная русскоговорящими предпринимателями Адрианом Лоном и Борисом Ренски. К 2015 году компания привлекла около $100 млн инвестиций — на тот момент это был один из крупнейших раундов в истории open source.

• Red Hat (2012) — стала одним из основателей OpenStack Foundation, запустила собственный дистрибутив Red Hat OpenStack Platform.

• HP (2014) — объявила HP Helion с инвестицией в $1 млрд на два года. Планировала развернуть OpenStack-based публичное облако в 20 дата-центрах по всему миру.

• Canonical, SUSE, IBM, Intel, Cisco, Oracle — все прыгнули на волну.

К 2014 году OpenStack поддерживали более 200 вендоров. К моменту пика — более 500 компаний. Было впечатление, что вокруг OpenStack складывается экосистема, аналогичная Linux. Стив Дитч из HP прямо говорил: «Мы намерены сделать с OpenStack в облаке то же, что мы сделали с Linux на серверах».

Аргументы казались железобетонными

Apache 2.0, философия Four Opens. Можно развернуть в своей стойке — данные на твоём железе, API совместим с EC2 и S3: разработчик, привыкший к AWS, мог работать почти без переучивания.

Отдельно про регуляцию — это не было «бесплатным бонусом». В США в 2010-м действовал GLBA: банки обязаны были иметь письменный план защиты информации и контролировать подрядчиков. Если аудиторы просили отчёт о проверке облака, а AWS такой отчёт предоставить не мог — это автоматически нарушало требование due diligence, независимо от того, насколько AWS был технически безопасен. Аналогично с PCI для платёжных данных. 

Так что для банков и финтеха on-premise OpenStack был не «ещё одним вариантом» — это был единственный вариант. Но «соответствие регуляции» не давалось само по себе: нужно было настраивать аудит-логи, шифрование, контроль доступа и документировать всё это самостоятельно.

К этому моменту в нашей истории VMware — это монополист on-premise виртуализации. Основанная в 1998 году командой исследователей из Стэнфорда, к 2008-му компания контролировала 65% рынка серверной виртуализации. Если у тебя был корпоративный дата-центр — с высокой вероятностью он работал на vSphere. Это была та самая прослойка, которую компании поставили между железом и своими сервисами, когда бежали от мейнфреймов.​

Но возможно, самый мощный мотиватор перехода на OpenStack — избавление именно от VMware. Лицензии vSphere доходили до $4,780 за CPU в год. С каждым годом VMware повышала цены — и деваться было некуда, слишком глубоко всё было завязано на их стек. OpenStack обещал нулевые лицензионные затраты и открытый код. Ирония: даже VMware в какой-то момент присоединился к OpenStack Foundation.

Я это, кстати, представляю вот так:

Релизы и реальные внедрения

OpenStack принял модель полугодовых релизов, число проектов выросло до 44. Это выглядело как невероятная мощь open source комьюнити. Только вот позже выяснится, что 44 слабо связанных проекта — это не только мощь, но и серьёзная проблема интеграций между всем этим зоопарком. Тем временем к 2012–2015 годам большие компании реально запускали OpenStack в продакшене:

• Walmart — начала с нескольких тысяч ядер в 2014-м, к 2021-му перевалила за миллион ядер. Даже делали стикеры: «100 000-core club».

• CERN — использовали для обработки данных Большого адронного коллайдера.

• Target, Santander Bank, Verizon, PayPal — все в продакшене.

OpenStack Foundation

В сентябре 2012 года комьюнити потребовало независимости от Rackspace, и была создана OpenStack Foundation — независимая некоммерческая организация с более чем 5600 членами в первый день. К 2014 году — более 355 компаний и примерно 500 активных контрибьюторов ежемесячно. Аналитики из 451 Research оценивали рынок в $3,3 миллиарда к 2018 году. Индустрия всем сердцем поверила, что open source облако победит AWS.

История одного деплоя

2015 год, средняя европейская компания, 500 человек. CTO посмотрел на лицензии VMware ($300K/год за право запускать ПО на собственном железе), потом на AWS (чужое железо, чужая сеть и уйти некуда) — и решил: «Давайте поднимем своё облако».

Купили железо на $400K, наняли двух OpenStack-инженеров. Следовали документации. Установка заняла два месяца вместо планового одного — документация устарела. К пятому месяцу попытка обновиться обернулась 6 часами downtime и откатом из бэкапа. На шестом — RabbitMQ съел всю память и положил кластер. На восьмом месяце CTO собрал митинг:

И эта история — не (совсем) выдумка. Это сборник из десятков реальных историй с HackerNews, Reddit и приватных разговоров 2015–2016. Паттерн был один: OpenStack обещал стать простой альтернативой AWS, а получился «дорогой, сложный, нестабильный AWS, который нужно чинить и поддерживать самому».

«Мам, можно нам AWS?» — «У нас есть AWS дома»

Ожидание: разворачиваем OpenStack, следуем гайду — у нас свой AWS.

Реальность: нет.

Установка: день 1 — уже боль

Чтобы просто установить OpenStack, нужно было выбрать дистрибутив, развернуть минимум 3 control-ноды для HA, настроить сеть. Mirantis разработала Fuel — отдельный продукт для установки OpenStack. Сам факт, что для установки облачной платформы нужен отдельный инструмент, который разрабатывала целая команда, — уже говорит о многом. А DevStack (скрипт для разработчиков) стал мемом: люди тратили дни, чтобы запустить OpenStack на одной машине для тестирования.

Neutron — главный злодей этой истории

Neutron (сетевой компонент) был главным источником боли во всём OpenStack. Это признавали даже сами разработчики.

Саар Гилай, COO (Chief Operating Officer — операционный директор) облачного подразделения HP, на Summit 2014 публично признал: «Neutron — это проблема. И это была наша общая вина как комьюнити». Neutron вырос из проекта Quantum от Nicira (позже куплена VMware) и нормально работал только с её NSX-плагином.

Для работы с Neutron инженер должен был знать: VLAN/VXLAN/GRE tunnels, Linux network namespaces, Open vSwitch, BGP, Security groups через iptables, DHCP-агенты. HP настолько пострадала от проблем Neutron, что была вынуждена полностью переписать сетевой стек для HP Helion. Типичная ситуации: VM создалась, но сеть не подключилась, или security group не применилась, или DHCP не раздал IP.

Инфраструктурные зависимости: RabbitMQ и Galera

OpenStack использует RabbitMQ для коммуникации между всеми сервисами и MySQL с Galera replication для высокой доступности базы. Оба компонента страдали от одних и тех же проблем: split-brain, потеря кворума, непредсказуемое поведение при нестабильной сети.

RabbitMQ при высокой нагрузке мог съесть всю RAM (Random Access Memory) и заблокировать producers — и весь OpenStack вставал. Galera не поддерживала downgrade базы — если апгрейд сломался, единственный путь назад — восстановление из бэкапа. Представьте: RabbitMQ в split brain, Neutron не получает сообщения, новые VM создаются без сети. Пейджер пищит в 3 часа ночи. Удачи!

К этому добавлялись Cinder (block storage, часто на Ceph — отдельной вселенной сложности), Keystone (Identity), Heat (Orchestration), Ceilometer (Telemetry, настолько тяжёлый, что мог положить базу). Каждый компонент — отдельный микросервис со своей базой, конфигом, логами, багами. И все они должны работать вместе, 24/7.

Парадокс стоимости

Open source есть, лицензии бесплатные, а стоимость эксплуатации — как у маленького гиперскейлера. Экономили на лицензиях VMware (100 000–500 000 $/год), но тратили 1–2 млн $ в год на инженеров. Честные анализы TCO (стоимость жизненного цикла) показали: OpenStack на своём железе — 37–50 млн $ на 3 года, AWS для тех же workloads — 40–60 млн $. Разница практически никакая, только на AWS ты платишь Amazon и забываешь, а на OpenStack — платишь своим инженерам 24/7, и они всё равно не спят.

К 2015–2016 годам начались громкие «похороны»:

• HP Helion Public Cloud — закрыт в январе 2016-го. Два года и миллиард долларов — и публичное облако закрывается.

• Cisco Intercloud — запущен в 2014-м, закрыт в 2017-м. Тоже миллиард, тоже на OpenStack.

• HPE и Mirantis — в октябре 2016-го одновременно уволили ~200 OpenStack-инженеров. Две самые влиятельные компании в экосистеме одновременно сокращают команды.

• Rackspace — сооснователь OpenStack — сместила фокус на managed services, признав невозможность конкурировать с AWS.

OpenStack давал те же примитивы, что и AWS. Но AWS давал простоту эксплуатации поверх них.

Момент, когда отсутствие OpenStack становится киллер-фичей

Помните, зачем вообще создавался OpenStack? 2010 год, NASA и Rackspace. Мечта: построить свой AWS, на своём железе, со своими API. А потом… потом произошло нечто интересное.

OpenStack идёт в публичные облака

Пока HP вливал миллиард в Helion, а Cisco хоронила Intercloud, тихо, без лишнего шума и громких конференций, OpenStack нашёл своё место — там, откуда его создатели хотели сбежать: в публичных облаках. Да, вы правильно поняли. Технология, рождённая как антитеза AWS, стала фундаментом для сотен публичных облачных провайдеров по всему миру. 

Кто все эти провайдеры? Очень разные компании, объединённые одним — необходимостью иметь IaaS-слой, но без желания строить его с нуля, потому что это слишком дорого.

OVHcloud (Франция) — пожалуй, самый известный европейский пример, ребята, которые сами производят серверы, сами строят дата-центры, сами тянут оптоволокно, но им нужен был только софтверный слой поверх железа — и OpenStack оказался идеальным. К 2022 году: более 400 000 инстансов, 900 000 ядер, 6 миллионов API-запросов в час. К 2023-му — перешагнули миллион ядер. Победитель Superuser Award 2022. 

Почему у OVH получилось, а у HP — нет? Потому что OVH не пыталась конкурировать с AWS по количеству сервисов. Им не нужны были Lambda, SageMaker и ещё 200 managed-продуктов. Им нужен был надёжный IaaS — VM, storage, API, и именно это OpenStack и умеет неплохо.

China Mobile — самый громкий восточный пример. К 2020 году: более 60 000 физических серверов на OpenStack в восьми регионах Китая. Из этого вырос China Mobile Cloud — полноценное публичное облако, которое к 2023 году принесло 83,3 миллиарда юаней (~$11,5 млрд) и заняло третье место по IaaS в Китае. 

Казалось бы — хеппи-энд? Не совсем: OpenStack не победил AWS, но нашёл свою нишу в публичных облаках. Но знаете, почему я такой фанат изучать историю? Да потому что она повторяется, причём всегда.

Eucalyptus 2.0

Помните историю из начала статьи? NASA взяла Eucalyptus, попыталась масштабировать — код не тянул, контрибуции не принимались, пришлось переписывать с нуля. Так родился Nova. Прокрутим на 6–8 лет вперёд. Облачные провайдеры — OVHcloud, Deutsche Telekom, Telefonica — берут OpenStack, пытаются масштабировать до сотен тысяч ядер и натыкаются на те же самые грабли.

Разница с Eucalyptus — тонкая, но принципиальная. Там патчи не принимали, потому что код был закрытым: физически нельзя было контрибьютить. Здесь код открытый — но патч мог висеть в Gerrit месяцами в ожидании core reviewer'а с правом +2. А vendor-специфичные фиксы для масштабирования нередко отклоняли вообще: «Это ваша частная проблема, не общая». Другая технология, другое десятилетие — но итог тот же. Каждый провайдер платил тысячами человеко-часов, чтобы OpenStack заработал на их масштабе.

China Mobile

В 2016 году Intel совместно с China Mobile провели детальный анализ их OpenStack-кластера из 1000 нод (530 compute, 5 контроллеров, 3 ноды Galera, 3 ноды RabbitMQ). Они отправили 2000 конкурентных запросов на создание VM и получили...​ Success rate: 58,45%​, да из 8000 запросов за 4 прогона только 4646 завершились успешно. Почти половина — провалилась. На продакшен-кластере крупнейшего мобильного оператора в мире.

Что ломалось:

• Galera deadlocks — optimistic locking на весь кластер, при 2000 параллельных запросах база вставала намертво, 2284 ошибки​.

• Keystone authentication timeout — PKI-токены не справлялись под нагрузкой. Каскадные таймауты по всему пайплайну, 845 ошибок​.

• Neutron port creation failure — 1222 ретрая, Neutron не мог выделить порт для VM.​

• Nova scheduler — однопоточный (!), упирается в 100% CPU на одном ядре. При каждом запросе лезет в базу. При 800+ конкурентных запросах — сатурация​.

Yahoo/LINE

Yahoo — одни из основателей Million Cores Club. Джеймс Пеник, архитектор Yahoo, открыто признавал: главная боль — RabbitMQ. При масштабе в миллионы ядер message queue (очередь сообщений) становится критической единой точкой отказа. RabbitMQ при перегрузке съедает RAM, блокирует producers — Nova, Neutron и все остальные сервисы просто перестают общаться друг с другом.​ А LINE (6,9 миллиона ядер к 2023 году) столкнулся со вторым вечным злодеем — Neutron. 

Стандартная VLAN-модель имела слабую east-west пропускную способность и требовала специфического шедулинга VM. Что сделали? Переписали сетевой стек целиком — собственный L2 isolation plugin с BGP-роутингом между TOR-свитчами и гипервизорами напрямую, без overlay-сетей, без L2-агентов, без network-нод.​

OVHcloud прошла тот же путь — публично рассказывала на OpenInfra Summit 2022 о проблемах с L3-сервисами: метадата-сервис не доставал до роутера, Octavia load balancer держал VIP-порт в down состоянии by design.​

Масштабирование — это не свойство технологии, а инженерная работа, которая никогда не заканчивается. OpenStack — будучи настоящим open source под Apache 2.0 — позволял это перепиливание. Eucalyptus с его open core — нет. И именно поэтому OpenStack выжил, а Eucalyptus — нет. Не потому что лучше масштабировался, а потому что позволял это делать.

Но каждый провайдер, прошедший этот путь, заплатил за масштаб месяцами (если не годами) инженерной работы, бессонными ночами дежурных и переписыванием целых компонентов, в итоге многие стали задаваться логичным вопросом — а дольше ли было бы строить всё с нуля?

«Мы не на OpenStack» — и почему это стало продавать

К 2016–2018 годам вся индустрия видела один и тот же паттерн: берёшь OpenStack → тратишь полгода на деплой → нанимаешь команду → натыкаешься на проблемы масштабирования → переписываешь Neutron → тюнишь Galera → молишься, чтобы RabbitMQ не съел всю RAM в 3 часа ночи. И вот тут появились провайдеры, которые посмотрели на всю эту боль и сказали: «Нет, спасибо. Мы напишем своё».

Hetzner: «Мы отвергли хайп»

Hetzner — немецкий провайдер, который сам производит серверы, сам строит дата-центры и вообще делает всё по-своему. На Hacker News один из разработчиков описал их подход так: «Они отвергли хайп вокруг OpenStack и усердно работали над собственной гипервизорной платформой, и, похоже, это окупается сторицей. Большинство суверенных облачных проектов в итоге задыхаются от сложности и бессвязности экосистемы OpenStack».​ Сам Hetzner подтвердил — их маркетинг-менеджер на Reddit прямо написала: «Мы не используем готовые системы вроде OpenStack или CloudStack — всё написано нами с нуля».​

По сути, Hetzner сделал ровно то, что в своё время сделала NASA с Eucalyptus — переписал с нуля. Только NASA переписывала compute-компонент, а Hetzner — весь облачный стек целиком. Та же логика: существующее решение слишком сложное, проще написать своё.

И это работает. Hetzner стал одним из самых популярных провайдеров в Европе:

• Простой API без 44 компонентов под капотом.

• VM запускается за секунды, а не за минуты.

• Цены в 3–5 раз ниже AWS.​

• И нет оверхеда, который OpenStack неизбежно тащит за собой.

DigitalOcean: «OpenStack нам ничего не даст»

DigitalOcean пошёл по тому же пути — и тут есть прямая цитата от CEO Бена Уретски: «На данный момент нам было бы очень сложно внедрить OpenStack, и я не верю, что он дал бы какое-то значительное преимущество».​

Их инфраструктура — purpose-built проприетарный код. QEMU и Libvirt для виртуализации, Ceph для хранилища — но всё склеено собственным control plane, а не Nova/Neutron/Cinder. Те же низкоуровневые кирпичики (KVM, Ceph), но свой дом, без посредника в виде OpenStack.​

Результат: Droplet запускается в секунды. API из десятка методов вместо сотен. UI, в котором разберётся джуниор-разработчик за 15 минут.​

Vultr: та же философия

Vultr — 32 дата-центра на пяти континентах, свой control plane, никакого OpenStack. Простой API, Terraform-провайдер, managed Kubernetes — всё на собственном стеке.​

Почему они НЕ выбрали OpenStack

Ключевой аргумент: зачем тащить 44 компонента, если тебе нужно только 4? OpenStack проектировался как универсальная облачная ОС — уметь всё для всех. Hetzner, DigitalOcean и Vultr хотели специализированный инструмент — делать одну вещь, но хорошо и быстро.

И вот именно эти провайдеры — простые, быстрые, дешёвые — стали невероятно популярны среди разработчиков и стартапов. Именно на их фоне фраза «мы не на OpenStack» стала восприниматься как плюс: мы простые, мы быстрые, у нас не ломается Neutron в 3 часа ночи.

Ирония: одни провайдеры перепиливали OpenStack годами, чтобы он работал на их масштабе, — а другие посмотрели на эту боль и решили, что отсутствие OpenStack и есть их главная киллер-фича. И обе стороны по-своему правы.

Что в итоге

OpenStack не стал «убийцей AWS». Это так и осталось мечтой, но проблемы масштабирования — та самая нить от Eucalyptus через NASA до China Mobile, LINE и OVHcloud — привели к расколу индустрии (снова).

Одни прошли через боль, перепилили OpenStack под себя и получили масштаб:

• Более 300 публичных облачных дата-центров по всему миру.

• Суверенные облака от Франции до Новой Зеландии, от России до Китая.

• Телеком-гиганты с облачным бизнесом на $11 млрд.

Но вот что интересно: те, кто выжил и вырос — OVHcloud, China Mobile, LINE, — в итоге настолько глубоко переписали OpenStack под себя, что это с трудом можно назвать OpenStack. Они пришли ровно туда, куда пришли те, кто сразу сказал «нет, спасибо, напишем своё», — к кастомной инфраструктуре, заточенной под свой масштаб. Просто через годы боли и десятки миллионов на инженеров.

Вывод жёсткий, но честный: если ты вырастаешь до таких масштабов, где тебе нужна своя облачная платформа, OpenStack не сокращает путь. Он создаёт иллюзию готового фундамента там, где фундамент всё равно придётся лить заново.

И знаете, что во всём этом самое ироничное? В 2023 году Broadcom купила VMware и подняла цены в 2–10 раз. Компании в панике побежали... к OpenStack. Более 80% членов OpenInfra Foundation получили запросы на миграцию с VMware. Randy Bias из Mirantis: «Компании держатся за вендоров из-за инерции. Должен произойти тектонический сдвиг. Broadcom стал этим сдвигом».

И тут наконец всё встаёт на своё место. OpenStack создавался, чтобы убежать от vendor lock AWS. Сейчас к нему бегут, чтобы убежать от vendor lock VMware. Для этой задачи — независимость от вендора, контроль над инфрой, разумная цена — он отлично подходит. Но это совсем другая задача, чем «построить облако, которое будет масштабироваться». Круг замкнулся, только вендор поменялся. 

На российском рынке тоже есть примеры, когда провайдеры делали или начинали делать облака на OpenStack. Беглый поиск по Хабру или расширенный с помощью нейросетей найдёт вам интересное чтиво на несколько часов про то, как российские провайдеры переписывали компоненты OpenStack или полностью от него отказывались. При этом нельзя сказать, что эта поляна пустует. В нашей стране всё ещё много платформ, в том числе относительно молодых, которые делают бизнес на базе OpenStack.

Мы в MWS Cloud Platform решили пойти своим путём и написать технологически независимую облачную платформу. Да, это делает разработку дороже с точки зрения ресурсов, и с точки зрения времени, но зато у нас есть возможность полностью контролировать все компоненты. 

В статьях на Хабре мы делимся нашими подходами. Например, в этой статье CTO MWS Данила Дюгуров рассказывает, как мы подошли к созданию облака и какие технологии выбирали. Прочитать материал можно по ссылке. 

Ну, а мы на этом завершаем наше увлекательное путешествие по истории OpenStack. Буду рад вашему мнению об OpenStack и облаках в комментариях или в тг-сообществе MWS Cloud Platform.