Cloud computing

О своём опыте построения пайплайнов, правильных и неправильных подходах к CI/CD, здоровых профессиональных конфликтах и реализации GitOps в неидеальном мире рассказывают спикеры курса Слёрма по CI/CD Тимофей Ларкин и Александр Швалов.

Кто говорит

Тимофей Ларкин
Руководил направлением автоматизации в дирекции BigData компании X5 Retail Group, строил платформу для разработки и хостинга продуктов. Сейчас работает платформенным инженером Тинькофф.

Александр Швалов
Инженер Southbridge, настраивает и сопровождает проекты на Kubernetes. Помогал настраивать CI/CD как для небольших, так и для крупных компаний. Certified Kubernetes Administrator.

Почему тема настройки CI/CD до сих пор остаётся актуальна? Почему до сих пор все не научились это делать?

Т: Я думаю, по той же причине, по которой уже одиннадцать лет существует слово DevOps, но некоторые компании и коллективы только-только запускают так называемую DevOps-трансформацию. По той же причине, что всегда есть отстающие, которые пока в группе Low Performеrs. Не все ещё научились. Не всем это вдруг стало нужно, не все так быстро разрабатывали внутри себя технологическую экспертизу.

То есть дело не в том, что тема сама по себе невозможна для реализации, а в том, что просто кто-то ещё последовательно до неё не дошёл?

Т: Да, всё так.

А: Я добавлю, что есть некоторые компании, стартапы, где два человека, допустим, сидят, и им пока не нужен CI/CD. Может быть, они о нём знают, но пока без него обходятся. И внедрение это должно быть на каком-то этапе, когда проект вырос до точки, где это необходимо. Тогда это принесёт больше плюсов, чем минусов. Когда есть только один талантливый программист, ему намного быстрее будет разрабатывать без CI/CD. Ну, и да, отсталость некоторых проектов. Я сам работаю с клиентами, и у них есть сайты с большой посещаемостью, куда они заходят и в середине рабочего дня вешают заглушку и начинают править код. Прямо на продакшене.

Какие это проекты?

А: Да просто интернет-магазины. Небольшие, естественно. В больших очень критичны простои. Там используют серьёзные технологии. А небольшие может, не слышали, может, им это неинтересно. Мы иногда рассказываем, что и как можно настроить, но без особого энтузиазма воспринимают. Мол, старое работает, и ладно.

До вопроса внедрения мы ещё дойдём. Расскажите о своём опыте построения CI/CD, что это были за проекты?

Т: Я около двух лет назад пришёл в X5 Retail Group как, на тот момент, единственный сотрудник нового подразделения, и на мне висела задача построить платформу для разработки, чтобы разработчикам дирекции больших данных было, где собирать свой код и где его запускать. Там достаточно много разных проектов. Какие-то более будничные: прогнозирование оптимальных цен, оптимальных промо-акций (вроде скучное, но приносит прибыль). И что-то более хайповое, вплоть до проектов по компьютерному зрению.

Технологии были разные. В основном для бэкендеров это Java, для фронтендеров это React. Ну, и для дата-сайентистов Python (Anaconda, Jupyter Notebook и тому подобное). Я должен был создать для них эту самую платформу разработки. То есть, CI/CD-серверы (у нас был GitLab), Kubernetes заставить всё это работать в связке и помочь продуктовым командам начать этим эффективно пользоваться.

Два года назад это началось и? Процесс завершился?

Т: На сегодняшний день я уже в X5 не работаю, но там ребята уже активно развились, очень хорошо освоились. Естественно, дирекция больших данных сейчас и то, что было два года назад это совершенно разные вещи. По количеству рост сотрудников, наверное, раз в 5-6. Ну, это была очень молодая дирекция на тот момент. Она очень быстро росла. И по компетенции, по парку серверов на этой рантайм платформе, по всему прочему рост был на порядки.

И люди тоже очень сильно компетенций набрались. Как я говорил, тогда я был единственным сотрудником отдела, а сейчас там примерно 10 человек. И были какие-то измеряемые успехи. Я воспроизводил исследование Ускоряйся, которое лежит в основе методики ежегодных отчётов State of DevOps, и по результатам этого исследования в масштабах одной только дирекции успехи были.

Александр, какой у вас опыт?

А: У меня опыт построения CI/CD первый был на третьем или на четвёртом потоке Слёрма, где я участвовал в качестве студента. Ведь Слёрм изначально задумывался как средство обучения сотрудников Southbridge, а я работал в Southbridge и как раз на одном из потоков плотно познакомился с CI/CD. До этого у нас было несколько клиентов с не совсем правильными подходами к CI/CD, а на обучении я увидел такой конкретный, цельный пример, и потом он мне очень пригодился.

У нас пришел клиент, ему нужно было мигрировать из Docker Swarm в Kubernetes некий стек и плюс распилить монолит. Там были уже несколько контейнеризованных микросервисов и плюс был монолит, который разработчики пилили и добавляли микросервисы, и вот это все мы заворачивали в Kubernetes. Поэтому туда я взял пример нашего CI/CD из Слёрма. Он простенький, но вполне себе рабочий. И в итоге мы дошли до того, что последние микросервисы разработчики деплоили уже сами, без нашего участия. Мы всё построили и отладили, а дальше они уже сами всё по шаблонам делали.

Если по этапам описать проделанную вами работу, в чем она заключалась? Как вы дошли от нулевой точки до момента, когда команда уже сама могла что-то делать?

А: Сначала мы адаптировали практически вручную то, что уже было в Docker Swarm микросервисы. Потребовался небольшой допил конфигурации. Плюс, helm-чарты написали первые. Использовался Kubernetes. Helm 2 на тот момент ещё был популярен. Ну и GitLab CI. После этого разработчики задавали множество вопросов, иногда делали не так, как мы задумывали. Мы поправляли их. У нас не было прямо тесной связи, мы иногда приходили и советовали, где как лучше сделать, чтобы работало. Таким путем проб и ошибок пришли к тому, что они теперь без нас отлично справляются.

До этого вы упомянули неправильные подходы. Что это было?

А: В целом неправильный подход для мелких проектов, наверное, оправдан. Потому что там не было CI-инструмента. У нас в курсе будут описаны некоторые уже устоявшиеся инструменты (online, self-hosted-решения). А там было проще некуда: задание по расписанию, git pull из репозитория с кодом. Буквально каждые две минуты он делает git pull. И когда разработчик в нужную ветку пушит изменения, он понимает, что это попадёт на продакшн. Т.е. через вот этот промежуток времени 1-2 минуты скрипт сработал, и всё попало на продакшн. Разработчику не нужно было самому ходить. Это такой небольшой пример CI/CD. Естественно, о тестах говорить не приходилось, всё было на совести разработчика.

Какие проблемы могут возникнуть при таком подходе? Ошибки?

А: Да, плюс откат. Если мы из этой ветки пушим постоянно, то чтобы откатиться, нужно будет в ту же ветку запушить уже более поздним коммитом нужную версию, уже исправленную. А не вернуться к предыдущему коммиту или предыдущему релизу/тегу.

Т: Тут еще, понимаете, это очень здорово работает, пока там действительно стартап из двух человек. И один только финансами занимается, а кодит только второй. Зачем ему тогда сильно следить за качеством своего кода? Зачем ему выстроенный CI/CD процесс? Он и так отлично знает, что у него где лежит. Проблемы начинаются, когда такую модель работы переносят на командную разработку, и там есть 2-3-4 сеньора, которые всё отлично знают, но никто не может начать с ними работать, потому что они не столь ответственно относились к качеству кода, не запускали тесты. Вроде и так всё понятно, но всегда тяжело учесть, что придёт человек со стороны а в больших компаниях это постоянно случается которому будет сложно объяснить, что тут вообще происходит. Цель CI/CD не просто автоматизировано допихать код до продакшена, но и следить за его качеством.

Мне кажется, это даже не основная цель пайплайна собрать какой-то артефакт, Docker-образ и задеплоить. В любом случае, пайплайн должен уметь делать это безупречно. Потому что это такая типовая задача, которую мы должны легко делать каждый день с нашим кодом. Но вообще, в процессе разработки продукта полезно иметь здоровый профессиональный конфликт. Это конфликт между разработчиками и инженерами по обеспечению качества. И пайплайн тоже должен стоять на страже качества кода. Чтобы тыкать разработчика носом и говорить: Так, вот тут у тебя код не по стандартам отформатирован. Вот тут линтер ругается, тут юнит-тесты не проходят. Давай откатывай и переделывай.

Если пайплайн просто собирает как-нибудь код и потом деплоит его, мы не знаем, что, собственно, задеплоили. Нормально или фигня. Может, там десять релизов уже, и каждый всё больше ломал наш код.

А как построить такую систему? Нужно, чтобы разработчики договорились о стандартах: мы все согласны, что вот так делаем, а вот так не делаем?

Т: Да, нужно прийти к соглашению, что мы считаем плохим/хорошим, как мы будем делать. Но в целом, это спор ни о чем. Не так важно, до чего вы договоритесь у вас будут табы или пробелы. Это все второстепенно. Выберите уже что-нибудь. Это лучше, чем ничего. В этом плане Golang такой интересный пример. Он не стал давать разработчикам волю самим выбирать, какое будет соглашение о качестве. Он просто сказал: Ок, у нас отступы табами, табы шириной 8 символов. И всё, не колышет. Это встроено прямо в утилиты самого Golang. Есть такое высказывание: Все его ненавидят, но при этом он самый лучший. Потому что хоть какой-то стандарт есть. Встроить проверку соответствия кода выбранным стандартам в пайплайн это буквально две строчки.

