However, there was one useful feature we found difficult to implement: an easier way to share Polaris reports. To help address this need, we’re excited to announce a new service: Polaris Snapshot. Polaris Snapshot will let you generate a report, hosted at polaris.fairwinds.com, that you can share with your team. We see this as a great way for teams to sync on how to make their Kubernetes workloads more stable, efficient, and secure.
Буду занудной — ну и ладно. Как же можно "GNU/Linux" через обратный слэш?! Элементарная грамотность, после которой (уже в заголовке) опасно читать статью.
велосипеды придется развивать и поддерживать кому-то, править там баги, проводить тесты, то есть это по сути еще одни затраты по деньгами и времени для компании
Спасибо за совет, но я искренне удивлён, если вы думаете, что мы это всё не понимаем :-) Мы не первый год на рынке, да и разработкам этим уже далеко не один год. Так что не просто понимаем, а видим в конкретных цифрах (сколько времени уходит на их развитие и какую пользу они приносят бизнесу). Возможно, у вас просто неполное понимание конкретно нашей картины и/или другой опыт: другие масштабы разработок, компании, ещё что-то другое…
Странное у вас представление о бизнесе («расчётах стоимости»), если автор выше уже написал, что изначально мы пользовались тем, что предоставляет тот же Redmine из коробки… а уж за 8+ лет его использования (я даже не поленился проверить дату первого issue в нашей базе) — и не из коробки тоже, поверьте :-))
У нас предостаточно более целевой (= приносящей прямые деньги) работы, чем разработка внутренних сервисов.
Мы, даже будучи большими любителями Open Source и обладая огромной компетенцией в администрировании, в своё время отказались от разновидностей чатов типа self-hosted в пользу платного(!) Slack. И за много лет ещё не передумали…
TL;DR: если какие-то внутренние разработки появляются — на то есть очень весомые бизнес-причины.
Проблема в том, что всё воспроизводится и на стороне сервера тоже (посему в начале написано, что kubectl и API Server, а не только kubectl). Но большое спасибо за комментарий: сейчас сделаю формулировки более явными и заменю пример в конце публикации.
P.S. Это формат новости, а не полноценный пост ;-)
Неявно подразумевается, что да (ведь речь идёт про весь 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»:
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.
Я не оспаривал, что процесс во многом организационный. Но выше уже писал, что он также требует технических средств для реализации. Могут использоваться разные средства — в данном случае выбрали Kubernetes, и выбор себя оправдал. Было бы так же хорошо с другими? Можем только гадать. Лично мне странно сравнивать «Jenkins со скриптами» и то, что может предложить Kubernetes, но спор ради спора скучен.
Значительно упрощает этот процесс, автоматизируя всё (выкатывание кода + сопутствующей инфраструктуры по всему pipeline и т.п.). Когда что-то автоматизируется и ускоряется, выкатываться чаще становится просто (и этим действительно начинают пользоваться).
Это всё-таки формат новостей, а не полноценных статей…
Вот нашлось выступление на KubeCon'18 (да, ещё год назад!): «The Journey of Adidas to a Global Kubernetes Rollout» (видео) — от представителей adidas и Giant Swarm. (А также их аналогичное выступление на ContainerDays.) Нашлись даже слайды к нему, однако они довольно бесполезны (там никакой «техники»). В докладе же озвучивают некоторые детали, но визуализируют их слабо — надо внимательно слушать.
Как пишут ниже, порядок действительно навели: реорганизовали и команды, и архитектуру/подход («general shift towards microservices»). В тексте новости, кстати, уже говорилось о том, что они собирались «модернизировать свою инфраструктуру и сопутствующие процессы». Однако для реализации изменений и техническая основа нужна, так что совсем «списывать со счетов» Kubernetes я бы не стал.
Заголовок вводит в заблуждение относительно содержимого. Оригинал звучит как «Connect to MySQL after hitting ERROR 1040: Too many connections» и лишён такой проблемы.
Для тех, кто разворачивает Kubernetes в облаках вроде AWS, есть специальная утилита Kubecost, помогающая находить способы сэкономить постоянные затраты. На прошлой неделе здесь публиковали её обзор.
What is the difference between a Kubernetes cluster using 100x n1-standard-1 (1 vCPU) VMs VS having 1x n1-standard-96 (vCPU 96), or 6x n1-standard-16 VMs (vCPU 16)?
Звучит так, что это только для Azure? Тогда по определению нам не подходит: очень разные провайдеры используются у клиентов. В начале указано требование про Kubernetes — так вот он развернут и в Google, и в AWS, и в Azure, и даже бывает bare metal.
fairwinds.com/polaris-snapshot
В обновлённой версии этого обзора для нашего англоязычного блога: Comparing Ingress controllers for Kubernetes.
Буду занудной — ну и ладно. Как же можно "GNU/Linux" через обратный слэш?! Элементарная грамотность, после которой (уже в заголовке) опасно читать статью.
Спасибо за совет, но я искренне удивлён, если вы думаете, что мы это всё не понимаем :-) Мы не первый год на рынке, да и разработкам этим уже далеко не один год. Так что не просто понимаем, а видим в конкретных цифрах (сколько времени уходит на их развитие и какую пользу они приносят бизнесу). Возможно, у вас просто неполное понимание конкретно нашей картины и/или другой опыт: другие масштабы разработок, компании, ещё что-то другое…
У нас предостаточно более целевой (= приносящей прямые деньги) работы, чем разработка внутренних сервисов.
Мы, даже будучи большими любителями Open Source и обладая огромной компетенцией в администрировании, в своё время отказались от разновидностей чатов типа self-hosted в пользу платного(!) Slack. И за много лет ещё не передумали…
TL;DR: если какие-то внутренние разработки появляются — на то есть очень весомые бизнес-причины.
P.S. Это формат новости, а не полноценный пост ;-)
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»:
(источник)
Вот нашлось выступление на KubeCon'18 (да, ещё год назад!): «The Journey of Adidas to a Global Kubernetes Rollout» (видео) — от представителей adidas и Giant Swarm. (А также их аналогичное выступление на ContainerDays.) Нашлись даже слайды к нему, однако они довольно бесполезны (там никакой «техники»). В докладе же озвучивают некоторые детали, но визуализируют их слабо — надо внимательно слушать.
Как пишут ниже, порядок действительно навели: реорганизовали и команды, и архитектуру/подход («general shift towards microservices»). В тексте новости, кстати, уже говорилось о том, что они собирались «модернизировать свою инфраструктуру и сопутствующие процессы». Однако для реализации изменений и техническая основа нужна, так что совсем «списывать со счетов» Kubernetes я бы не стал.