Что меняется в Highload системах с точки зрения DevOps?
Highload-системы смещаются в сторону Data-Intensive приложений, где качество данных становится критически важным наряду с качеством кода. Одновременно возрастает потребность в бережливом использовании ресурсов и появлении мульти-модельных возможностей в управлении данными, что усложняет стратегии хранения и отказоустойчивости. DevOps-инженерам предстоит готовиться к ограничениям доступа к пользовательским данным, использование инфраструктуры под AI/LLM и дальнейшее развитие платформенного инжиниринга в рамках концепции «всё как код».
- Почему мне вообще стоит писать этот текст, а вам его читать?
- Что такое Highload системы, и зачем мы используем DevOps?
- Развитие Highload до настоящего времени
- Развитие Open Source сообществ
- Тренды и Вызовы нового времени
- Что измениться в Highload системах?
- К чему стоит быть готовым DevOps инженеру?
- Влияние на менеджмент и бизнес
Привет! Меня зовут Михаил, во первых я возглавляю центр компетенций DevOps в компании ГНИВЦ, во вторых у меня есть управленческая шапочка - Delivery Manager. В область моих интересов попадают как сами технологии, так и люди которые с ними работают и процессы которые объединяют все в единое целое.
В этой статье постараюсь кратко и понятно рассказать о том, что по моему мнению ждет бизнес в области Highload систем в ближайшее время, и какие навыки и знания пригодятся менеджменту и инженерам для успешной работы в этой, очень конкурентной области.
Highload системы - это системы, которые обрабатывают большое количество запросов в единицу времени. Это наверно самое простое определение, которое можно дать. Оно, скажем так, не очень вносит ясности. И если мы начнем гуглить в англоязычном сегменте, то увидим, что термин Highload не так часто используется, как в русскоязычном сегменте. Термины high-throughput computing (HTC), High-performance computing (HPC) относятся скорее к суперкомпьютерным системам, которые тоже обрабатывают большое количество данных в единицу времени, и собственно никуда не делись и продолжают развиваться и приносить пользу человечеству.
Возможно виной тому одна из самых больших в Европе конференций Highload++, которая проходит уже более 10 лет и популяризировала этот термин. Не знаю. Но такая вот история.
Пропустив этап технологической гонки на суперкомпьютерах, мы фактически создали свой собственный термин, который описывает идеальную систему. Идеальную, потому что она обрабатывает много запросов, идеальную, потому что она масштабируется, идеальную, потому что она надежная. Идеальную, потому что она дешевая. Идеальную, потому что она быстрая и отзывчивая. Идеальную, потому что она безопасная. Идеальную, потому что она удобная и красивая. Тут еще можно долго продолжать, и думаю, что вы поняли идею.
Что еще важно упомянуть - индустрия сместила фокус от мейнфреймов и супер компьютеров в тот момент, когда стала понятна стоимость их увеличения мощности и масштабирования под растущие задачи. Новому бизнесу было не по карману покупать дорогое железо, они стали использовать простые и дешевые 1-2 процессорные серверы с не очень большим объемом памяти, но вкладываясь в разработку софтверной бэкенд части, которая могла бы масштабироваться по мере роста бизнеса. И вот тут потребовались новые практики, которые в последствии стали называться SRE и DevOps.
Можно по разному относиться к термину Highload, но в целом он используется, чтобы совсем уж по разному его не понимать предлагаю использовать следующее тезисы:
- Дешево обслуживает большое количество людей, обычно через Интернет, зарабатывая на массовости
- Микросервисная архитектура + Twelve-Factor App
- Разработка отдельных сервисов ведется в небольших командах
- Распределенная система, которая может быть легко масштабирована в облаках
Уточнять еще можно долго, но в целом это то, что вижу вокруг себя - то где находятся или куда движутся компании.
DevOps/SRE практики предназначены прежде всего для ускорения процесса разработки и внедрения нового функционала. Причем не просто ускорения, а ускорения без потери качества.
Можно рассуждать про культуру, а можно еще раз вспомнить, что цель новых компаний - найти свою нишу на рынке, и начать зарабатывать деньги. И чем быстрее идеи будут превращаться в действующие продукты, тем быстрее станет понятно - хорошая идея это или нет. И еще хотелось бы в случае сбоев, которые неизбежны - быстро их устранить, чтобы не потерять репутацию и клиентов.
Первые поисковые системы стали основой для той сети Интернет, которую мы знаем сегодня. Google (1998), Яндекс (1997) - это те компании, которые внесли свой вклад в развитие Highload и DevOps, стали успешными и популярными. Но что пожалуй самое важное - они стали коммерчески успешными. Бизнес модель заработка на контекстной рекламе, которую они предложили стала успешной.
Примерно в это же время появились первые электронные коммерции: Amazon (1994), eBay (1995), Ozon (1998), Avito (2007) - их путь к успеху был более долгим из-за трудностей да и стоимости масштабирования офлайн части бизнеса.
Facebook (2004), ВКонтакте (2006) - с бизнес моделью, которая позволяет зарабатывать на рекламе. Внутри был функционал по обмену сообщениями, который впоследствии вырос в мессенджеры.
Предоставление вычислительных мощностей и хранилища данных позволило не только зарабатывать компаниям Amazon Web Services (2006), Google Cloud (2008), Microsoft Azure (2010) которые уже имели свои инфрастуктуры, но и открыла доступ для малых и средних компаний к Highload.
Netflix (1997), YouTube (2005), Spotify(2006) - с бизнес моделью, которая позволяет зарабатывать на подписках и рекламе.
Для экономии времени пропустим моменты с появлением сервисов видеоконференций, онлайн игр, онлайн образования, агрегаторов и сервисов бронирования, государственных сервисов ГосУслуги (2010), АИС Налог (1997), Блокчейн, NFT и т.д.
BigData появился в недрах компаний, которые уже обрабатывали большие объемы данных. И внутри этих компаний BigData начал приносить пользу. А вот широкое сообщество ограничивалось мемом - "Big Data - это как подростковый возраст: все о нем говорят, но никто толком не знает, как их делать". И значимых новых компаний на этой волне не появилось. Данные - как нефть, но не каждый может ее добыть и обработать.
BigData усложнила задачи Highload систем, разделив из на 2 сегмента: транзакционный и аналитический. Также потребовались потребовались инструменты для обработки больших объемов данных, и вот тут на помощь пришли Kafka (2011), концепции Data Lake и Data Warehouse (2010), ElasticSearch (2010) и ETL/ELT процессы на продуктах Apache Nifi(2006).
Вершиной пищевой цепочки данных тогда были BI системы, в основном проприетарные, которыми пользовались Аналитики да и менеджмент в крупных компаниях.
Примерно в 2007-2010гг стал развиваться рынок смартфонов, и это стало новым вызовом для Highload систем. Появилась необходимость в мобильных приложениях, которые работали через нестабильные GSM сети, с используя небольшие аппаратные ресурсы, но требующие меньшего времени отклика чем классические веб-сайты.
И да, это стал новый огромный рынок, зародилась концепция mobile first (2010), и появились новые бизнесы, которые зарабатывали благодаря мобильным приложениям - Uber (2009), WhatsApp (2009), Instagram (2010) да и электронным площадкам это дало новый толчок к развитию.
Рост числа пользователей позволил, или потребовал новых инженерных решений, так в 2014г появился Kubernetes - фактически стандарт для оркестрации контейнеров, который позволил масштабировать Highload системы на новый уровень, и без которого трудно сейчас представить работу DevOps инженера.
В первую волну появились PayPal (1998), Qiwi (2007), Яндекс.Деньги (2002), но это были скорее платежные системы, чем банковские, с ограниченным функционалом и ограниченным числом пользователей. Во вторую волну появились Тинькофф Банк (2006), N26(2013), Revolut (2015), которые предложили новые услуги и стали конкурировать с традиционными банками. Причем без офлайн офисов, что позволило им сэкономить на аренде и персонале, и вложить эти деньги в развитие Highload систем.
На данном этапе уже существующие игроки начали создавать экосистемы, предлагая своим пользователям все больше услуг. Яндекс (2014), Google (2004), Сбер (2018), Microsoft (2010) все больше и больше стали конкурировать за внимание пользователей, за их данные и деньги.
Фактически это контекст, происходивший вокруг Highload систем. Ускорение старта новых бизнесов, уменьшение порога входа и упрощение рефакторинга существующих систем - это то, на что повлиял Open Source с точки зрения бизнеса.
Apache Software Foundation (1999), Python Software Foundation (2001), Linux Foundation (2007), OpenInfra (ранее OpenStack) Foundation(2012), Cloud Native Computing Foundation (2015). CNCF создана под эгидой Linux Foundation, курирует проекты, связанные с cloud-native архитектурой - Kubernetes(2014), Prometheus(2012), Envoy, Helm(2015), gRPC(2015) и многие другие. CNCF быстро выросла в одно из самых влиятельных сообществ в сфере облачных технологий и DevOps.
Стандартизация технологий еще один неопалимый плюс Open Source сообществ. Разработчикам и DevOps-ам стало проще работать, с потенциально меньшим количеством ошибок, а бизнесу стало проще ратировать специалистов и уменьшить затраты на обучение.
При всех плюсах Open Source работы безопасникам это добавило. Сообщества по типу OWASP(2001) несколько смягчают техничскую проблематику, вместе DevSecOps практиками. В широком смысле безопасность Open Source - это большая тема, которая заслуживает отдельного разговора.
- LLM, AI и этичное использование
- Бережливое использование ₽ ресурсов и человеческого капитала
Стоит учитывать реалии рыночных и политических взаимодействий, обособление как российского, так и китайского рынков, их закрытость и требования к хранению данных. Европейский рынок в принципе очень зарегулирован, и требования в том числе к хранению данных там еще выше. Все это влечет к локализации технологических стеков и облачных сервисов.
- BigData и Data Science
- IoT и умные устройства
- Blockchain и NFT технологии
- Рост объемов данных, требований к данным и их сложности
- Рост числа угроз кибер-безопасности
Highload системы будут все более сдвигаться от Compute-Intensive к Data-Intensive приложениям. Причем это происходит даже с учетом AI и ML, которые вроде как должны быть Compute-Intensive. Требования к качеству данных (Data Quality Requirements) становятся такими же важными, как и качество кода.
Бережливое использование ресурсов становится заметным как на уровне БД, так и в более широком смысле - уровне управления данными. Если раньше мы могли скопировать одни и те-же данные несколько раз, например для аналитического сегмента в отдельную column-oriented БД, то сейчас это становится в некотных случаях коммерчески нецелесообразным. Multi-model функционал появился в PostgreSQL, Redis, MongoDB, YandexDB и других БД, что позволяет хранить разные типы данных в одной БД и использовать их в разных сценариях.
Появилось много Open Source баз данных под разные задачи, которые мы не можем просто взять и разметить в Kubernetes для увеличения надежности. Для каждого такого элемента с данными нужно продумывать стратегию хранения, доступности, обработки и восстановления в случае сбоев, катастроф и атак. Не то что это раньше не делали, но сейчас разных БД данными различных типов становится все больше и больше.
Появилась плотная работа LLM моделями, которые требуют многопоточных вычислений на GPU и взаимодействие с Nvidia CUDA, что специфической инфраструктуры.
Кроме работы с AI/LLM моделями - ничего принципиально нового. Меняются акценты и реализации.
Использование облачных платформ и стандартизированных компонентов. Развитие практик GitOps и Infrastructure as Code. Собственные разработки останутся только в сильно спрециализированных областях бизнеса конкретных компаний. И большинство обслуживания - тоже, перейдет в облака.
Да, на первый взгляд, это нарушения идеологии DevOps, но это не так. Это просто следствие увеличения рисков, соответсвия законодательствам и требований к безопасности. Инженеры в большинстве будут работать с анонимизированными данными, и только небольшая группа будет иметь доступ к персональным данным.
Работа с гипотезами и верификация информации полученной от ИИ. Своего рода "информационная гигиена". Запуск собственных моделей локально.
Сейчас есть доклады на даже на топовых конференциях, где проекты и команды стартовали без мониторинга и логирования, и как они героически справлялись вслепую. В угоду бизнесу. И вот такого подхода в ближайшем будущем не будет. Не потому что кому то станет жалко инженеров, а потому крайне рискованно с точки зрения бизнеса. Большинство компонент - арендованы, и если они не работают - это убытки. Или нет прогнозов по потреблению - это убытки. Или нет данных для аналитики - это убытки. И так далее.
Даже данные - это "код", который нужно версионировать, тестировать и разворачивать. Причем данные в широком смысле - трудовой договор или договор с подрядчиком, документация, бизнес-процессы, - ко всему этому тоже можно относиться как к коду.
Стандартизированные компоненты, работающие не под предельными нагрузками уйдут под управление системных инженеров. То-есть профессиональных "админов", которые будут заниматься только поддержкой.
Теперь отличаются не только стратегиями тестирования но и набором данных, которые на них аккумулируются.
Для простоты очертим 2 круга, круг людей и бизнесов кому повезло сильнее и круг тех, кто столкнется с большими трудностями.
К первым можно отнести крупные компании которые уже работают с большими данными и у них они есть. Это например государственные структуры, банки, телекомы, крупные интернет-компании. Самый большой вызов для них будет скорее в области бюрократии и законодательства, чем в технологиях. Из технологических вызовов можно отметить только необходимость замены исторически сложившихся систем, которые хоть и продолжают работать, но трудозатраты на их поддержку и развитие становятся все больше и больше.
С большими трудностями столкнутся малые и средние компании, которые еще не имеют больших ресурсов. Им придется не только конкурировать за внимание пользователей, но и за доступ к данным, чтобы улучшать свои продукты и рекомендательные системы. Также не стоит забывать про сложность минимального пакета инфрастуктуры, даже без учета AI/LLM моделей и катастрофоустойчивости, минимальная инсталляция Kubernetes с БД, очередями и мониторингом - это уже несколько человеко-месяцев работы. Да существуют публичные облака, да они с удовольствием предоставят вам все необходимое, но это будет стоить денег, и не малых.
Не таким уж и новым но востребованным скилом менеджера будет умение самостоятельно работать с первичными данными, агрегировать их и делать выводы. Причем идет речь не о разовой акции, а о способности работать в потоках информации. Вторым, но не менее важным скилом будет умение сроить процессы планирования. Причем не только бюджетов, а реалистичного образа результата и пути к нему.