Как обеспечить контроль выполнения стандартов?

Т: Мне не приходит на ум ни один язык, где нельзя какие-то юнит-тесты сделать. Как правило, они делаются обычно чуть ли не средствами самого компилятора. Это одна строчка. Если нет юнит-тестов, когда первый будет написан, он автоматически будет выполняться. Потом, если это компилируемый код, тогда сам факт, что компиляция прошла успешно, тоже о чём-то да говорит.

Значит, есть несколько таких ступенек?

Т: Да. Всегда принцип 20/80. 20% усилий дают 80% успеха.

А: Тут упомянули проверку кода. Это достаточно важно, и многие инструменты содержат в своём названии как раз CI. Travis CI, GitLab CI. И это очень важно проверить и программиста носом натыкать, это экономия труда тестировщиков. Может, потом код скомпилируется, запустится, даже будет первое время выглядеть нормально, но потом тестировщик найдёт ошибку. А если это сделает автоматика, это намного быстрее и экономия труда, половины рабочего дня тестировщика.

Вы сказали программиста носом натыкать. Это тот самый конфликт между разработкой и QA, о котором говорил Тимофей?

А: Могу привести свой пример, поскольку работаю с CI/CD каждый день, но не с кодом, а с конфигурациями. У нас есть линтеры лишний пробел поставил, он уже ругается. Иногда злишься, ведь это просто формальность, ни на что не повлияет, но это приучает к качеству. И стандарты эти нужны для обеспечения командной работы в том числе. Чтобы новый человек пришел и быстро разобрался.

Получается, весь процесс настройки CI/CD как бы против программиста. Разработчик раньше был этаким свободным художником, а теперь приходит DevOps-инженер и говорит ему, как работать.

А: Можно провести аналогию с конвейером. Если норма у рабочего на конвейере пять деталек в час, а он такой стахановец и делает десять. Это уже может быть непредсказуемость, если мы всегда будем считать, что он делает десять, хотя норма пять. Поэтому лучше пусть стабильно делает пять, но качественно. Можно фигачить код без стандартов, он будет работать, но новый человек не въедет быстро. Поэтому в командной работе есть ограничения, чтобы ото всех можно было получить одинаково стабильную работу. А не так, что один вкалывает, а другой сидит.

Т: А если сеньор проверяет код джуна и говорит: Слушай, а тут вот у тебя функция может вернуть исключение, а ты его не проверяешь. Это сеньор тогда против джуна? А что меняется, если то же самое делает автоматика? Что сеньор, что автоматика они против плохого кода, а не против разработчика.

Давайте мы теперь чуть отступим и поговорим про внедрение CI/CD. Как компании и команды приходят к тому, что пора что-то менять? Ошибки слишком частые, порядка нет, что-то ещё?

Т: Это очень по-разному случается. Вот мой опыт в X5 был такой, что была полная поддержка со стороны менеджмента, но при этом есть менеджмент всей дирекции, а есть отдельные продуктовые команды, у которых некое двоевластие. С одной стороны, есть руководитель отдела разработки, который, наверное, ратует за поставку качественного кода, но, с другой стороны, это продуктовая команда, у них есть дедлайны для поставки фич, и не всегда ясно, что поставить в приоритет. Конечно, нет откровенно глупых людей, которые говорят, что весь этот ваш DevOps не важен, нам нужно фичи пилить. Но при этом в разговорах проскакивает моментами. Мол, ну, я не знаю, у меня сейчас есть бюджет на одну ставку, и для меня вывод очевиден, кого я возьму DevOps или ещё одного разработчика. Мне нужно разрабатывать, так что я возьму разработчика.

Как сделать хорошую мину при плохой игре? Поскольку у нас есть такой инфраструктурный отдел, который ещё в какой-то степени DevOps-евангелисты, то есть отдел, которым я руководил в X5, лучшее, что можно сделать, это облегчить командам внедрение этих пайплайнов, этого CI/CD. Обучать людей до тех пор, пока это возможно, но лучше всего что-то сделать за них. Зашаблонизировать типовые действия. Например, даже банально собрать докер-образ и запушить его в репозиторий. Это нужно авторизоваться в docker registry. Рассчитать, с каким тегом мы соберем докер-образ. Это docker build, потом пуш несколько раз. Возможно, если мы хотим кэши, то нужно сначала скачать старый образ, который уже был, использовать его как кэш, потом закачать новый. Это куча рутины, которая может растянуться строчек на пятнадцать, но это всё однотипно.

Если инфраструктурная команда понимает немного в DevOps, она осознаёт, что это её задача. Сделайте Developer Experience получше. Зашаблонизируйте это, чтобы умещалось в три строчки, а не в пятнадцать. Тогда разработчики будут мыслить не категориями: надо спулить образ, собрать, туда-сюда. А категориями: а вот здесь Docker. Просто один блок, модульный такой. И им будет легче. Они тогда смогут абстрагироваться от деталей и больше заниматься своей непосредственной работой. А именно писать код. В этом плане DevOps он в том, чтобы фасилитировать, предоставлять разработчикам возможность лучше делать свою работу.
И таким образом снижать сопротивление.

А: Отвечу на тот же вопрос со своей стороны. У меня пример внедрения не из мира разработки, больше из мира администрирования. У нас в один прекрасный момент сказали: Мы вот подошли к тому, что откладывать нельзя. Базис мы подготовили для вас. Теперь все новые проекты вы будете создавать вместо старого пути по CI/CD. Вот у вас есть шаблончик, создаете в GitLab и работаете с ним. Каждая команда будет вольна его улучшать. Так и внедряли. Достаточно императивно. В некоторых проектах, когда этот путь нёс больше вреда, чем пользы, мы откатывались на старую версию, но сейчас половина проектов работают через CI/CD. Мы управляем конфигурациями серверов через GitLab CI. Точно так же, как у разработчиков, там есть проверки, линтеры.

Раз уж заговорили про администрирование, поговорим про GitOps. Что это такое, и какое значение имеет: это всё-таки хайп или полезность?

А: Мало что могу сказать про GitOps. Мое мнение такое, что это достаточно хайповое слово. В последнее время я много его слышу. Три года назад так хайповали на DevOps, так что GitOps для меня одно из слов, примазавшихся к DevOps. Для меня это больше хайп.

Это вообще о том, что вся правда хранится в Git. Там и управление конфигурациями серверов, Infrastructure-as-Code, и код проекта, который потом на эти сервера поедет, и описание процесса, как мы с исходного кода получаем приложение на серверах. Так это я понимаю. Возможно, Тимофей меня дополнит, исправит.

Т: GitOps, мне кажется, чуть более честное словечко, чем все эти DevOps, DevSecOps и так далее. Потому что оно значит почти буквально то, что и говорит. Это именно ведение своих действий по эксплуатации своего софта, своей инфраструктуры через Git. Вся правда хранится в Git.

Что это на практике значит? Вроде как мы запушили какой-то код в наш репозиторий, автоматически запустился пайплайн. Что-то произошло, допустим, какие-то манифесты отправились в Kubernetes. И вот у нас то, что мы запушили в Git, это теперь то, что находится в Kubernetes. В принципе, это тоже GitOps, хотя не всегда его так называют. В частности, это так называемая push-модель, когда мы информацию из репозитория толкаем на продакшн.

Еще бывает так называемая pull-модель. Когда, если речь идет о Kubernetes, то у нас там какой-то агент стоит, который мониторит изменения в репозиториях, и если видит, что там что-то закомитили, что-то изменилось, то он стягивает эти изменения. Он умеет и Helm, и Kustomize делать, и просто манифесты ямликами подтягивать. И опять же отправляет их в Kubernetes.

Некоторые пропоненты GitOps вовсе закрывают любое редактирование в Kubernetes и позволяют изменять состояние кластера, только подтягивая изменения из Git. Если этого не делать, всегда есть риск, что из-за чьих-то ручных действий состояние кластера и то, что описано в репозитории разъедется. Кто-то там ручками что-то поменял, а в Git ничего не поменялось. Поэтому частенько говорят про GitOps именно в контексте pull-модели, когда, ну, поменял ты что-то в Kubernetes, ничего страшного, потому что автоматика в ближайшие полчаса все равно вернет все, как описано в Git.

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

К примеру, смежный отдел, который управлял Data Lake в X5, быстро пришёл к тому, что у них вся конфигурация из двух сотен машин управлялась через Ansible, а он запускался каждые 30 минут, как пайплайн в GitLab. Это пример более-менее правильного применения GitOps.

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

Александр, когда вы говорили о том, как строите процесс работы с клиентами в Southbridge, вы упоминали что-то похожее на GitOps. Настройка конфигурации через описание в Git, это не то же самое?

А: В идеальном мире да. Но у софта зачастую очень много настроек. И чтобы в каждой ручечку/переключатель/ползунок поменять, роль управления конфигурацией должна быть очень развесистая, раскидистая. Либо шаблонизированная. Иногда бывает, что настройки просто нет, и мы идем вручную поправляем. Разработка не успевает за эксплуатацией. Потому что иногда задачи бывают критичные. А чтобы всё разработать, у нас просто нет времени. Но в идеальном случае мы делаем именно то, что описал Тимофей.

