Комментарии 38
Статья классная, всё супер, но учитывая её объём, я бы разделил её на 2 или даже 3 части, т.к. за 1 раз прочитать такое полотно текста, пусть и с красивыми картинками, сложно.
А как вы умудрились школу окончить? Там же войну и мир читать надо было :))
Вообще-то это статья , а не книга. И не удобно читать на хабре длинные статья потому что 1) нужно закладывать больше времени чем обычно уделяю одной статье 2) нет загладок чтобы можно было прододжить с определенного места 3) требуется охватить структуру статьи, а если статья длинная то это делать сложно. Как компромиссное решение добавить оглавление к статье.
Не хочу быть скептиком без знания деталей, но как считается - "дешевле практически по всем сервисам любого публичного облака в РФ"? Я том плане что затраты на разработку облака и его текущий мейнтенанс учитываются? Учитываются ли скидки от Яндекса которые для организаций вашего размера могли бы достигать 30-40 процентов?
Как по мне разумнее всегда не изобретать велосипед, взять готовое и нормально - и ехать на чужом, допиливая свое. Я прекрасно представляю сколько нужно усилий и времени чтобы поддерживать такое решение в работоспособном состоянии- а может эти ресурсы могли бы делать что то более полезное.
Здесь была невнятная статься от Flant где они запилили всего лишь замену Опсджини но на вопрос чем это лучше так и не смогли ответить(ну кроме того что это написано не нами(С)). Не смотря на разницу масштабов и затрат мне почему-то видится что кейсы похожие.
[для большей ясности приведу пример] у вас на сайте есть раздел Вакансии. Вы не выдумывали своего, а просто поставили там редирект на HH. И это вполне зрело и мудро - у вас единая точка правды, вы не тратите бабки на запиливание собственной вундервафли для поиска персонала и количество показов ваших вакансий на HH просто несравнимо с тем что было бы если бы вы шли только со своим решением по публикации вакансий.
В статье есть подробности в конце про сравнение стоимости. Дочитайте )
Есть в ИТ такой подход - ресурсно-сервисная модель (РСМ). Вы берете какой-то сервис, считаете текущие и будущие затраты на его развитие, поддержку, инфру и проч. Берете текущее и прогнозное потребление и одно распределяете на другое - получаете цену сервиса. Мы ровно это и сделали.
Мы не изобретаем велосипед - в статье есть про это.Commodity мы используем готовое, просто интегрируя это в платформу - например S3 или бэкапы. Да и OpenStack мы покупаем как сервис. Но я ответственно говорю что на рынке нет решения для таких компаний как Х5 ни среди РФ поставщиков, ни зарубежных. Поэтому мы сделали свое.
Кстати мы не одиноки - например Walmart делает то же самое. У него своя большая инфраструктурная платформа, а паблик облака используются только для cloud burst и ряда других задач связанных с распределенным compute, при этом никто своих пользователей в паблик облако напрямую не пускает, только через свою платформу.
Про HH пример не корректный ИМХО. HH это маркетплейс для сотрудников и работодателей.
Да я читал, но это общие слова.
Можно как угодно посчитать, чтобы доказать что наш солюшен дешевле. Про скидки от клауд провайдера вы например промолчали.
И ваш подход избегать Vendor Lock он контр продуктивный- я тоже раньше верил в то что быть независимым можно, и что OpenSource это спасение, но увы.
Вы сами, с Mirantis, добровольно в этот капкан попали.
На мой скромный взгляд более правильно использовать подход Cloud Agnostic - при кажущейся одинаковости, он отличается от VendorLock.
Мы используем каких-то провайдеров, но всегда держим в голове тот момент, что нам может понадобиться его поменять и наш солюшен должен быть максимально независимым.
Отсюда как раз и вытекает что выгоднее взять ОДНОГО провайдера, например, Yandex у которого и бакеты и базы данных и бекапы и Кубернетес уже есть. Да вы будете привязаны к этим сервисам, но только одного вендора и мигрировать будет легче. И у вас не будет головняка поддерживать десяток сервисов от разных провайдеров - что намного затратнее.
Не клауд агностик это например использовать в AWS - Aurora. У других вендоров ее нет.
Волнует еще такой вопрос- вы пишете что основной прирост идет за счет таких специалистов как SRE- но я в вакансиях кроме Системных администраторов больше никаких релятивных позиций не увидел.
Думаю если бы у вас было побольше современных специалистов, а не старой гвардии- они бы вам в ваших дискусиях указали на все эти моменты.
Ну моделями мы делиться здесь не будем - это интеллектуальная собственность.
Что касается скидо,то они сегодня есть, завтра их нет, а после завтра у вас 2х цена и что вы делать будете?
Ну и отдельный вопрос к зрелости и надёжности локальных публичных провайдеров. У любимого вами яндекса есть публичная инфа про инциденты. С таким уровнем доступности в ритейле в проде работать нельзя.
Цена важный, но не ключевой фактор. Намного важнее вопросы ИБ, контроля, в том числе финансового и свободной от вендорских сервисов разработки.
Если у вас 200 команд каждая со своим бюджетом вы как это в яндексе сделаете ? Финопс внедрять пойдёте?)
Относительно прироста. Если читали внимательно, то в статье сказано что мы работаем над превращением сервисом, которые оказывались ранее по заявкам в плаиформенные, облачные. Это прирост за счёт уже существующих команд.
По поводу специалистов современных в Х5, мы в взяли попкорн в руки и с нетерпением ждём когда вы расскажите нам что такое современная платформенная разработка. Ну пожалуйста)
Ну так вы сегодня есть, а завтра вас сбил автобус, и документация не особо поможет.
Про яндекс я не знаю- есть ли там бюджеты, в AWS нет проблем с любой гранулярностью бюджеты считать, опять же проще по тегам свою тулу для расчета сделать, чем свое облако :)
на мой скромный взгляд для 200 команд проще каждой было дать аккаунт в Yandex + настроить кубернетес кластер в этом аккаунте. Вопросы ИБ и прочего решаются политиками и рулами.
И уж после миграции заниматься тюнингом и зажиманием гаек, естественно это не быстро и каждый проект может требовать индивидуального подхода.
Как снимать метрики здоровья и организовать мониторинг инфры в таком подходе?
Как поступать при сбоях в сервисах и оперативно их чинить?
Как реализовать bulk-операции на всех элементах инфры (принудительное обновление, добавление новых внутренних доверенных сертификатов)?
Как снимать сводную статистику по использованию "в попугаях" (CPU/RAM) и в деньгах для всех проектов?
Я могу таких "как" накидать ещё штук 50 :)
Если ручками/плейбуками допиливать всё, то вся прелесть облака теряется - возвращаемся к системе заявок в инфровое подразделение и ожидание исполнения, измеряемое в днях, а не минутах. В этом подходе никакого бенефита от облака не прослеживается, можно и собственные сервера + vSphere/Xen использовать.
Так это не обязательно должно быть через клауд, графана и ELK которую вы крутите как сервис - вполне справятся.
Большая часть тут должна быть не на вас а на командах которые отвечают за сервис, вы только предоставляете платформу.
Прелесть не теряется- вы допиливаете только небольшие части.
У нас сами команды допиливают мелкие opensource сервисы никто никаких заявок в инфра подразделение не пишет.
Зачем кудато писать если большинство сервисов это docker image?
Поменял код - запустил и дальше работаешь.
Хороший подход. Жаль, что в реальной крупной организации не работает :)
Вы не можете начать работу с виртуалкой, т.к. кто-то должен настроить на ней доменную авторизацию по вашей заявке. И даже неважно, как это происходит - руками, плейбуком, или пайплайном.
Либо альтернатива - всё отдать на откуп 200 командам. Команды будут очень рады, когда узнают, что им самим нужно не бизнес-приложение пилить, а реализовывать инфраструктурные сервисы самостоятельно: мониторинг, логирование, доменная авторизация и другие требования ИБ. Бизнес также будет доволен тем, что вместо компактного подразделения, которое занимается массовыми операциями, в каждой команде появится отдельный человек, занимающийся инфраструктурой. Архитекторы порадуется тому, что мониторинг у 100 команд построен на Prometheus, у 70 на Zabbix, а оставшиеся вообще Splunk притащили вопреки арх.стандартам компании :)
А ещё из этих 200 команд примерно половина забудет обновить сертификат CA, или цепочку сертификатов и раз в год половина систем будет складываться как карточный домик )
То что вы описываете проблемы менеджмента, а не инфраструктуры. У нас сертификаты обновляет cert-manager. Мы вообще его на let's encrypt настроили и ничего не платим за сертификаты- все хорошо уже 2 года. Это решение спокойно маштабируется на все кластера централизованно или в виде шаблона.
Но повторюсь - 200 автономных команд на базе платформы которой все равно управляет инфраструктурная команда - вполне способны работать. Никто не говорит, что оно само заработает. Да много чего надо допиливать.
Но я опровергал ваше заявление о том что ваш солюшен дешевле облачных решений. По практическому опыту- самопилные вещи всегда дороже.
Да иногда это оправданно, но не дешевле чем взять готовое и допилить.
Cloud Agnostic - это выход, если вы ищете облако для одной-единственной команды.
На 5 командах у вас уже будут трудности с управлением такой инфраструктурой.
На 10 трудности станут явными.
На 200 такая модель просто работать не будет. Когда провайдер сломается, внезапно выяснится, что 20 команд не могут мигрировать, потому что никто не знает, как ПО устроено, ещё 40 завязли по уши в vendor specific сервисах, из оставшихся примерно половина не думает про ИБ и мы все вместе прочитаем на Хабре про новую утечку данных. И всё потому, что в публичном облаке вы отдаёте в руки командам полный контроль и никак не можете ограничить, что делать можно, а что нельзя.
И всё потому, что в публичном облаке вы отдаёте в руки командам полный контроль и никак не можете ограничить, что делать можно, а что нельзя.
Не совсем так. В том же Azure (да и у всех гиперскейлеров), например, есть довольно развесистая и гибкая система политик, которые могут применяться к тем или иным проектам, или организации в целом. И их нельзя просто "отменить" изнутри проекта.
А cloud agnostic да, вполне может применяться. Если пользоваться только стандартным функционалом, который везде более менее одинаково работает. Но, как быть со всякими прикольными provider-specific штучками? Не использовать что ли?
Я ответил выше в треде, но про провайдер специфик штучки скажу так - очень сильно стоит подумать, а так ли нужны они?
Вспомните MongoDB- в период популярности на его базе че только не пилили, а сейчас я даже встречал lock на использование монго на уровне дизайна.
Например вот без секьюрити фич вам не обойтись, у каждого провайдера нетворк и секьюрити свой. Но опять же, снаружи можно сделать все по дефолту, а внутри кластера Кубернетес использовать его инструменты, и это обычно везде работает. Если вы не решите использовать AWS EKS Pod security group конечно.
Каждый сам себе злобный буратино.
Cloud Agnostic это подход который позволяет минимизировать боль при миграции между клауд провайдерами. Он не пропагандирует воздержание от использования любых фич провайдеров, а предлагает всегда учитывать что возможно солюшен/инфраструктура будет переезжать к другому провайдеру.
Например лоад балансеры придется использовать, nginx ingress не во всех сценариях поможет. Но лоад балансеры в том или ином виде есть везде- и это можно смигрировать. А вот напримир AWS Aurora проприетарное решение и смигрировать оттуда БД гораздо больнее. Поэтому решение не использовать Aurora а использовать Postgress может быть принято в том числе исходя и из этого аргумента.
AWS Aurora - это сервис, в котором используется движок от MySQL/PostgreSQL (на выбор), и миграция очень проста (pg_dump работает с Aurora без дополнительных настроек).
Вероятно, вы имеете в виду другой сервис - AWS DynamoDB. DynamoDB является собственной разработкой Amazon и использует NoSQL, так что, да, нельзя обойтись всего лишь одной-двумя bash командами. Однако и здесь есть варианты: Microsoft и Google не заинтересованы в том, чтобы клиенты оставались в AWS, поэтому они разработали сервисы, максимально похожие на DynamoDB, с возможностью относительно простой миграции. Примером такого сервиса от Microsoft является CosmosDB. Если вы откроете документацию космоса, то увидите, что почти половина текста посвящена тому, насколько "легко" осуществить миграцию с DynamoDB.
Что-то готовое == негибкое.
Дьявол, как всегда, кроется в деталях поэтому взять любой готовый продукт и использовать его - это всегда компромисс между потребностями большой организации и возможностями вендорского продукта. Причём этот компромисс решается всегда в пользу вендора, а не компании-потребителя, которая, между прочим, платит совсем немаленькие деньги за продукт. Абсолютно типовая ситуация, когда запрос реализация потребности приводит сразу к нескольким негативным эффектам:
1) Появление форка продукта, который вендор в какой-то момент решит перестать поддерживать. Изменилась стратегия, команду форка переключили на развитие другого направления и т.д. - всем этим вы не управляете.
2) Выставление заградительных ценников на доработки. Вендору может быть просто неинтересно тратить ресурсы на создание того, что вам требуется.
3) Неуправляемые со стороны потребителя сроки реализации функционала. На сроки можно просто согласиться, почеледжить не выйдет.
Это только малая часть того, что скрывается за словом Opinionated.
Простой пример. Компании нужно, чтобы управление группами безопасности (по сути, просто правила фаервола) происходило под контролем ИБ, а не только пользователя. Это вообще стандарт в энтерпрайзе. Какое готовое облако позволяет так организовать ролевую модель, чтобы это было возможно реализовать?
Второй пример - санкционные ограничения. Если вы используете готовый Openstack, то заменить его вполне реально. Да, это отдельный технологически сложный проект, но реально. А вот если вы используете готовое облако, то выход у вас только один - миграция на другой продукт, что в крупной организации гораздо сложнее и дольше.
Готовые продукты как раз используются - тот же Openstack, например. Но, во-первых, это продукты не конкретной компании, а opensource-сообщества, а во-вторых, только как отдельные компоненты конечного продукта, вся логика предоставления сервисов конечному пользователю сделана иначе, под потребности большой организации.
Вы лукавите. Облачный провайдер не идеален не разу- но закрывает сразу широкий спектр сервисов, которые ВАМ не надо пилить. И это будет один вендор с бесшовной интеграцией этих сервисов. И вы можете в любой момент встать и уйти, да сейчас в РФ не так много альтернатив, но эта ситуация не статична.
И как я писал выше - расширить функционал готового солюшена гораздо проще чем пилить свою вундервафлю.
Не знаю как в Я но в AWS варианты управления политиками и секьюрити группами на любой вкус.
И к вашему кейсу как нельзя лучше подходят слова Безоса:
> В 1900 году чтобы открыть магазин вам надо было построить электростанцию рядом. В 2000х никому и в голову не придет строить свою электростанцию- все просто покупают электроэнергию у электрокомпаний. Вот вы занимаетесь тем что мастерите электростанцию. Да возможно неплохую, да сильно кастомизированную, но не факт что вашему бизнесу от этого лучше. Вам интересно - это как раз понятно.
Нет, это не я лукавлю, скорее вам надо чуть глубже погрузиться в вопрос, так как дьявол всегда кроется в деталях :)
Для начала я предлагаю вообще перестать говорить про AWS, сразу по нескольким причинам: санкционные риски для крупной компании в этом случае запредельны, требования российского законодательства нарушаются на каждом шагу (ФЗ 152 и т.п.)
Если вы разрабатываете один продукт без персональных данных, то публичное облако + cloud agnostic подход может быть для вас применим. Но при этом, боюсь, что только на старте и для небольших систем.
Почему я так думаю?
Представьте, что вам нужно перенести в другое облако не 1, не 10 приложений, а, к примеру, 100, или 200. Сколько времени займёт у вас такая миграция? Год для такого процесса - очень оптимистичный срок. Скорее 2-5 лет.
Как вы будете контролировать Cloud Agnostic? Запускается ещё один проект, в силу сложностей в коммуникациях до конечного инженера не донесли этот подход, или инженер на него забил, потому что "надо использовать новое, а не жить как староверы". И всё, в какой-то системе уже используется, скажем, Tarantool, который как сервис есть только в VK Cloud. А так как инженеры друг с другом часто общаются, то ещё через полгода тарантул появляется ещё в 10 проектах. И этот эффект сразу вы даже не заметите, узнаете как раз во время миграции. И даже с сотрудником ничего не сделать, так как он год как уволился.
Как быть с требованиями ИБ, которые не статичны? Как быть, если новое требование ИБ нереализуемо на конкретном облаке? Вам ИБ просто не согласует использование сторонних инфраструктурных площадок, т.к. данные компании физически "живут" в месте, которое компания никак не контролирует физически. Как пример: требование ИБ - авторизация только с помощью корпоративной учётки AD. Как это реализовать by default на всех виртуальных машинах, которые будут создаваться сотрудниками компании в публичном облаке? Административно заставить всех настраивать доменную авторизацию? Заставить всех использовать кастомные образы? А как это сделать для чего-то посложнее виртуальной машины, в том PostgreSQL/K8S as a service от публичного облака?
Тут в соседних комментариях уже упоминали немного про SLA, я расширю этот момент. Как управлять доступностью в публичном облаке? Как компании-потребитель предъявить требования к доступности сервисов? Что делать, если предлагаемая, либо обеспечиваемая доступность вас не устраивает?
Как добавить свой сервис в платформу? Я сейчас немного утрирую, чтобы было понятно. У сферического публичного провайдера нет redis as a service. При этом redis используется всё активнее, см пример с Tarantool. Даже в копии публичного облака, которое мы физически установили в нашем ДЦ для себя, это сделать было невозможно. Как и кастомизировать образ PostgreSQL as a Service под себя. В итоге у вас просто нет нужного сервиса и 4 тысячи сотрудников смотрят на вас как на идиота, потому что "именно вы приняли решение выбрать такого плохого провайдера услуг, ищите способ решения".
А для крупной компании, про которую и написана статья, всё описанное - не праздные вопросы, количество стейкхолдеров зашкаливает и вы просто не найдёте публичного провайдера, который предложит всё, что требуется. Либо предложит, но это уже будет не паблик, а форк паблика с огромным количеством минусов.
[1] постоянно этим занимаемся, это вполне нормальные сроки, если приложений много, не вижу вообще ничего плохого в том, чтобы не ломая ничего переехать постепенно. Просто новые проекты не разрешают создавать по старому и все за 2 года максимум переезжает.
[2] Контроль это вообще административное понятие, у вас же руководители способны контролировать инженеров? Надеюсь что да. Вот до руководителей доноситься это правило, они доносят до инжинеров.
Со второй стороны это как раз вашей структурой и должно контролироваться- в виде ассесмента/валидации КАЖДОГО нового сервиса. У нас это поставлено на поток, если ты поставил сервис в прод без валидации и добавления его в backstage- это равносильно запуску биткойн генератора по последствиям.
[3] ИБ не религия, с ними всегда можно договориться исходя из реалий бизнеса. Нужно вам получить определенный сертификат в этой области- смотрите что не попадает - идете к ИБ и к клауд провайдеру и разговариваете. Все эти стороны заинтересованы договориться. Да клауд провайдер может пилить сервис в нужную вам сторону дольше чем вы- например год. Но вы не единственные клиенты которые сталкиваются с такой проблемой, а провайдер держит нос по ветру и критичные вещи он должен быстро исправлять, ведь он то сам как то это сертификат получил ))
[4] Смотря что понимать под доступностью. В общем случае - использовать не один регион а 2-3, реплики БД, запасной провайдер. 3 региона у Яндекса уже надежнее ваших двух датацентров. Их тупо 3, а может быть 10 за совсем небольшие деньги.
[5]
https://cloud.yandex.ru/services/managed-redis
https://cloud.vk.com/databases/redis/
Ну и люди всегда будут ругать любой солюшен, какой бы он не был. Просто когда он сделан по канонам, гораздо больше людей понимает почему так, и не нужно тратить время на обьяснения
[1] И часть не переезжает вовсе. Вы не представляете, сколько систем в крупных организациях, которые когда-то кем-то были запущены, потом команда внедрения разошлась и осталось полтора инженера на поддержку. И что в итоге мы делаем, когда текущее облако не устраивает? Добавляем ещё одно, если я правильно понимаю? И даём выбор командам, в какое облако заезжать? И как всем этим хозяйством потом в компании управлять?
[2] Ещё хуже. Валидировать придётся каждый элемент информационной системы на всех этапах жизненного цикла. Как вы себе это представляете? Контролировать кто и что поставил на новую созданную виртуалку и как это что-то новое настроил, по стандартам, или нет? Это просто остановит любые изменения.
[3] Что делаем, если провайдер делает 90% нужного и не делает 10% нужного? А если соотношение 80 на 20? Спокойно смотрим, как 20% от 4000 человек говорят и вам, и руководству, что выбор данного конкретного облака был ошибочным? Наш подход очень простой - если есть востребованный, но отсутствующий сервис, то он реализуется. Точка.
[4] У вас пострадал сервис из-за того, что конкретный инфраструктурный элемент не работал 3 дня. Все средства обеспечения отказоустойчивости от Облака ограничены одним регионом, а иногда регионы ломаются целиком. Вы теряете примерно по миллиону в час и ничего не можете с этим сделать, эскалировать некому, поддержка говорит "мы чиним, ваш звонок очень важен для нас". По итогам месяца строго по договору получаете компенсацию в 10-50% от месячной стоимости этого инфраструктурного элемента.
[5] Спасибо, я умею пользоваться поиском и не зря написал, что утрирую. Я и так отлично знаю, что редис в облаках есть. Вопрос мой звучит очень просто - как добавить в публичное облако сервис, который востребован у нас но его нет у провайдера? Как этот вопрос решается? Сколько времени займёт? И ответ я знаю из собственного опыта, если что: "Можно открыть кошелёк и слёзно попросить провайдера. Времени займёт столько, сколько пожелает провайдер, если вообще возьмётся". Потому что каждый конкретный клиент, даже крупный - для провайдера это всего лишь один клиент.
Прочел с интересом. Но имея опыт работы на крупном проекте X5 видел как информация о проекте отобразила только удобную сторону проекта для менеджмента. В этой статье попахивает немного схоже. Хочется конечно сразу же увидеть мнение от конечных пользователей - уж больно много пафоса . Хотя должен признать - в Х5 сильная айти-культура. Но не все-таки не уровня мировых лидеров, чтобы писать "искали, но не нашли". Скорее, кажется, плохо искали по некоторым своим причинам. Переключение на инхаус - разработку для сложных систем напоминает создание уже изобретённых колёс заново, хотя сейчас понимаю ноги растут из-за конъюктуры на росс. рынке из-за войны.
Поздравляю с публикацией!
Видно, что проделана большая работа.
Наконец-то вижу статью на Хабре с настоящим уникальным и думающим подходом в таком большом инфраструктурном ландшафте.
Блестящее решение.
Каким образом частное облако обыграло публичное по скорости предоставления ресурсов утилизации?
Алсо, есть некоторые манипуляции. Тот факт, что предоставление ресурсов с т.з. согласований и закупок занимало времени - это прежде всего проблема процессов. Процессов запросов и согласований, процессов планирования.
Спасибо, очень интересно. Хорошо, что небольшая компания может воспользоваться сервисами небольшого локального облачного провайдера, а большая компания - сделать себе свое собственное родное облако прямо на железе. Потому что плохо, когда облаков на свете всего 3 и они в 2-3 раза дороже, чем можно бы было сделать самим.
Mirantis вынужден был проинформировать нас о том, что мы должны прекратить использование их программного обеспечения.
Каждый раз видя такую формулировку, так и подмывает спросить "а не то что вы нам сделаете если не прекратим?"
Мощный проект. Хотелось бы почитать подробнее от вас про:
Commodity-решения для сети. Что используете?
P.S.: зарубежные вендоры паблик клауд вполне себе используют вендорские коробки ;) И Cisco (в т.ч. с SONiC, понятно у кого, в первую очередь) и Arista и др. Но, с тз оркестрации они там и вправду довольно сильно commoditized.
На чём построен SDN? Управляете через нативные API вендора или Net. OS, или через прослойки в виде Ansible/TF (или что-то ещё, вроде Nornir)?
Как именно в нём осуществляете сегментацию и service insertion?
Есть какая-то хитрая оркестрация, непосредственно связанная с наличием контейнеров в вашей SDN?
Всегда интересовало как рассчитывается предполагаемая нагрузка и соответствующий ТСО (вы упомянули РСМ в комментариях - было бы интересно почитать про методологию исходя из вашего опыта на этом проекте)
При прочтении показалось, что ребенок прыгает перед забором, что бы его заметили, что вот он, что-то сделал и прыгает сильнее и сильнее....
Вы бьете себя в грудь.... да работа проделана большая, но ..... Если просчитать сколько вы отняли у бизнеса средств и времени. говоря, что вы реализовали что-то единственное вы бизнес повесили на крючок зависимости своего огорода...
Медленные ЦОД'ы ? - вы либо давно не выходили на улицу либо работали с интересными ЦОДами либо не умеете планировать рост потребления ресурсов, так как при начале работы с любым крупным Облачником, Вас спросят, сколько на старте, сколько через пол года, год и так далее, а так же любой облачник запустит Вам стойку до 3х недели...
По поводу единого окна с одним поставщиком - да, тема хорошая, но тогда как раз и нет прозрачности фин модели, потому-что подрядчик начнем перераспределять ваши затраты с одной слуги на другую когда вы будите где-то оптимизировать или перестраивать себя...
Как бы это правильно сказать,.... а жаба надутая через палочку....) , а так да молодцы ?
наоборот изменения мы согласуем с сообществом разработчиков и добиваемся их включения в Upstream (направление развития сообщества разработчиков, последние версии ПО с открытым кодом).
посмотрел я тут в https://www.stackalytics.io/, и в последнем релизе OpenStack нашел один коммит от it-key https://www.stackalytics.io/?company=itkey&metric=commits и один или selectel https://www.stackalytics.io/?company=selectel&metric=commits, очень интересно как вы добиватесь включения изменений в апстрим, дело очень не простое, я немножко пробовал
Облачная трансформация ИТ инфраструктуры современной компании. Практический опыт Х5 Group