Comments 32
Хотелось бы больше конкретики, причем от самой Адидас.
А то там окажется, что все крутится на SAP, а контейнеры у них для лендинга бутс Криштиану используется.
А то там окажется, что все крутится на SAP, а контейнеры у них для лендинга бутс Криштиану используется.
UFO just landed and posted this here
Это всё-таки формат новостей, а не полноценных статей…
Вот нашлось выступление на KubeCon'18 (да, ещё год назад!): «The Journey of Adidas to a Global Kubernetes Rollout» (видео) — от представителей adidas и Giant Swarm. (А также их аналогичное выступление на ContainerDays.) Нашлись даже слайды к нему, однако они довольно бесполезны (там никакой «техники»). В докладе же озвучивают некоторые детали, но визуализируют их слабо — надо внимательно слушать.
Как пишут ниже, порядок действительно навели: реорганизовали и команды, и архитектуру/подход («general shift towards microservices»). В тексте новости, кстати, уже говорилось о том, что они собирались «модернизировать свою инфраструктуру и сопутствующие процессы». Однако для реализации изменений и техническая основа нужна, так что совсем «списывать со счетов» Kubernetes я бы не стал.
Вот нашлось выступление на KubeCon'18 (да, ещё год назад!): «The Journey of Adidas to a Global Kubernetes Rollout» (видео) — от представителей adidas и Giant Swarm. (А также их аналогичное выступление на ContainerDays.) Нашлись даже слайды к нему, однако они довольно бесполезны (там никакой «техники»). В докладе же озвучивают некоторые детали, но визуализируют их слабо — надо внимательно слушать.
Как пишут ниже, порядок действительно навели: реорганизовали и команды, и архитектуру/подход («general shift towards microservices»). В тексте новости, кстати, уже говорилось о том, что они собирались «модернизировать свою инфраструктуру и сопутствующие процессы». Однако для реализации изменений и техническая основа нужна, так что совсем «списывать со счетов» Kubernetes я бы не стал.
Я не очень понимаю как именно Кубер сокращает время релизов. Я и на IIS могу релизить 4 раза в день и что? Причем тут контейнеры?
Значительно упрощает этот процесс, автоматизируя всё (выкатывание кода + сопутствующей инфраструктуры по всему pipeline и т.п.). Когда что-то автоматизируется и ускоряется, выкатываться чаще становится просто (и этим действительно начинают пользоваться).
Ну все тоже самое можно делать каким нибудь Azure DevOps. А раньше все это делали скриптами в каком-нибудь Дженкинсе.
Вопрос автоматизации — это процесс организационный, а не серебряная пуля внедрил контейнеры все-сразу-стало-круто. В хороших компаниях CI/CD и раньше работал как часы, когда и контейнеров-то современных не было.
И это я еще не брал сам факт перехода в контейнер, безопасность и удобство их администрирования а также зарплату людей, кто сможет нормально решить эти пункты.
Вопрос автоматизации — это процесс организационный, а не серебряная пуля внедрил контейнеры все-сразу-стало-круто. В хороших компаниях CI/CD и раньше работал как часы, когда и контейнеров-то современных не было.
И это я еще не брал сам факт перехода в контейнер, безопасность и удобство их администрирования а также зарплату людей, кто сможет нормально решить эти пункты.
Я не оспаривал, что процесс во многом организационный. Но выше уже писал, что он также требует технических средств для реализации. Могут использоваться разные средства — в данном случае выбрали Kubernetes, и выбор себя оправдал. Было бы так же хорошо с другими? Можем только гадать. Лично мне странно сравнивать «Jenkins со скриптами» и то, что может предложить Kubernetes, но спор ради спора скучен.
Адидас не только делает спортивную одежду но и софт?
adidas.github.io
Ну и они нанимают backend девелоперов.
Ну и они нанимают backend девелоперов.
The 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.
(источник)
UFO just landed and posted this here
Ещё несколько лет назад обычному разработчику в adidas могла потребоваться неделя(!) для того, чтобы получить виртуальную машину
А причём здесь Kubernetes? :) Напрашивается, что тут организационная проблема.
Итогом 6-месячного проекта стал 100%-ный запуск сайта электронной коммерции (e-commerce) adidas на Kubernetes, благодаря чему:
его время отклика сократилось вдвое;
релизы стали происходить по 3-4 раза в день (раньше новый релиз выкатывался раз в 4-6 недель).
Ну вот прямо это всё заслуги Kubernetes?
Поверхностные причинно-следственные связи озвучены, которые сподвигнут неопытных IT-специалистов на длинную петлю проб и ошибок, т.к. за всем этим стоит не сам Kubernetes, а работа инженеров.
Вообще секта контейнеризации пришла после секты блокчейна и биг даты, но перед сектой AI.
А до всего этого были Аджайл трансформации.
Честно, как чуваку с 13+ годами в разработке я тут вижу только что одним товарищам нужно свои консалтинговые услуги впарить, другим товарищам бюджет побольше получить, ну а програмистам получать чуть больше бабла за наличие в резюме нескольких волшебных строчек.
А до всего этого были Аджайл трансформации.
Честно, как чуваку с 13+ годами в разработке я тут вижу только что одним товарищам нужно свои консалтинговые услуги впарить, другим товарищам бюджет побольше получить, ну а програмистам получать чуть больше бабла за наличие в резюме нескольких волшебных строчек.
Да контейнеризация это хорошо, плохо что некоторые непонимают где оно плохо :)
Kubernetes даёт API и другие плюшки, но надо понимать какой ценой.
И всёравно если кластер нужен для автоматизации чего-либо, аля SaaS PaaS, то всёравно надо будет обвязывть всё своими скриптами.
А если так, то может и Docker swarm пойдёт.
Тут даже не силами своих devops всё сделано, а интеграторов позвали.
Недавно статья была, как небольшой компании два отдельных devops сотрудника потребовалось, чтобы свой Kubernetes обслуживать :)
Прямо перед переходом надо в начале считать экономику — кластер должен позволить или уволить админа, или программиста или дать экономию по железу, ну естественно если речь не идёт о подготовке к 10x росту зоопарка ИС :)
Kubernetes даёт API и другие плюшки, но надо понимать какой ценой.
И всёравно если кластер нужен для автоматизации чего-либо, аля SaaS PaaS, то всёравно надо будет обвязывть всё своими скриптами.
А если так, то может и Docker swarm пойдёт.
Тут даже не силами своих devops всё сделано, а интеграторов позвали.
Недавно статья была, как небольшой компании два отдельных devops сотрудника потребовалось, чтобы свой Kubernetes обслуживать :)
Прямо перед переходом надо в начале считать экономику — кластер должен позволить или уволить админа, или программиста или дать экономию по железу, ну естественно если речь не идёт о подготовке к 10x росту зоопарка ИС :)
Я и не говорю, что контейнеры зло. Но вот экономика таких решений отрицательна. Потому что админов меньше не становится, а зарплаты их растут, ибо Модно.
Ну а если у нас рост 10x к количеству серверов, я вообще бы стал смотреть в сторону Azure/AWS, там более чем всего достаточно для быстрого роста. Главное архитектуру продумать.
И главное. Зачем релизить 5 раз в день? В чем тут бизнес-идея?
Ну а если у нас рост 10x к количеству серверов, я вообще бы стал смотреть в сторону Azure/AWS, там более чем всего достаточно для быстрого роста. Главное архитектуру продумать.
И главное. Зачем релизить 5 раз в день? В чем тут бизнес-идея?
Адидас как раз 90%, что сидит на Сапе (либо его порождений) как центральной системе для контроля остатков, и производства. в продакшене систем которые могу вынести большие нагрузки, включая отсутствие багов не так много…
А вот остальные части — аналитика, дизайнер-программы и т.д. + дополнения к скелету сапа и есть, то что описано в статье, вот и все.
Вряд ли серьезный продакшен будет на своей шкуре оттачивать умения программистов, нужен хребет учетная система при том, что скорее всего требования к ней — чтобы была сертифицирована и иностранная ( бэк офис).
это личное ИМХО на опыте аналогичных работ
А вот остальные части — аналитика, дизайнер-программы и т.д. + дополнения к скелету сапа и есть, то что описано в статье, вот и все.
Вряд ли серьезный продакшен будет на своей шкуре оттачивать умения программистов, нужен хребет учетная система при том, что скорее всего требования к ней — чтобы была сертифицирована и иностранная ( бэк офис).
это личное ИМХО на опыте аналогичных работ
Согласен с коллегами, что статья даёт неверный посыл — что кубернетес — серебряная пуля и решит все проблемы бизнеса. К сожалению, это не так.
Я был бы очень рад, если был проведен сравнительный анализ внедрения кубернетеса против переезда на тот же Амазон, благо adidas как крупная европейская компания могла себе это позволить (да и не нарушая при этом всякие GDPR).
Отдельный вопрос — я так понял, что у Адидас кубернетес именно в продакшен, т.к. говорится про e-commerce сайт. А базы у них где? Разработка — понятно мигрировала, причем только с радостью. В общем — как-то поверхностно, ожидаешь большей глубины.
Очень интересный вопрос — у них облачный куб, managed, или какое-то гибридное решение cloud + on-premise.
Короче — я пошел искать и читать первоисточник этой классной новости
Выше в комментариях приведена ссылка на видео с выступлением авторов миграции. Речь про весь production для e-commerce как минимум.
Так фронты или бд тоже? :-) Как будто в видео и статье это о(у-)пущено
Так там вообще одна вода. Выглядит так, как освоили бюджет.
Не удивлюсь, что продакшен у них это контейнеры с лендингом, получением товаров через рест апи и размещение заказов через очередь из/в SAP.
Не удивлюсь, что продакшен у них это контейнеры с лендингом, получением товаров через рест апи и размещение заказов через очередь из/в SAP.
Неявно подразумевается, что да (ведь речь идёт про весь 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»:
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»:
Попахивает редкостной прохладой.
В ядре Линукса в 2017 году было 18 млн. строчек кода. В Винде XP 45 млн. В каком-нибудь Umbraco-CMS пара миллионов строчек. А в самой знаменитой софтверной компании умудрились 100 млн за год наговнокодить.
Успех, я считаю.
В ядре Линукса в 2017 году было 18 млн. строчек кода. В Винде XP 45 млн. В каком-нибудь Umbraco-CMS пара миллионов строчек. А в самой знаменитой софтверной компании умудрились 100 млн за год наговнокодить.
Успех, я считаю.
360ТБ — не так уж и много. У нас измеряется десятками, если не сотнями ПБ.
100 млн строк кода — можно повернуть по-разному. Это за какое время было столько сгенерировано написано разрабами? Это все код, включая тесты? Или там есть автогенерированный код (шаблонизаторами и генераторами)? Или инфраструктурный код включен? Не ясно.
2300 битбакет аккаунтов — это, кстати, интересная и понятная метрика. Это говорит примерно о размере команд разработки. Другой вопрос — сколько из них мертвых душ?
Т.е. опять вопрос в интерпретации данных и соотносении их с другими такими же данными.
Адидас подобрал под себя один из фитнес-трекеров Runtastic.
На днях обновился внешний вид приложения, вебная версия (я ей пользовался и бал благодарен за её наличие, пользоваться большим экраном с клавиатурой и мышью удобнее чем тыкать толстыми пальцами в маленький экран) была уничтожена полностью.
Много преобразований, но фундаментальные баги в этомговнозамечательном софте, который выкатывается в прод хоть по 100 раз в день не изводятся годами. Это конечно не проблема только Адидаса/Рантастика, все остальные приложения для бегунов примерно такого же качества. Из-за неизводимых багов в runkeeper я в своё время перешел с него на рантастик. Runkeeper, Nike Running, endomondo, mifit, garmin — все одним качеством мазаны. Видимо такая бизнес-модель.
Когда еще пользовался runkeeper постоянно писал багрепорты, но эффективность этого была почти нулевая.
На днях обновился внешний вид приложения, вебная версия (я ей пользовался и бал благодарен за её наличие, пользоваться большим экраном с клавиатурой и мышью удобнее чем тыкать толстыми пальцами в маленький экран) была уничтожена полностью.
Много преобразований, но фундаментальные баги в этом
Когда еще пользовался runkeeper постоянно писал багрепорты, но эффективность этого была почти нулевая.
В реальности, наверное, года 3-4 люди сначала страдали, искали корни проблем, искали решения, пробовали разные подходы, кто-нибудь охрип доказывать и обосновывать переход на какой-нибудь Kanban или Scrum традиционным менеджерам, внедряли кучу инженерных практик типа user stories, TDD, Code review, feature branches, branch by abstraction, evolutionary database design, trank based development и тп, лажали, переделывали, опять лажали, что-то у них получалось, обучали других, распространяли успешные практики… ну и в конце концов под конец внедрили Kubernetes до кучи)))) ну и теперь флант публикует такую новость )))
Не совсем ясно, насколько увеличились расходы при переходе от ежемесячных релизов к ежечасным (при сохранении того же уровня качества, обеспечиваемого тестами разных уровней).
Кто бы написал как весело на кубе хостить крупные проекты — хотя бы больше 5к инстансов сервисов с партиционированием, zero downtime и тд и тп :) Постоянно после таких новостей приходится от менеджмента отпинываться :D
Зависит от самих нагрузок, что там запускаются, но если в целом про большие кластеры, то:
- OpenAI рассказывали о своем опыте больших инсталляций Kubernetes: Scaling Kubernetes to 2,500 Nodes и Scaling Kubernetes to 7,500 Nodes.
- Была такая статья в блоге Red Hat: OpenShift/Kubernetes Failure Stories at Scale — Lessons Learned from Large and Dense Deployments.
- Сам не смотрел этот доклад, но тоже может быть по теме: «Kubernetes в Booking.com (Иван Круглов, Booking.com)».
Sign up to leave a comment.
В adidas перешли на Kubernetes, сократив время релизов в ~100 раз