Тимофей, а подход GitOps учитывает это обстоятельство неидеального мира?

Т: Это тяжело, конечно. Потому что нам надо бизнес делать, бабки зарабатывать. Казалось бы, вот она, ручка, сходи и поменяй, надо же. Есть потребность, а тут какой-то скрипт ещё писать, дорабатывать helm-чарты. Поэтому да, есть соблазн всё быстренько сделать руками.
Чтобы и бизнес-потребности учесть и себе codebase не испортить, можно хотя бы завести тикет, что вот тут вручную настраиваемое значение, но это баг. Мы положим тикет в бэклог, потом обязательно вернемся и допилим тут автоматизацию. Главное не потерять места, где мы руками настраивали.

В чём ключевые преимущества подхода GitOps?

Т: Основное мы достоверно знаем, что у нас запущено в продакшене. Что все четко описано в репозитории, и не возникает сомнений, что кто-то руками поменял.

А: Когда большая команда, это очень важно, что все могут в любой момент посмотреть и увидеть, какая сейчас конфигурация работает на нужном сервере. Потому что если там 1-2 человека, они могут всегда договориться, а когда 15 человек, GitOps сильно экономит время. Не надо ходить, опрашивать, выяснять, откуда ноги растут у несоответствий.

Чем GitOps отличается от подхода Infrastructure-as-Code?

А: Это не только инфраструктура, но еще и приложение, как код. Они хранятся в единой точке. Может, в разных репозиториях, но в одном инстансе GitLab. Можно легко посмотреть состояние инфраструктуры и приложения. Плюс, в идеальном мире может быть вообще связана инфраструктура с кодом. Мы создали новый репозиторий, настроили с нуля хитрый пайплайн, запушили код и он сам пошёл, создал себе инфраструктуру где-нибудь в облаке и задеплоил туда приложение, которое мы туда написали. Это идеальный, конечно, случай, но думаю, где-то это работает. Например, в больших компаниях.

Т: Да, там предлагают даже держать отдельно несколько репозиториев. Один это просто сам код приложения, в котором собирается образ или бинарник. Второй репозиторий туда генерируются, допустим, манифесты для Kubernetes. Третий это такой большой репозиторий, который нам рассказывает, что в нашем кластере манифест из этого репозитория за таким-то тегом, из этого такой-то версии. Он уже просто по номерам версий описывает, что вообще в нашем кластере запущено. На это иногда даже автоматику натягивают: изменили приложение, только код, повесили на него новый тег, а там потом автоматически новый манифест запушился в репозиторий с манифестами, и нужная строчка с нужной версией изменилась в том месте репозитория, которое описывает общее состояние кластера.

Это такая идеальная система?

Т: Ну, да.

CI/CD это такая штука, которую один раз настроил и забыл, или это процесс, который нужно поддерживать?

Т: И да, и нет. Когда он только внедряется, не бывает сразу идеально. Когда в X5 я внедрял, то начальник отдела разработки спрашивал у разработчиков, сколько времени в неделю они тратят на обслуживание их CI/CD. Кто-то отвечал: А что там обслуживать? Вот мы настроили и забыли. И какое-то время это работает. Если сделать сходу правильно, можно сделать очень модульные блоки. И потом не сильно трогать нижележащий код, который это делает, а просто появился новый проектик/микросервис, подключили к нему типовые модульные блоки и поехали дальше. Но пока все учатся, что-то допиливается. Приходится на первых порах долго и мучительно внедрять новые хорошие практики в трудно обслуживаемый код. Дальше уже полегче.

А в больших компаниях как обычно происходит? Приходит DevOps, помогает всё это настроить и остается в команде, или разработчики перенимают на себя его функции, а DevOps уходит в другую команду? Или есть отдел DevOps?

Т: Все очень по-разному. У меня в X5 были продуктовые команды очень разных способностей. Какие-то хорошо въезжали в процесс, и редко надо было им помогать. Были более слабые. К ним привязывали инженера, который помогал писать пайплайны. Работал, в некоторой степени, приходящим релиз-инженером в их команде. Но в X5 порядка 9-10 DevOps обслуживали потребности где-то 200 техспециалистов.

Сейчас я работаю в Тинькофф, тоже в платформенной команде, но там масштабы немного другие. Нас 8 человек, а разработчиков тысячи полторы. И невозможно предоставлять каждой команде DevOps как сервис. Поэтому там предполагается, что команда сама добывает эту экспертизу или нанимает себе DevOps. Либо сами разработчики этому обучаются.

А: Моя версия такая, что да, вначале идет активная разработка. Мы программируем пайплайн, что за чем будет идти, потом ситуация может устаканиться. Если в архитектуре проекта нет глобальных изменений, всё может работать год без правок. Но в мире все меняется. Микросервисы могут быть переписаны за две недели. И если их переписали на другом языке программирования, то тесты выкидываем и пишем новые. Поэтому CI/CD тоже требует обслуживания.

Ну и добавлю, что у разработчиков разная компетенция. Кому-то постоянно нужна помощь, а кому-то нет. Вот у нас был пример с одним из клиентов. Мы им настроили базовые CI/CD, всё показали. Через какое-то время они к нам приходят и говорят: А мы вот переписали всё по-своему. Мы только и ответили: Ух ты, молодцы. Они просто взяли все в свои руки.

TL;DR: GitOps применяет те же способы для развертывания инфраструктуры, какими пользуются DevOps и CI/CD для развертывания приложений.

За последние десять лет разработка приложений увидела много революционных изменений. Часть их возникла из методов кластеризации вокруг DevOps-подхода и CI/CD. Еще часть таких изменений пришла из движения от монолитной кодовой базы к основанным на облачных технологиях микросервисам, которые запускаются в контейнерах и управляются платформами оркестровки, например Kubernetes.

Основанные на контейнерах приложения запускаются в кластеризированных системах или в облаках, могут быть сложными по структуре и трудными для раскатки и управления даже с использованием оркестраторов. GitOps появился в виде набора методов, цель которых упрощение этой управленческой задачи с использованием подходов, похожих на методы DevOps и CI/CD.

Ключевой идеей GitOps является инфраструктура-как-код, имеющая такой же смысл для создания инфраструктуры, как DevOps для раскатки приложений. Таким образом, не только приложения, но и нижележащие сервера и сети описываются в файлах, которые обрабатываются, как и любой другой код, лежащий в системе контроля версий, с помощью автоматических процессов, совмещающих реальный мир с тем, что написано в этих файлах.

Говоря в терминах GitOps код в системе контроля версий единый истинный источник того, как приложение будет работать в производственном окружении.

Определение GitOps

Компания Weaveworks сделала больше всех для популяризации идеи GitOps. Мы немного погрузимся в роль Weaveworks, и для начала посмотрим на определение GitOps от этой компании, состоящее из двух моментов:

• Эксплуатационная модель Kubernetes и прочих облачных технологий предоставляет набор передовых методов, соединяющих развертывание, управление и мониторинг контейнеризированных кластеров и приложений.
• Устоявшийся способ управления приложениями для разработчика, где сквозные конвейеры CI/CD и рабочие процессы Git применяются как для разработки, так и для эксплуатации.

Другими словами, GitOps особый набор методов, разработанный для управления Kubernetes и прочими сходными платформами, который предполагается использовать шире, поскольку все больше и больше компаний-разработчиков принимают DevOps и переносят код в облака. Но чтобы понять секреты GitOps и проблемы, решаемые им, нам нужно обсудить входящие в него компоненты.

Определение Git

Git в GitOps это широко известная распределенная система контроля версий, разработанная Линусом Торвальдсом в 2005 году. Git инструмент, позволяющий командам разработчиков работать совместно над кодовой базой приложения, сохраняя различные ветки кода, над которыми они работают, прежде чем слить их вместе в готовый к промышленному использованию код. Одним из ключевых моментов Git является запрос на слияние, в котором разработчик формально просит добавить код, над которым он работал, в другую ветку кодовой базы. Запрос на слияние в Git дает возможность совместной работы и обсуждения для членов команды. Члены команды должны достичь соглашения по новому коду, который будет добавлен в приложение. Git также сохраняет старые версии кода, что делает возможным легкий откат к последней рабочей версии, если вдруг что-то пойдет не так. Кроме того, можно легко посмотреть различия между версиями. Git также известен как основа GitHub, облачной системы контроля версий, но сам Git программа с открытым исходным кодом, которую можно установить везде, начиная с внутренних серверов компании и заканчивая вашей рабочей машиной.

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

Еще одну вещь стоит упомянуть: несмотря на наличии слова "Git" в имени, GitOps в принципе не требует использования Git. Компании, использующие другие системы контроля версий, например Subversion, могут также реализовать GitOps. Но сам Git широко используется в области DevOps для реализации CI/CD, так что большинство проектов GitOps все-таки используют именно Git.

Что такое процесс CI/CD

Полностью описывать CI/CD в этой статье мы не будем, об этом можно почитать например здесь, но нужно сказать пару слов про CI/CD, поскольку это основа работы GitOps. Непрерывная интеграция, первая часть CI/CD, работает с системой контроля версий, например Git: разработчики могут постоянно делать небольшие улучшения их кодовой базы, вместо выкатывания больших монолитных новых версий каждые несколько месяцев или лет. Вторая часть, непрерывная поставка, основана на автоматических системах, т.н. конвейерах, собирающих, тестирующих и выкатывающих новый код для промышленного использования.

