Комментарии

На работе дали в нагрузку ML инженеров, сейчас со скрипом ковыряю процессы. На базе ажура. Что интересно, на самом деле очень тяжело объяснить подходы к автоматизации, стандартизации и т.п., они все хотят делать руками ;) Почитать было интересно, как раз некоторые моменты для себя прояснил, соберусь с новыми силами и продолжу.

Если в команде нет выделенной роли, которая отвечает за работоспособность стека ML-технологий, то не стоит отчаиваться — сейчас это пока норма. MLOps-инженеры пока еще могут считаться единорогами, почти как Angular-разработчики.

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

деплой ML-моделей отличается от деплоя кода,
Serving и Deploy требуют знаний специфических инструментов,
нужно разбираться в Kubernetes на высоком уровне, а такие специалисты и без ML на вес золота,
нужно использовать IaaС и дружить с Terraform,
вишенкой на торте является процесс Continuous Training, который подразумевает написание Python-скриптов для автоматизации взаимодействия разных компонентов в оркестраторах.

Как минимум нашему DevOps-специалисту потребуется много времени на изучение всех процессов и технологий. В одной версии идеального мира MLOps-специалист — следующая стадия развития DevOps-инженера. Когда уже все Terraform-файлы написал, сконфигурировал с помощью Ansible и в Kubernetes через Argo CD запустил.

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

На данный момент идеальный MLOps-инженер представляется как «воин дракона»: ученик, учитель, data scientist, backend developer, ML-инженер, data-инженер, devops, software developer и остальное в одном человеке. Только где такого найти?

Работаем в связке DST CRM и ДСТ платформ, охватывает весь спектр бизнеса, очень удобно

Используем DST CRM, охватывает все спектры работы, особенно работу с постановкой задач и персоналом, очень удобный и качественный софт

При всех преимуществах cloud bursting для бизнеса этот процесс не лишен риска, и многие из упомянутых в статье преимуществ могут исчезнуть в результате недостаточного планирования или прогнозирования регулярных процессов.

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

Быстрое масштабирование в облако (сloud bursting) может сыграть решающую роль в поддержании работоспособности сервисов как для сотрудников, так и для клиентов. Опрошенные порталом Information Age эксперты обсуждают, в чем заключается выгода этой концепции, где она может быть полезной и какие риски следует учитывать.

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

Что представляет собой cloud bursting и как предприятия могут эффективно использовать этот метод развертывания приложений, снижая при этом риски?

Как это работает

Сloud bursting — это когда приложения, работающие в частных или локальных средах (например, в дата-центре), попадают в публичное облако для использования дополнительных ресурсов. Компании могут настроить двусторонний доступ к ресурсам публичного облака для поддержания работы в случаях, когда потребность в ресурсах локальных или частных облачных сервисов достигает пика. Это может быть реализовано как вручную, так и автоматически, в зависимости от предпочтений и потребностей компании.

«Например, деятельность по обработке данных в частном облаке может быстро достичь пикового спроса. Поддержка масштабирования облачных сервисов во время пиковых нагрузок позволяет продолжать работу, получая при этом преимущества, связанные с возможностью восстановления масштаба в случае необходимости», — говорит Джейми Шилдс, ведущий архитектор облачных вычислений компании xDesign, занимающейся разработкой веб- и мобильных продуктов.

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

По мнению Рахула Прадхана, вице-президента по продуктам и стратегии компании Couchbase, предоставляющей облачные базы данных NoSQL, особую пользу cloud bursting может принести в двух основных режимах работы приложений. Первая — это кратковременные и высокоинтенсивные сезонные пиковые нагрузки, характерные для таких отраслей, как розничная торговля или электронная коммерция. «Примерами служат „черная пятница“ или пиковые сезоны бронирования путешествий на праздники, когда нагрузка может в 100 раз превышать нагрузку в обычный день», — говорит Прадхан.

Второй вариант, по его словам, связан с периодически используемыми рабочими нагрузками в области аналитики или машинного обучения. «Они не являются постоянно критически важными для бизнеса, однако вычислительные мощности, необходимые для их выполнения, значительно превышают возможности частных облаков или дата-центров, и их постоянное развертывание будет слишком дорогостоящим, — говорит Прадхан. — Именно в этом случае может помочь cloud bursting — масштабирование в облако в те короткие периоды, когда МО или аналитика жизненно важны для бизнеса, после чего они снова отключаются».

Очень полезный и интересно подан материал, автору респект

Наконец простым и понятным языком объяснили что такое безголовая CMS, спасибо, полезно

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

У нас как раз идёт внедрение внедрения DevSecOps. Спасибо, очень полезная статья

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

У нас в компании внедрили много облачных технологий, в том числе и CRM систему, возник вопрос как сделать все это максимально безопасным. Спасибо автору за статью

Информация представлена доступно и легко усваивается. Понравилось!

Спасибо за превосходное руководство! Очень помогло.

Очень полезное руководство с практической информацией.

Рекомендую эту статью для более глубокого понимания темы

Полезная информация, которая пригодится в работе.

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

Во-вторых, принципы REST мы часто применяем в жизни. Они очень полезны для осмысления. Кэширование, STATELESS и STATEFUL, клиент-серверная модель или код по требованию — это те вещи, которые аналитику полезно знать для понимания.

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

Водопад не любят не из-за того, что не понимают, его не любят из-за того, что он плохо подходит для сложных программных систем. Причин 2:
1. В современных условиях заказчик сам не знает и не может объяснить, чего же он в итоге хочет («чтоб было круто» — это не желание, это ощущение);
2. из-за п.1 бегать вверх-вниз по ступенькам водопада можно до бесконечности, как только проект переваливает определенную сложность (у нас в команде буквально за неделю аж 3 таких проекта появилось, притом так, что мы даже пока не знаем, в каких сроки и стоимость это получится уложить)

То, что вы озвучили в конце — это не разновидность водопада, это скорее спираль

Всем привет. Недавно открыл для себя интересный факт, что товарищ Винстон Ройс (Dr. Winston D. Royce), анонсируя свой знаменитый Waterfall говорил об итеративной модели разработки.

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

Изображение не загружено

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

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

К примеру, если рассмотреть параллельные работы по 2 последовательным фазам — Coding и Testing, становится очевидным, что часть программы выдается в тестирование, в то время как другая часть все еще находится на стадии разработки.
Т.е. получается, что речь действительно идет об итеративной методологии разработки ПО.

В таком случае остается вопросом, почему методология в широких кругах разработчиков и тестировщиков воспринимается ошибочно, как отображено на первом рисунке…