Специалисты всемирно известного производителя спортивной обуви и одежды adidas провели миграцию своей инфраструктуры на платформу, основанную на Kubernetes, и пришли к качественно новому циклу выпуска обновлений разрабатываемого в компании программного обеспечения.
Ещё несколько лет назад обычному разработчику в adidas могла потребоваться неделя(!) для того, чтобы получить виртуальную машину. Как уточняет Daniel Eichten, директор по Platform Engineering в adidas, такая простая операция начиналась со специального запроса с указанием назначения ВМ, названия проекта, ответственного и т.п. В лучших случаях всё удавалось сделать за полчаса, однако ряд обстоятельств мог увеличить этот срок и до целой недели. Тогда в компании решили «посмотреть на ситуацию глазами разработчика» и найти способы модернизировать свою инфраструктуру и сопутствующие процессы.
В итоге, в adidas пришли к необходимости использования контейнеров, принятия гибкой (agile) методологии разработки и создания современной облачной платформы. Среди выбранных технических средств для реализации задуманного оказались Kubernetes и Prometheus:
«Выбор Kubernetes был достаточно понятен. День нулевой (имеется в виду Day 0 как первая фаза жизненного цикла информационной системы — прим. перев.): принятие решения — всё просто. День первый: установка, конфигурация — тоже просто. День второй: запуск и испытания даже с небольшими нагрузками… если что-то пойдёт не так, вы уже не знаете, как вся система работает, и теряетесь. Нам потребовался партнёр, который помог бы решить проблемы „второго дня“».
Таким партнёром в начале 2017 года стала компания Giant Swarm (родом из Германии, как и сама adidas), специализирующаяся на внедрении и обслуживании Kubernetes-кластеров.
Итогом 6-месячного проекта стал 100%-ный запуск сайта электронной коммерции (e-commerce) adidas на Kubernetes, благодаря чему:
- его время отклика сократилось вдвое;
- релизы стали происходить по 3-4 раза в день (раньше новый релиз выкатывался раз в 4-6 недель).
Общая инфраструктура на базе Kubernetes теперь насчитывает 4000 pod'ов на 200 узлах. В ней производится 80 тысяч сборок кода в месяц и запущено 40 % от всех наиболее критичных систем компании.
P.S.
Читайте также в нашем блоге:
Комментарии (30)
RomanZon
25.09.2019 15:41Адидас не только делает спортивную одежду но и софт?
shurup Автор
25.09.2019 20:46The next session – Adidas’ – was run by Fernando Carnago. Fernando explained how Adidas is becoming a programming company. In only 4 years, a group of just a few engineers grew into a team of over 300. Fernando talked about changing the focus of a company – from making sportswear to creating software for data processing. His amazing lecture showed how to present the benefits of new technologies through immense branding action carried out within the structures of a company. By means of films, articles, gamification and hackatowns, which – in case of Adidas – changed the way of thinking of every employee, not only IT guys. As it turned out, the presentation fostered new, amazing ideas in the production department. This allowed Adidas to implement 80 000 changes in the production process in a single month, which in turn allowed the company to collect and use 360 TB of data in data lake.
(источник)
VolodjaT
25.09.2019 16:25+2Когда я работал в айти-конторе и садился программировать, ПМ всё время как-бы невзначай крутился возле кубикла, и всё спрашивал, что ты там затих, почему не слышно как ты релизиш? первый раз я не ответил, так он начал ломиться в дверь, и орать, ты чем там занят, что с тобой? начал материться, и говорить, что вообще на меня инцидент создаст и до кастомера проэскалирует, алсо, ПМ ругался, если я пишу код и не резижу, причём не просто вконце реализации фичи, а непосредственно после написания каждой строчки, мотивировал это тем, что вдруг что-то случится и состояние проекта должно быть на сервере, и сам потом мне говорил: вот я напишу и сразу релижу, и ты так делай! однажды я работать сел, и слышу, ПМ где-то у принтера встал в отдалении, ну я бранч смерджил, и на пол накарачики присел, а там щель очень широкая снизу у перегородки, ну я в щель и смотрю, а там ПМ на карачиках сидит и в щель смотрит, и мне говорит: ты чё? еб***й? чё ты там делаешь? ПМ кстати всё время какие-то тренинги посещает, чтобы релизить часто, релизит по 5 раз в день, а потом говорит, что руки устали, и ещё менторит он. п****ц короче! реальная история. я не джун
Sovetnikov
25.09.2019 17:23Ещё несколько лет назад обычному разработчику в adidas могла потребоваться неделя(!) для того, чтобы получить виртуальную машину
А причём здесь Kubernetes? :) Напрашивается, что тут организационная проблема.
Итогом 6-месячного проекта стал 100%-ный запуск сайта электронной коммерции (e-commerce) adidas на Kubernetes, благодаря чему:
его время отклика сократилось вдвое;
релизы стали происходить по 3-4 раза в день (раньше новый релиз выкатывался раз в 4-6 недель).
Ну вот прямо это всё заслуги Kubernetes?
Поверхностные причинно-следственные связи озвучены, которые сподвигнут неопытных IT-специалистов на длинную петлю проб и ошибок, т.к. за всем этим стоит не сам Kubernetes, а работа инженеров.euroUK
25.09.2019 17:28+2Вообще секта контейнеризации пришла после секты блокчейна и биг даты, но перед сектой AI.
А до всего этого были Аджайл трансформации.
Честно, как чуваку с 13+ годами в разработке я тут вижу только что одним товарищам нужно свои консалтинговые услуги впарить, другим товарищам бюджет побольше получить, ну а програмистам получать чуть больше бабла за наличие в резюме нескольких волшебных строчек.Sovetnikov
25.09.2019 17:37+2Да контейнеризация это хорошо, плохо что некоторые непонимают где оно плохо :)
Kubernetes даёт API и другие плюшки, но надо понимать какой ценой.
И всёравно если кластер нужен для автоматизации чего-либо, аля SaaS PaaS, то всёравно надо будет обвязывть всё своими скриптами.
А если так, то может и Docker swarm пойдёт.
Тут даже не силами своих devops всё сделано, а интеграторов позвали.
Недавно статья была, как небольшой компании два отдельных devops сотрудника потребовалось, чтобы свой Kubernetes обслуживать :)
Прямо перед переходом надо в начале считать экономику — кластер должен позволить или уволить админа, или программиста или дать экономию по железу, ну естественно если речь не идёт о подготовке к 10x росту зоопарка ИС :)euroUK
25.09.2019 17:41Я и не говорю, что контейнеры зло. Но вот экономика таких решений отрицательна. Потому что админов меньше не становится, а зарплаты их растут, ибо Модно.
Ну а если у нас рост 10x к количеству серверов, я вообще бы стал смотреть в сторону Azure/AWS, там более чем всего достаточно для быстрого роста. Главное архитектуру продумать.
И главное. Зачем релизить 5 раз в день? В чем тут бизнес-идея?
laptei
25.09.2019 18:06+1Адидас как раз 90%, что сидит на Сапе (либо его порождений) как центральной системе для контроля остатков, и производства. в продакшене систем которые могу вынести большие нагрузки, включая отсутствие багов не так много…
А вот остальные части — аналитика, дизайнер-программы и т.д. + дополнения к скелету сапа и есть, то что описано в статье, вот и все.
Вряд ли серьезный продакшен будет на своей шкуре оттачивать умения программистов, нужен хребет учетная система при том, что скорее всего требования к ней — чтобы была сертифицирована и иностранная ( бэк офис).
это личное ИМХО на опыте аналогичных работ
gecube
25.09.2019 18:33Согласен с коллегами, что статья даёт неверный посыл — что кубернетес — серебряная пуля и решит все проблемы бизнеса. К сожалению, это не так.
Я был бы очень рад, если был проведен сравнительный анализ внедрения кубернетеса против переезда на тот же Амазон, благо adidas как крупная европейская компания могла себе это позволить (да и не нарушая при этом всякие GDPR).
Отдельный вопрос — я так понял, что у Адидас кубернетес именно в продакшен, т.к. говорится про e-commerce сайт. А базы у них где? Разработка — понятно мигрировала, причем только с радостью. В общем — как-то поверхностно, ожидаешь большей глубины.
Очень интересный вопрос — у них облачный куб, managed, или какое-то гибридное решение cloud + on-premise.
Короче — я пошел искать и читать первоисточник этой классной новости
shurup Автор
25.09.2019 19:25Выше в комментариях приведена ссылка на видео с выступлением авторов миграции. Речь про весь production для e-commerce как минимум.
gecube
25.09.2019 20:27Так фронты или бд тоже? :-) Как будто в видео и статье это о(у-)пущено
euroUK
25.09.2019 20:56Так там вообще одна вода. Выглядит так, как освоили бюджет.
Не удивлюсь, что продакшен у них это контейнеры с лендингом, получением товаров через рест апи и размещение заказов через очередь из/в SAP.
shurup Автор
25.09.2019 20:57Неявно подразумевается, что да (ведь речь идёт про весь 100% e-commerce, а как это он без БД?), но однозначного ответа и подробностей в официальных источниках не вижу.
P.S. Нашёл более свежее их выступление, уже в этом году: «Adidas Digital Platform: Where Cloud Native Meets the Sporting Goods Industry». Нет сейчас возможности послушать детали, но выглядит серьёзно.
P.P.S. И ещё нашёл такой слайд этого же года с комментарием «Impressive CloudNative figures for a clothing company like Adidas»:
euroUK
25.09.2019 21:55Попахивает редкостной прохладой.
В ядре Линукса в 2017 году было 18 млн. строчек кода. В Винде XP 45 млн. В каком-нибудь Umbraco-CMS пара миллионов строчек. А в самой знаменитой софтверной компании умудрились 100 млн за год наговнокодить.
Успех, я считаю.
gecube
26.09.2019 13:08360ТБ — не так уж и много. У нас измеряется десятками, если не сотнями ПБ.
100 млн строк кода — можно повернуть по-разному. Это за какое время было столькосгенерированонаписано разрабами? Это все код, включая тесты? Или там есть автогенерированный код (шаблонизаторами и генераторами)? Или инфраструктурный код включен? Не ясно.
2300 битбакет аккаунтов — это, кстати, интересная и понятная метрика. Это говорит примерно о размере команд разработки. Другой вопрос — сколько из них мертвых душ?
Т.е. опять вопрос в интерпретации данных и соотносении их с другими такими же данными.
snvtr
26.09.2019 12:14Адидас подобрал под себя один из фитнес-трекеров Runtastic.
На днях обновился внешний вид приложения, вебная версия (я ей пользовался и бал благодарен за её наличие, пользоваться большим экраном с клавиатурой и мышью удобнее чем тыкать толстыми пальцами в маленький экран) была уничтожена полностью.
Много преобразований, но фундаментальные баги в этомговнозамечательном софте, который выкатывается в прод хоть по 100 раз в день не изводятся годами. Это конечно не проблема только Адидаса/Рантастика, все остальные приложения для бегунов примерно такого же качества. Из-за неизводимых багов в runkeeper я в своё время перешел с него на рантастик. Runkeeper, Nike Running, endomondo, mifit, garmin — все одним качеством мазаны. Видимо такая бизнес-модель.
Когда еще пользовался runkeeper постоянно писал багрепорты, но эффективность этого была почти нулевая.
Savochkin
26.09.2019 20:58В реальности, наверное, года 3-4 люди сначала страдали, искали корни проблем, искали решения, пробовали разные подходы, кто-нибудь охрип доказывать и обосновывать переход на какой-нибудь Kanban или Scrum традиционным менеджерам, внедряли кучу инженерных практик типа user stories, TDD, Code review, feature branches, branch by abstraction, evolutionary database design, trank based development и тп, лажали, переделывали, опять лажали, что-то у них получалось, обучали других, распространяли успешные практики… ну и в конце концов под конец внедрили Kubernetes до кучи)))) ну и теперь флант публикует такую новость )))
gecube
26.09.2019 22:02Не стреляйте в Флант — они переводят как умеют )))
Новость-то в оригинале с сайта фонда CNCF, т.е. именно они решили пропиариться )
cross_join
27.09.2019 13:35+1Не совсем ясно, насколько увеличились расходы при переходе от ежемесячных релизов к ежечасным (при сохранении того же уровня качества, обеспечиваемого тестами разных уровней).
euroUK
Хотелось бы больше конкретики, причем от самой Адидас.
А то там окажется, что все крутится на SAP, а контейнеры у них для лендинга бутс Криштиану используется.
eumorozov
Да, все эти чудо истории вызывают у меня скептицизм. Скорее всего, раньше был бардак, и выкатывание релиза вручную. При переходе просто навели порядок и автоматизировали, соответственно заслуга, скорее всего, не Kubernetes, а глобального рефакторинга.
euroUK
Зная немцев, их страсть к бумажкам и документированию, я не верю вообще, что бизнес-критические процессы у них могут релизы по 3-4 раза в день накатываться. Вот раз в 4 недели это более вероятно.
fougasse
У вас странное мнение о немцах, очень стереотипное.
shurup Автор
Это всё-таки формат новостей, а не полноценных статей…
Вот нашлось выступление на KubeCon'18 (да, ещё год назад!): «The Journey of Adidas to a Global Kubernetes Rollout» (видео) — от представителей adidas и Giant Swarm. (А также их аналогичное выступление на ContainerDays.) Нашлись даже слайды к нему, однако они довольно бесполезны (там никакой «техники»). В докладе же озвучивают некоторые детали, но визуализируют их слабо — надо внимательно слушать.
Как пишут ниже, порядок действительно навели: реорганизовали и команды, и архитектуру/подход («general shift towards microservices»). В тексте новости, кстати, уже говорилось о том, что они собирались «модернизировать свою инфраструктуру и сопутствующие процессы». Однако для реализации изменений и техническая основа нужна, так что совсем «списывать со счетов» Kubernetes я бы не стал.
euroUK
Я не очень понимаю как именно Кубер сокращает время релизов. Я и на IIS могу релизить 4 раза в день и что? Причем тут контейнеры?
shurup Автор
Значительно упрощает этот процесс, автоматизируя всё (выкатывание кода + сопутствующей инфраструктуры по всему pipeline и т.п.). Когда что-то автоматизируется и ускоряется, выкатываться чаще становится просто (и этим действительно начинают пользоваться).
euroUK
Ну все тоже самое можно делать каким нибудь Azure DevOps. А раньше все это делали скриптами в каком-нибудь Дженкинсе.
Вопрос автоматизации — это процесс организационный, а не серебряная пуля внедрил контейнеры все-сразу-стало-круто. В хороших компаниях CI/CD и раньше работал как часы, когда и контейнеров-то современных не было.
И это я еще не брал сам факт перехода в контейнер, безопасность и удобство их администрирования а также зарплату людей, кто сможет нормально решить эти пункты.
shurup Автор
Я не оспаривал, что процесс во многом организационный. Но выше уже писал, что он также требует технических средств для реализации. Могут использоваться разные средства — в данном случае выбрали Kubernetes, и выбор себя оправдал. Было бы так же хорошо с другими? Можем только гадать. Лично мне странно сравнивать «Jenkins со скриптами» и то, что может предложить Kubernetes, но спор ради спора скучен.