Опять же, мы здесь говорим о коде, который все привыкли видеть как код программ, написанный на некотором языке программирования, например C, или Java. Но в GitOps под кодом мы по большей части подразумеваем файлы настроек. Это не просто мелкое примечание это то, на чем основана работа GitOps. Эти файлы, как мы уже говорили, являются единым истинным источником, описывающим, как наша система должна выглядеть. Они по большей части декларативные, а не инструктивные. Это значит, что вместо того, чтобы сказать "запусти десять серверов в файле с настройками, мы просто говорим в системе должно быть десять серверов.

С помощью CI в трактовке GitOps разработчики могут быстро добавить настройки и улучшения в этих файлах, CD начинается там, где автоматизированные программы-агенты делают все необходимое, чтобы реальная версия приложения соответствовала описанию в файлах настройки сходилась с декларативной моделью, если говорить в терминах GitOps.

GitOps и Kubernetes

Как мы уже писали выше, идеи GitOps были сначала обкатаны на приложениях, управляемых Kubernetes. Давайте теперь с тем, что мы знаем о GitOps, вернемся обратно к обсуждению GitOps от Weaveworks, и посмотрим, как они описывают принципы управления обновлениями для Kubernetes, применяемые в GitOps. Кратко процесс работы:

1. Разработчик делает запрос на слияние с новой функцией;
2. Код проверяется и одобряется, сливается с кодовой базой;
3. Слияние активирует конвейер CI/CD, автоматически собирающий, тестирующий и выкатывающий код в registry;
4. Программный агент получает уведомление об обновлении, скачивает новый код из registry и обновляет файл настроек (написанный на YAML) в репозитории настроек;
5. Программный агент в кластере Kubernetes определяет, основываясь на файле настроек, что его настройки устарели, скачивает изменения и выкатывает новую функцию.

Weaveworks и GitOps

Очевидно, что шаги 4 и 5 делают большую часть тяжелой работы, ведь программные агенты, волшебным образом синхронизирующие единый истинный источник в репозитории Git с реальным приложением в Kubernetes, делают возможным GitOps. Как мы уже писали, процесс превращения живых систем в те, что описаны в файлах настроек, в терминах GitOps называется схождением. (А когда не синхронизированы расхождением). В идеальном случае схождение может быть достигнуто с помощью автоматизированных процессов, но есть несколько пределов автоматизации. Так что местами потребуется вмешательство человека.

Мы описываем процесс общими словами, но по факту, если вы посмотрите страничку Weaveworks, программные агенты, о которых мы писали, это часть корпоративной платформы Weave Cloud. Термин GitOps придумал генеральный директор Weaveworks, Alexis Richardson, этот термин нужен для того, чтобы привлечь внимание разработчиков, знакомых с DevOps и CI/CD, к платформе Weaveworks.

При этом Weaveworks никогда не заявляла прав на монопольное использование термина GitOps, потому что он больше философия и набор передовых практик, чем некий определенный продукт. В блоге CloudBees, компании, предоставляющей решения CI/CD, есть заметка о том, что GitOps представляет собой открытую, независимую от поставщика модель, разработанную в качестве ответа на управляемые собственнические решения на основе Kubernetes, доступные у всех крупных поставщиков, например Amazon, Google и Microsoft. CloudBees предлагают свое собственное решение GitOps, как и многие другие поставщики в этой отрасли.

GitOps и DevOps

В блоге компании Atlassian, создавшей несколько инструментов для гибких разработчиков, есть объемная, но стоящая вашего времени, статья, описывающая историю и назначение GitOps. По их мнению, GitOps представляет собой логическое продолжение идей, пришедших вместе с DevOps. Согласно описанию, GitOps это развитие идеи инфраструктуры-как-кода, причем сама идея пришла из мира DevOps. GitOps, по мнению Atlassian, закрывает ключевые дыры между нынешними методами DevOps, которые стали решением проблем системного администрирования, и отдельными нуждами распределенных приложений, размещенных в облаках. Автоматическое схождение, предлагаемое разными облачными поставщиками, делает GitOps особенным.

Пока GitOps остается нацеленным на Kubernetes, мы надеемся, что вам стало ясно, как его применять в более широком мире распределенных облачных приложений. Эта статья от поставщика безопасности с открытым исходным кодом выделяет следующие преимущества GitOps:

• Наблюдаемость: системы GitOps предлагают мониторинг, журналирование, слежение и визуализацию сложных приложений, так что разработчики могут видеть, что и где сломалось;
• Управление версиями и изменениями: это, очевидно, ключевое преимущество от использования систем контроля версий, например Git. Кривые обновления можно легко откатить;
• Легкое внедрение: GitOps основан на навыках DevOps, уже имеющихся у большинства разработчиков;
• Продуктивность: GitOps предлагает увеличение продуктивности, аналогичное получаемому от внедрения DevOps и CI/CD;
• Проверки: благодаря Git все действия можно отследить до отдельного коммита, делая легким отслеживание исходных причин проблем.

Даже если вы и не используете Kubernetes, есть хорошие шансы на то, что GitOps станет частью вашего рабочего процесса рано или поздно.

От редакции: Практику применения GitOps можно получить на курсе Слёрма CI/CD на примере Gitlab CI. До 3 декабря 2020 курс доступен по цене предзаказа, а также можно стать консультантом-тестером и повлиять на итоговый контент курса.

Компания Neocortix, специализирующаяся на распределенных вычислениях, анонсировала завершение портирования Folding@Home и Rosetta@Home на 64-битную платформу Arm, тем самым позволяя современным смартфонам, планшетам и встраиваемым системам типа Raspberry Pi 4, вносить свой вклад в исследование и разработку вакцины от COVID-19.





Четыре месяца назад Neocortix анонсировала запуск порта Rosetta@Home, позволив устройствам Arm участвовать в исследовании свертки белков, направленном на поиск вакцины для COVID-19. В тот момент компания сообщила, что ведутся работы над портированием на Arm Folding@Home другого проекта распределенных вычислений, нацеленного на достижение той же цели.

Теперь Neocortix сообщила об успехе по обоим фронтам. Мы портировали Folding@Home и Rosetta@Home для устройств, основанных на Arm, чтобы позволить миллиардам высокопроизводительных мобильных устройств работать над поиском вакцины от COVID-19, объясняет Ллойд Уоттс, основатель и генеральный директор Neocortix, Мы увидели возможность использования нашей платформы Neocortix Cloud Services для помощи наиболее востребованным научным проектам в их нужде в вычислительных ресурсах, и сделали это в большом масштабе.



Мы движемся в будущее с триллионом соединенных между собой устройств, и инновация заключается в том, что этим подходом решается одна из сложнейших задач связывания множества устройств из разных точек мира в единое облако, добавляет Пол Уильямсон, вице-президент и управляющий по связям с бизнес клиентами Arm, Сотрудничество Arm с Neocortix означает, что технологии Arm теперь могут дать свой вклад в критически важные исследования COVID-19 и это потрясающе видеть, как глобальная экосистема Arm разработчиков объединяется, чтобы совместно поддержать эти усилия.

Мы наблюдаем растущую вычислительную мощность телефонов и других мобильных устройств в последние годы, соглашается Грег Боуман, директор проекта Folding@Home, Это сотрудничество между Neocortix и Arm предоставило нам идеальную возможность использовать мобильные ресурсы для ускорения наших исследований по COVID-19.

Folding@Home и Rosetta@Home уже работают на платформе распределенных вычислений Neocortix Scalable Compute и передают результаты обратно в научные проекты. С дополнительными техническими деталями можно ознакомиться в Коронаблоге Neocortix.

Полезные ссылки на живые мероприятия, видео, митапы, техтолки и книги ниже в нашем еженедельном посте.

Начни новое:

• Установка Red Hat Advanced Cluster Management (ACM) for Kubernetes
  
  Как настроить Red Hat OpenShift 4 для установки Red Hat Advanced Cluster Management (ACM) for Kubernetes и затем провести такую установку.
• Новые возможности Red Hat CodeReady Studio 12.16.0.GA и JBoss Tools 4.16.0.Final for Eclipse 2020-06
  
  Что нового в JBoss Tools 4.16.0 и Red Hat CodeReady Studio 12.16 for Eclipse 4.16 (2020-06), от улучшенного UI до обновленных расширений JDT.
• Кастомная установка Open Data Hub и Kubeflow
  
  
  
  
  Три варианта: правка манифеста в форке, создание репозитория с переопределениями (overrides) и добавление оверлеев (overlays).
• Балансировка нагрузки в подкластерах Red Hat JBoss Enterprise Application Platform с помощью mod_cluster
  
  Создание, управление и балансировка нагрузки в кластерных средах с помощью подкластеров с модулем Apache HTTP Server mod_cluster и JBoss EAP.
• Лучшие практики edge-разработки
  
  Периферийные вычисления все чаще применяются в реальной жизни и пора учиться правильно создавать для них приложения.
• Что нового в developer-режиме консоли OpenShift 4.5
• OpenShift 4.5: улучшенная навигация для разработчика
• Защита приложений Vue.js с помощью Keycloak | Семинар DevNation Tech Talk
• Шпаргалка: MicroProfile Health
  
  
  
  
  
• Бесплатная электронная книга Kubernetes Patterns: повторно используемые элементы при конструировании облачно-ориентированных приложений
  
  
  
  
  

Качай:

• Скачай и установи OpenShift Container Platform 4
  
  Все, что нужно для управления жизненным циклом разработки, включая стандартизированные рабочие процессы, поддержку мультисред, непрерывную интеграцию и управление релизами.

Почитать на досуге:

• Как алгоритмы муравьев помогли транспортным автопаркам вдвое сократить выбросы в атмосферу
• Ускоряем сборку контейнеров с помощью overlay mount-ов
• Red Hat Enterprise Linux 8.3 beta уже здесь: высочайшая стабильность и ИТ-инновации для корпоративных заказчиков
• 3 причины использовать Kubernetes-платформу корпоративного класса
• Создаем сайт с документацией с помощью Docsify и GitHub Pages

Пообщаться:

• 6 августа, семинар DevNation Tech Talk Serverless Workflow: новый подход к оркестрации Kubernetes-сервисов
  
  Как улучшить serverless-архитектуры с помощью Serverless Workflow от Cloud Native Computing Foundation (CNCF) и инструмента бизнес-автоматизации Kogito от Red Hat.
• 10 августа, мастер-курс DevNation Kubernetes для начинающих
  
  Как развернуть, адаптировать и применять Kubernetes в контексте своих облачных требований.

Полезные ссылки на живые мероприятия, видео, митапы, техтолки и книги ниже в нашем еженедельном посте.

Начни новое:

• Представляем Red Hat Flatpak: контейнеры для чисто десктопных приложений
  Как использовать Flatpak runtime для сборки контейнеризованных десктопных приложений поверх Red Hat Enterprise Linux 8.2.
• Kubernetes и гибридное облако с использованием Skupper (видеоурок DevNation Tech Talk)
  Развертываем облачно-ориентированные микросервисы Java на Amazon Web Services, Google Cloud Platform и Microsoft Azure с помощью Skupper.
  
  
  
• Cloud-native CI/CD с использованием Tekton (KubeCon Europe 2020)
  Концепции и преимущества Tekton, а также практика работы с этой системой (видео с конференции KubeCon).
• Безопасная проверка подлинности с использованием Red Hat AMQ 7.7 и ApacheDS LDAP Server
  Интегрируем Red Hat AMQ 7.7 с Apache Directory Studio (это LDAP-браузер и клиент службы каталогов для ApacheDS).
• Open Data Hub 0.7 теперь поддерживает Kubeflow 1.0
  Новое в Open Data Hub 0.7, включая поддержку Kubeflow 1.0 и улучшенное тестирование компонентов для непрерывной интеграции OpenShift.

Качай:

• Шпаргалка по языку программирования C
  C это классика компилируемых языков программирования, концептуальный предок Lua, C++, Java, Go и многих других современных языков, ну и просто отличный выбор, чтобы начать учиться программированию. Эта шпаргалка содержит полезную выжимку по синтаксису C.

Строй:

• Мониторинг приложений .NET Core на Kubernetes
  Как использовать Prometheus для мониторинга приложений .NET Core, работающих на платформе Kubernetes, и как выполнять запросы и генерировать метрики с помощью PromQL.
  
  
  
• Louketo Proxy: проверка подлинности для микросервисов на различных языках программирования
  Как использовать Louketo Proxy в качестве sidecar-а, чтобы организовать проверку подлинности микросервисов, написанных на различных языках программирования.
• HTTP-сообщения Kafka в Red Hat AMQ Streams
  Как производить и потреблять системные логи с использованием AMQ Streams Kafka Bridge (это RESTful-интерфейс для производства и потребления Kafka-топиков с использованием HTTP/1.1).
• Глубокое погружение в Keycloak (видеоурок DevNation Tech Talk,34 минуты)
  Подробный обзор Keycloak опенсорсной системы управления учетными данными и доступом для современных приложений и сервисов.
• Библиотека реактивного программирования Mutiny в Quarkus (видеоурок DevNation Tech Talk, 34 минуты)
  Что такое Mutiny, и как она вместе с Quarkus упрощает разработку реактивных приложений.

Событие сентября присоединяйтесь!

15 сентября состоится DevNation Day абсолютно бесплатная виртуальная конференция по новым компьютерным технологиям и защите компьютерным программ (тм) ну то есть вопросам разработки и технологий. В это году в центре внимания 4 темы: Kubernetes/OpenShift, JavaScript, Python и Java.

Помимо экспертов Red Hat выступят представители Google, MongoDB, Redis, Snyk, Tail, Auth0, Ionic и многих других ведущих компаний. Никуда ехать не надо сидите (или лежите) там, где вам удобно, смотрите-слушайте и общайтесь с докладчиками через онлайновые опросы и чаты.

Пообщаться:

• 27 августа, 2020 Tech Talk @ 19:00 по московскому времени: Hacking the Mesh: Extending Istio with WebAssembly Modules
• 3 сентября, 2020 Tech Talk @ 19:00 по московскому времени: Cloud-Native Modernization or Death? A false dichotomy
• 10 сентября, 2020 Tech Talk @ 19:00 по московскому времени: How I Built a Serverless Blog Search with Java, Quarkus, and AWS Lambda

По-русски:

Мы начинаем серию пятничных вебинаров про нативный опыт использования Red Hat OpenShift Container Platform и Kubernetes. Регистрируйтесь и приходите:

• 28 августа
  Император Оператор: Операторы в OpenShift и Kubernetes
• 11 сентября
  OpenShift-специфичные волшебные вещи для сборки и развертывания приложений
• 25 сентября
  Red Hat OpenShift и Machine API
• 9 октября
  Как справиться с внезапным ростом нагрузки
• 23 октября
  Встроенный Jenkins, Pipeline-builds, Tekton в Red Hat OpenShift Container Platform

enterprisersproject.com

Собрали для вас много новых инсайтов, записей важных вебинаров, книжек и шпаргалок. Прокачивайте скилы, читайте, смотрите, думайте, применяйте на практике! Станьте частью DevNation!

Начни новое:

• 7 способов, которыми Agile и DevOps могут помочь с цифровой трансформацией
  Занимаясь цифровой трансформации, команды часто сталкиваются с конфликтующим задачами. К счастью, у разработчиков ПО есть большой опыт решения проблем в этой области.
  Вкратце: Agile и DevOps помогают снизить риски и ускорить изменения.
• 4 преимущества стандартизованной операционной среды SOE
  Почему принципы SOE (Standard Operating Environment) становятся еще актуальнее в эпоху контейнеров, Kubernetes, CI/CDи автоматизации? Все дело в эффективности и безопасности, и связанных с ними проблемах.
  Вкратце: Гордон Хафф(GordonHaff), техно-евангелист Red Hat и другие эксперты рассуждают о SOE и контейнерах
• 6 советов руководителю, которые помогут защитить сотрудников на удаленке от родительского выгорания
  Это очень даже реальная проблема, и надо постараться помочь сотрудникам, которые имеют детей, оставаться и хорошими работниками, и хорошими родителями.
  Вкратце: Какие меры стоит принять для решения этой долгоиграющей проблемы

Качай:

Подборка бесплатных книг по OpenShift:

• Быстрый старт
• OpenShift для разработчиков
• OpenShift для devops-инженеров
  
  
  
  
  
• Шпаргалка по тестированию приложений Quarkus
  
  
  
  
  
• Бесплатная электронная книга Kubernetes Patterns: повторно используемые элементы при конструировании облачно-ориентированных приложений (осторожно, требуется регистрация)
  
  
  
  
  

Почитать на досуге:

• Основа успешной цифровой трансформации
  Monica Sasso, главный технический специалист Red Hat по работе с финансовыми учреждениями в регионе EMEA, рассказывает в рамках мероприятия EBADay о рецептах успешной цифровой трансформации и о выгодах применения Open Source в банковском секторе.
• Женщины в сфере STEM: Я с нетерпением жду возможности посмотреть, как изменится мир с ростом числа женщин в отрасли высоких технологий
  Jen Albertson, старший руководитель направления Software Engineering компании Red Hat, отвечает на вопросы рубрики Women in Tech для портала Jaxenter.
• Это очень по-человечески хотеть знать, кто совершил киберпреступление
  Это скорее бугристый, чем плоский ландшафт, в плане того, за чем компаниям надо приглядывать, Mike Bursell, главный архитектор безопасности Red Hat. Не столько межсетевые экраны и криптографические ключи, сколько клиентские данные, или сведения о выплатах руководству, или адреса сотрудников.
• Red Hat поддерживает партнеров по мере изменения корпоративного ИТ-ландшафта
  Kevin Bland, директор Red Hat по альянсам и работе с партнерами, говорит, что пандемия подстегнула переход к облачным вычислениям, и все больше организаций думают расширить номенклатуру данных, которые можно выводить за пределы корпоративной сети.

Мероприятия:

• 4 декабря, Создание гибридной облачной инфраструктуры с Red Hat и Microsoft Azure
  На вебинаре эксперты Red Hat и Microsoft расскажут про новые продукты и сервисы Red Hat на Microsoft Azure, благодаря которым можно быстро развернуть надежную и гибкую гибридную облачную среду. На вебинаре детально обсудим, как эффективно интегрировать ресурсы публичного облака в существующую инфраструктуру, а также использовать новые архитектуры приложений, которые расширяют ваши возможности.

Смотри в записи:

• jconf.dev
  Бесплатная виртуальная Java-конференция прямо у вас на экране: четыре техно-трека с нашими комьюнити-экспертами по Java и облаку, 28 углубленных сессий и два потрясающих основных доклада.
• AnsibleFest
  Два дня интереснейших докладов, демонстраций и практических занятий. Отличная возможность узнать, как разработчики, администраторы и ЛПР в сфере ИТ отвечают на вызовы перемен с помощью гибких технологий автоматизации с открытым кодом, которые позволяют перейти от того, что есть, к тому, что нужно.
• J4K Conference
  Новая виртуальная конференция по Kubernetes, Java и облаку: 17 сессий с сотрудниками Red Hat, включая доклад Марка Литтла (Mark Little), главного человека в Red Hat по связующему ПО.
• График предстоящих мероприятия DevNation
  Ознакомьтесь с планом мероприятия DevNation на портале Red Hat Developer, включая все вебинары Tech Talks и мастер-курсы, чтобы заранее спланировать свое расписание и зарегистрироваться на заинтересовавшие вас мероприятия.

По-русски:

• DeploymentConfig vs Deployment
• Император Оператор: Операторы в OpenShift и Kubernetes
• OpenShift-специфичные волшебные вещи для сборки и развертывания приложений
• Red Hat OpenShift и Machine API

Не забудьте отдать свой голос в конкурсе на лучшие OpenShift
настройки веб-консоли с использованием поддерживаемых механизмов OpenShift 4! Присоединяйтесь к нам на openshift.tv и выбирайте победителя!

Компания VMware каждый год в октябреноябре проводит 5-дневную европейскую конференцию VMworld, посвященную виртуализации и всему, что с ней связано. Параллельно для участников конференции проходит конкурс VMware Odissey Hands-On Lab Challenge, на котором ИТ-специалисты со всего мира выполняют лабораторные работы по продуктам и технологиям VMware. В финал выходят несколько участников. Выигрывает тот, кто выполняет все работы быстрее других.

В этом году победителем VMware Odyssey стал Александр Никитин заместитель руководителя группы системного администрирования ITGLOBAL.COM. Финальный раунд турнира был посвящен новому продукту VMware Tanzu Kubernetes Grid. Александр выполнил все задания за 15 с небольшим минут; для сравнения, участник, который занял 2 место, за 41 минуту.



ITGLOBAL.COM ежегодно подтверждает партнерский статус VMWare Advanced Partner. В компании выстроена система обучения технологиям вендора. Инженеры и администраторы в обязательном порядке сдают экзамен на сертификацию VMware Certified Professional у нас 5 таких специалистов. Среди них и Александр Никитин.

Мы попросили Александра рассказать, как проходил конкурс VMware Odyssey, насколько трудными были задания, как он готовился и что в итоге дает эта победа, кроме дополнительного подтверждения высокого профессионального уровня.

Как проходил конкурс?

Во время конференции VMworld любой желающий может выполнить ту или иную лабораторную работу, часть из них относится к конкурсным работам VMware Odyssey. Конкурс проходит поэтапно: отборочный тур, четвертьфинал, полуфинал, финал. В этом году и конференция, и конкурс проходили онлайн. Финальный раунд VMware Odyssey транслировался в Twitch.

На выполнение обычной работы дается 1 час. При этом у тебя есть полчаса для выполнения заданий и получения дополнительных баллов они начисляются за каждую не потраченную на выполнение заданий секунду. Одно правильно выполненное задание 400 баллов. Каждая секунда оставшегося времени плюс 1 балл. То есть ты получаешь фиксированное количество баллов за каждый этап и плюс то, что у тебя осталось до первого получаса времени.

В финале, например, все кто выполнил все задания и при этом превысили время в 30 минут, дополнительных баллов не получили у них вышло суммарно по 1600 баллов. У меня же оставалось 14 неизрасходованных минут, за которые я получил дополнительно 884 балла итого 2484.

В конкурсе в этот раз участвовало около 200 человек. В финал, насколько я помню, вышли 8.

Я участвовал впервые. Это получилось, потому что конкурс проходил онлайн. В 2018 и 2019 годах, когда я бывал на офлайн-мероприятиях VMworld, я успевал сделать только несколько простых лабораторных работ. Тогда мне сложно было выделить время между докладами и сессиями конференции.

Как оценивались работы?

Есть программа, которая контролирует правильность выполнения заданий. При этом тебя ничто не ограничивает: можешь пользоваться документацией, можешь гуглить. Но ты тратишь на это время, а тут результат зависит от скорости решения.

Какие задания были на конкурсе?

Второй раунд был посвящен продукту vSAN это распределенное хранилище данных (кстати, наша компания разработала конкурентоспособную платформу, которая называется vStack). У меня с vSAN знакомство поверхностное, но этих знаний было достаточно, чтобы выполнить лабу.

Полуфинал был посвящён сетевой безопасности и продукту NSX Advanced Load Balancer, который VMware представили в начале года.

Финал также был посвящен новому продукту Tanzu Kubernetes Grid, решению для работы с контейнерами. С ним я вообще не был знаком. Но, благо, организаторы заранее назвали тему каждого этапа, давая возможность подготовиться.

Как готовился?

Тем же NSX Advanced Load Balancer я в принципе интересовался. До этого я выполнял лабу, которая очень сильно перекликалась с тем, что было на конкурсе, поэтому конкурсную работу мне было несложно сделать.

К первому этапу по vSAN я специально не готовился. Не думал, что настолько заинтересуюсь и что вообще пройду дальше полуфинала. Отборочные были ещё задолго до конференции, и я даже сделал несколько работ по vSAN это заняло минут 15. Ближе к началу мероприятия мне сообщили, что я прошел отборочный тур, и предложили участвовать дальше.

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

Какие были трудности при решении заданий?

В финале последняя задача была посвящена тому, с чем я вообще не работал, и мне пришлось гуглить. Это меня очень огорчило, я думал, что потерял много времени. Наверное, где-то пару минут я гуглил, нашел, как это сделать, сделал, нажал кнопку Проверить и мне зачли результат.

Как оцениваешь уровень сложности?

Задания несложные. В целом у VMware такие градации: уровень 100 для начинающих, уровень 200 уже для продвинутых специалистов, 300 для экспертов, кто глубоко погружен в продукт и очень хорошо его знает. Уровень сложности лабораторных между 100 и 200. То есть часть задач была очень простой, уровня 100, какая-то часть была посложнее на уровне 200.

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

Что получил за победу на конкурсе?

Мне подарили комплект NUC9 Extreme Kit в максимальной конфигурации с процессором Intel Core i9 с индексом 9980HK. По сути, это маленький персональный компьютер, очень мощный и очень компактный. Мы вместе с командой ТехЛаб сделали распаковку и обзор этого девайса.

Но официальной какой-то ачивки за 1 место нет. Можно теперь просто говорить: Вот, ребят, я выиграл VMware Odyssey.

Как долго работаешь с продуктами VMware?

С начала работы в компании, то есть с 2016 года. Тогда она ещё называлась ИТ-ГРАД. Я пришел на должность системного администратора VMware, при том, что у меня практически не было бэкграунда по продуктам VMware. Но на тот момент у меня был уже нормальный опыт работы с виртуализацией в целом, я работал с Microsoft Hyper-V.

Чем, на твой взгляд, хороши решения VMware?

Сложно сказать. Я для этого слишком ангажирован сейчас. То есть я работаю только с VMware и практически не слежу за тем, что происходит у конкурентов. Я не могу сказать, что VMware прям лучше всех. Ну, безусловно, это лидеры рынка, они задают тон всем остальным. VMware делают очень серьезные энтерпрайз-продукты.

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

Насколько оцениваешь сложность продуктов VMware? Какая квалификация нужна, чтобы управлять такой инфраструктурой?

Некоторые продукты VMware сделаны очень хорошо. Они сейчас достаточно понятные, но, безусловно, в каждый нужно погружаться. На мой взгляд, просто так без багажа знаний, наверное, это не получится. Конечно, ты можешь начать что-то устанавливать, благо документации и статей очень много. То есть ты можешь что-то установить и даже настроить, но без глубокого понимания можно столкнуться с очень большими проблемами. Если ты потом начнешь это использовать в продуктивной среде, можно наступить на очень большое количество граблей.

Здесь важно знать и архитектуру как сделать правильно, с учетом лучших практик, скажем так. То есть нюансов очень много. Но так, в общем-то, с любым вендором.

P. S.

В следующем посте анбоксинг комплекта NUC9 Extreme Kit, который Александр получил за победу в VMware Odissey Hands-On Lab Challenge. Расскажем, на что способна самая производительная рабочая станция Intel.

---

Блог ITGLOBAL.COM Managed IT, частные облака, IaaS, услуги ИБ для бизнеса:

• АНБ утверждает, что российские хакеры атакуют платформы VMware
• Эволюция ИТ: от локальных серверов до managed services
• Как получить новый сертификат инженера по машинному обучению от Google Cloud
• Модель managed IT как альтернатива аутсорсингу и аутстаффингу. Опыт сервис-провайдера

---

Промышленный Machine Learning: 10 принципов разработки

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

И, порой, каждый начинающий программист, будь он страстным стартапером или же рядовым Full Stack или Data Scientist, рано или поздно приходит к осознанию того, что есть определенные правила программирования и создания софта, которые сильно упрощают жизнь.

В этой статье я кратко опишу 10 принципов того, как стоит программировать промышленный machine learning, чтобы его можно было легко встроить в приложение/сервис, основываясь на методике 12-factor App, предложенной командой Heroku. Моя инициатива это повысить узнаваемость этой методики, что может помочь многим разработчикам и людям из Data Science.

Эта статья это пролог к серии статей про промышленный Machine Learning. В них я дальше буду рассказывать о том, как, собственно, сделать модель и запустить ее в продакшн, создать для нее API, а также примеры из различных областей и компаний, которые имеют встроенный ML в их системы.

Принцип 1. Одна кодовая база

Некоторые программисты на первых этапах из-за лени разобраться (или по каким-то своим соображениям) забывают про Git. Забывают либо от слова совсем, то есть кидают файлы друг другу в драйве/просто кидают текст/отправляют голубями, либо не продумывают свой workflow, и делают commit каждый в свою ветку, а потом и в мастера.

Этот принцип гласит: имейте одну кодовую базу и много развертываний.

Git можно использовать как в production, так и в research and development (R&D), в котором он используется не так часто.

Например, в R&D фазе Вы можете оставлять коммиты с разными методами обработки данных и моделями, для того, чтобы потом выбрать наилучший и легко продолжить работать с ним дальше.

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

А также Вы можете создать package своего проекта, разместив его, например, на Gemfury, и дальше просто импортируя функции из него для других проектов, чтобы не переписывать их 1000 раз, но об этом чуть позже.

Принцип 2. Четко объявляйте и изолируйте dependencies

В каждом проекте есть разные библиотеки, которые вы импортируете извне для того, чтобы где-то их применить. Будь то это библиотеки Python, или библиотеки других языков разных предназначений, или системные инструменты Ваша задача:

• Четко объявить dependencies, то есть файл, в котором будут прописаны все библиотеки, инструменты, и их версии, которые используются в Вашем проекте и которые должны быть установлены (например, в Python это можно сделать с помощью Pipfile или requirements.txt. Ссылка, позволяющая хорошо разобраться: realpython.com/pipenv-guide)
• Изолировать dependencies специально для Вашей программы во время разработки. Вы же не хотите постоянно менять версии и переустанавливать, например, Tensorflow?

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

Ваше приложение также не должно опираться на системные инструменты, которые могут быть установлены на определенной ОС. Эти инструменты нужно также объявлять в манифесте dependencies. Это нужно для того, чтобы избежать ситуаций, когда версия инструментов (а также их наличие), не совпадает с системными инструментами определенной ОС.

Таким образом, даже если практически на всех компьютерах можно использовать curl, то следует все равно объявить его в dependencies, так как при миграции на другую платформу его может не быть или версия будет не той, которая Вам изначально была нужна.

Например, Ваш requirements.txt может выглядеть вот так:

# Model Building Requirementsnumpy>=1.18.1,<1.19.0pandas>=0.25.3,<0.26.0scikit-learn>=0.22.1,<0.23.0joblib>=0.14.1,<0.15.0# testing requirementspytest>=5.3.2,<6.0.0# packagingsetuptools>=41.4.0,<42.0.0wheel>=0.33.6,<0.34.0# fetching datasetskaggle>=1.5.6,<1.6.0

Принцип 3. Конфигурации

Многие слышали об историях, когда разные ребята-девелоперы случайно загружали код на GitHub в открытые репозитории с паролями и другими ключами от AWS, просыпаясь на следующий день с задолженностью в 6000$, а то и со всеми 50000$.



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

Альтернатива этому это хранить конфигурации в переменных среды. Более подробно о переменных среды Вы можете прочитать здесь.

Примеры данных, которые обычно хранят в переменных среды:

• Имена доменов
• API URL/URIs
• Публичные и приватные ключи
• Контакты (почта, телефоны и тд)

Таким образом, Вы можете не менять постоянно код, если Ваши переменные конфигурации будут меняться. Это поможет сохранить Вам время, силы и деньги.

Например, если вы используете Kaggle API для проведения тестов (например, скачиваете дотаяет и прогоняете через него модель, чтобы протестировать при запуске, что модель работает хорошо), то приватные ключи от Kaggle, такие как KAGGLE_USERNAME и KAGGLE_KEY надо хранить в переменных среды.

Принцип 4. Сторонние службы

Идея здесь это создавать программу таким образом, чтобы не было различий между локальными и сторонними ресурсами в плане кода. Например, вы можете подключить как локальную MySQL, так и стороннюю. То же самое касается и различных API, таких как Google Maps или Twitter API.

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

Так, например, вместо того, чтобы указывать каждый раз путь к файлам с датасетами внутри кода, лучше воспользоваться библиотекой pathlib и объявить путь к датасетам в config.py, чтобы не зависимо от того, каким сервисом Вы выпользуетесь (например, CircleCI), программа смогла узнать путь к датасетам с учетом строения новой файловой системы в новом сервисе.

Принцип 5. Сборка, релиз, runtime

Многим людям из Data Science полезно качать навыки по написанию софта. Если мы хотим, чтобы наша программа как можно реже падала, и как можно дольше работала без сбоев, нам нужно разделить процесс релиза новой версии на 3 этапа:

1. Этап сборки. Вы преобразуете Ваш голый код с отдельными ресурсами в так называемый пакет, который содержит весь необходимый код и данные. Этот пакет и называется сборкой.
2. Этап релиза к сборке здесь мы подключаем наш config, без которого мы бы не смогли выпустить нашу программу. Теперь это полностью готовый к запуску релиз.
3. Далее идет этап выполнения. Здесь мы выпускаем приложение с помощью запуска необходимых процессов из нашего релиза.

Подобная система релиза новых версий модели или всего пайплайна позволяет разделять роли между администраторами и разработчиками, позволяет отслеживать версии и предотвращает нежелательные остановки работы программы.

Для задачи релиза создано множество различных сервисов, в которых Вы можете записать процессы для запуска сами в .yml файл (например, в CircleCI это config.yml для обеспечения самого процесса). Wheely отлично создает package для проектов.

Вы сможете создавать пакеты с различными версиями вашей machine learning модели, и после чего пакетировать их и отсылаться к нужным пакетам и их версиям, чтобы использовать оттуда функции, которые Вы написали. Это поможет Вам создать API для Вашей модели, а Ваш пакет можно разместить например на Gemfury.

Принцип 6. Запускаем Вашу модель как один или несколько процессов

Причем процессы не должны иметь разделяемых данных. То есть процессы должны существовать отдельно, а всевозможные данные отдельно, например, на сторонних службах по типу MySQL или других, смотря на то, что Вам нужно.

То есть данные внутри файловой системы процесса хранить точно не стоит, иначе это может привести к очищению от этих данных при следующем релизе/изменении конфигураций или переноса системы, на которой работает программа.

Но есть исключение: для machine learning проектов можно хранить кэш библиотек, чтобы не переустанавливать их каждый раз при запуске новой версии, если дополнительных библиотек или каких-либо изменений в их версиях произведено не было. Таким образом, вы сократите время запуска вашей модели в промышленности.

Чтобы запустить модель как несколько процессов, можно создать .yml файл, в котором вы как раз и укажете необходимые процессы и их последовательность.

Принцип 7. Утилизируемость

Процессы, которые работают в вашем приложении с моделью, должны легко запускаться и останавливаться. Таким образом, это позволит быстро развертывать изменения кода, изменения конфигураций, быстро и гибко масштабироваться и предотвратит от возможных поломок рабочей версии.

То есть ваш процесс с моделью должен:

• Минимизировать время запуска. В идеале время запуска (от момента, когда была подана команда запуска до момента, когда процесс придет в рабочее состояние) должно иметь не более нескольких секунд. Кэширование библиотек, описанное выше это одна из методик уменьшения времени запуска.
• Завершаться корректно. То есть фактически приостанавливается прослушивание порта сервиса, и новые запросы, поданные в этот порт, не будут обрабатываться. Здесь уже нужно либо настраивать неплохую связь с DevOps инженерами, или самому понимать, как это работает (желательно, конечно, второе, но связь поддерживать нужно всегда, в любом проекте!)

Принцип 8. Непрерывное развертывание/интеграция

Во многих компаниях используют разделение между командами разработки приложения и его развертывания (делающее приложение доступным для конечных пользователей). Это может сильно замедлять разработку софта и прогресса в его улучшении. А также это портит культуру DevOps, где разработка и интеграция, грубо говоря, объединены.

Поэтому этот принцип гласит о том, что среда Вашей разработки должна быть максимально приближена к среде Вашего продакшена.

Это позволит:

1. Снизить время релиза в десятки раз
2. Снизить количество ошибок из-за несовместимости кода.
3. Также это позволяет снизить нагрузку на персонал, так как разработчики и люди, развертывающие приложение теперь одна команда.

Инструменты, которые позволяют с этим работать CircleCI, Travis CI, GitLab CI и другие.

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

Минимизируйте различия!!!

Принцип 9. Ваши логи

Logs (или Логи) это записанные обычно в текстовом формате события, которые происходят внутри приложения (поток событий). Простой пример: 2020-02-02 уровень системы имя процесса. Они созданы для того, чтобы разработчик мог буквально видеть то, что происходит, когда программа работает. Он видит ход процессов, и понимает, таков ли он, как сам разработчик задумывал.

Этот принцип гласит о том, что не стоит хранить свои логи внутри вашей файловой системы их нужно просто выводить на экран, например делать это в стандартном выводе системы stdout. И за потоком таким образом можно будет следить в терминале во время разработки.

Значит ли это что не нужно сохранять логи совсем? Конечно нет. Просто этим не должно заниматься Ваше приложение оставьте это сторонним сервисам. Ваше приложение может лишь перенаправить логи в определенный файл или терминал для просмотра в реальном времени или перенаправить его в систему для хранения данных общего назначения (например, Hadoop). Само Ваше приложение не должно хранить или взаимодействовать с логами.

Принцип 10. Тестируйте!

Для промышленного machine learning эта фаза крайне важна, так как Вам нужно понять, что модель работает правильно и выдает то, что Вы хотели.

Тесты можно создать с помощью pytest, и протестировать с помощью небольшого датасета, если у вас задача регрессии/классификации.

Не забывайте ставить одинаковый seed для deep learning моделей, чтобы они не выдавали постоянно разные результаты.

Это было краткое описание 10 принципов, и, конечно, сложно пользоваться ими не попробовав и не увидев то, как они работают, поэтому эта статья это лишь пролог к серии интересных статей, в которые я буду раскрывать то, как создавать промышленные machine learning модели, как их интегрировать в системы, и как эти принципы могут упростить нам всем жизнь.

Я также постараюсь использовать крутые принципы, которые кто-то по желанию может оставить в комментариях.

Amazon, Microsoft и Google раскрыли свои доходы за третий квартал 2020 г. они составили почти 33 млрд долл. Причина этого бурного роста в пандемии коронавируса, которая вынуждает компании по всему миру закрывать офисы и переносить работу в облака.

Главный аналитик Synergy Research Джон Динсдейл отмечает, что это стало неожиданностью: Хотя мы ожидали продолжения роста на рынке, итоги третьего квартала оказались несколько удивительными. Для такого крупного рынка это необычно. Очевидно, что коронавирус дал дополнительный толчок отрасли, которая и так стремительно развивалась.

Первые места

Лидер рынка предсказуемо, Amazon, с доходом в 11,6 млрд долл. в третьем квартале, в прошлом цифра составила 10,8 млрд долл. Эти показатели на 29% больше прошлогодних. Amazon продолжает демонстрировать замедление роста на рынке облачных вычислений, но зато стабильно удерживает лидерство в части доли рынка (33%). Доходы компании почти вдвое выше, чем у ближайшего конкурента, Microsoft.

Microsoft Azure занимает 18% рынка; доходы выросли на 48% в год. В третьем квартале компания получила на 700 млн долл. больше чем, во втором.

Google объявила о росте доходов от облачных вычислений на 9%, за третий квартал она получила 2,98 млрд долл., за второй 2,7 млрд. долл.

Alibaba и IBM разделили четвертое место с ростом в 5% и около 1,65 млрд долл. выручки.

При этом, облачное подразделение Alibaba планирует в этом году впервые выйти в плюс. Генеральный директор компании Дэниел Чжан заявил, что наибольший вклад в рост облачного подразделения внесли государственный сектор и финансовые услуги.

Мы считаем, что облачные вычисления являются фундаментальной инфраструктурой цифровой эры, но они все еще находятся на ранней стадии роста. Мы намерены и дальше увеличивать наши инвестиции сюда, сказал Чжан.

Финансовый год Alibaba начался в апреле 2020 года и закончился 31 марта 2021 года.

Коронавирус как двигатель прогресса

Аналитическое агентство Gartner с мая по июнь 2020 года провелоонлайн-опрос 256 членов советов директоров крупных компаний в США, Европе и Азии. Они рассказали, как пандемия повлияла на внедрение новых технологий в компаниях. 67 % опрошенных рассказали, что увеличили бюджет на ИТ. А 7 из 10 членов советов директоров ускорили цифровизацию компаний с началом пандемии.

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

Пандемия продемонстрировала ценность цифровизации в тех областях, где физический контакт стал сложнее например, в торговле. Быстрая трансформация процессов стала для компаний вопросом выживания в новых условиях.

Что дальше

Аналитик компании Canalys Блейк Мюррей говорит, что пространство для дальнейшего роста рынка есть. В ближайшем будущем гибридные облака начнут активно использоваться в новых технологиях, таких как 5G. Все три провайдера сотрудничают с операторами мобильной связи и разворачивают свои облачные стеки в центрах обработки данных операторов. Цель этих действий извлечь прибыль из услуг 5G на рынке бизнес-клиентов, а также преобразовать ИТ-инфраструктуру мобильных операторов, говорит он.

---

Блог ITGLOBAL.COM Managed IT, частные облака, IaaS, услуги ИБ для бизнеса:

• Какой вид облаков выбирают компании сегодня. Российская и зарубежная практика
• Главные тенденции ИТ-индустрии в 2021 году по версии Gartner
• Эволюция ИТ: от локальных серверов до managed services
• Боли стартапов: как правильно развивать ИТ-инфраструктуру

---

На ежегодной конференции NetApp Insight и последовавшей за ней Cloud Field Day 9 (CFD) компания NetApp представила новые продукты и рассказала о стратегии компании на будущее. Кроме прочего, NetApp анонсировала множество новых проектов, связанных с мультиоблачными решениями.

Полноценный переход к Data Fabric

Когда-то компания специализировалась только на решениях, в основе которых была ONTAP собственная операционная система компании для хранилищ данных, таких как NetApp FAS и AFF. Однако несмотря на то, что система действительно хорошо работает, ее невозможно применить ко всем новым продуктам NetApp. Это мешало развитию новых решений.

В 2019 году NetApp рассказала об изменениях в стратегии развития и выпуске новых продуктов на основе Data Fabric (фабрика данных) это единый комплекс из технических и программных компонентов, который помогает организациям управлять данными в гибридных и мультиоблаках, объединять локальную и облачную инфраструктуру. Такие решения упрощают управление большими массивами данных и интеграцию облачных технологий для заказчиков.

Это было стало большим шагом вперед для компании. NetApp начала разрабатывать такие продукты, как объектное хранилище StorageGrid, купила компанию Solidfire, интегрировала различные семейства продуктов, чтобы все работало вместе, и добавила дополнительные инструменты, чтобы упростить жизнь своим клиентам. В конце концов, ONTAP перестала быть единственным ответом на все вопросы, и компания стала двигаться вперед.

Облако, построенное на основе Data Fabric

Концепция Data Fabric и год назад включала облако, но в некоторых аспектах она была неполной. Data Fabric была разработана еще до успеха Kubernetes, а о мультиоблаке и речи не шло.

После Insight и CFD, обновление стратегии кажется завершено. Можно сказать, что NetApp сегодня является одним из наиболее развитых провайдеров на рынке гибридных технологий. Проекты Astra или даже новый VDS (Virtual Desktop Service) используют в основе Data Fabric.

NetApp больше нельзя назвать простым поставщиком хранилищ, по крайней мере, не в традиционном смысле. Компания диверсифицируется и становится серьезным игроком на рынке облачных вычислений. Также интересно, что компания делает это таким образом, чтобы не конкурировать с известными поставщиками облачных услуг или их партнерами.

Фактически, NetApp позиционирует семейство своих продуктов как основу для беспрепятственного перемещения данных из локальной среды в облако, а затем управления ими с единым пользовательским интерфейсом, независимо от используемых облачных платформ. То есть NetApp предоставляет разнообразные возможности для работы с данными в облаках, расширяя для пользователей свободу выбора.

Компания создает набор интересных решений на основе надежных и согласованных методов управления данными. С определенной точки зрения эта стратегия похожа на стратегию VMware: их стек теперь доступен во всех облаках, а на его основе построены дополнительные решения (например, Disaster-Recovery-as-a-Service или послеаварийное восстановление как услуга, появившийся в результате приобретения Datrium).

Что в итоге

Можно ли по-прежнему классифицировать NetApp как традиционного поставщика систем хранения? Определенно доходы от продажи систем хранения данных по-прежнему составляют львиную долю их доходов (так что они все еще традиционные в этом плане), но изменение стратегии здесь весьма заметно, и доходы от облачных вычислений становятся все более внушительными.

Большинство предприятий меняют свое представление об ИТ-инфраструктуре. Гибридные и мультиоблачные решения теперь стали нормой. Пользователи хотят быстро и просто запускать свои приложения там, где этого требует бизнес. Быть просто поставщиком хранилищ уже недостаточно.

Важно отметить, что с этой точки зрения NetApp не одинока (мы уже упоминали VMware). Аналогичной стратегии придерживаются и у других компании, такие как RedHat. Все они хотят создать единый пользовательский интерфейс независимо от того, где клиент развертывает свой бизнес (и данные).

Прогноз

Сможет ли NetApp снова измениться? Будет ли это надежный поставщик облачных услуг и станет ли компания настоящим поставщиком гибридных облачных хранилищ? Компания хорошо справилась с переходом на Data Fabric и находится на правильном пути, чтобы повторить успех. Сравнивая NetApp с некоторыми другими традиционными поставщиками систем хранения, у них действительно хорошие возможности расширить список услуг и закрепится на рынке облачных технологий.

---

Блог ITGLOBAL.COM Managed IT, частные облака, IaaS, услуги ИБ для бизнеса:

• Какой вид облаков выбирают компании сегодня. Российская и зарубежная практика
• Главные тенденции ИТ-индустрии в 2021 году по версии Gartner
• Эволюция ИТ: от локальных серверов до managed services
• Боли стартапов: как правильно развивать ИТ-инфраструктуру

---