изображение создано нейросетью
Что ждет бизнес в области Highload-систем в ближайшее время и какие навыки и знания пригодятся менеджменту и инженерам для успешной работы в этой области? Ответы – в материале IT-World.
Я возглавляю центр компетенций DevOps в компании ГНИВЦ, а кроме того, у меня есть управленческая шапочка — Delivery Manager. В область моих интересов попадают как сами технологии, так и люди, которые с ними работают, и процессы, которые объединяют все в единое целое.
Содержание:
Что такое Highload системы и зачем мы используем DevOps?
История термина Highload
Highload-системы — это системы, которые обрабатывают большое количество запросов в единицу времени. Это, наверное, самое простое определение, которое можно дать. Оно, скажем так, вносит не очень большую ясность. И если мы начнем гуглить в англоязычном сегменте, то увидим, что термин Highload не так часто используется, как в русскоязычном сегменте. Термины high-throughput computing (HTC), High-performance computing (HPC) относятся скорее к суперкомпьютерным системам, которые тоже обрабатывают большое количество данных в единицу времени, и, собственно, никуда не делись и продолжают развиваться и приносить пользу человечеству.
Возможно, виной тому одна из самых больших в Европе конференций Highload++, которая проходит уже более 10 лет и популяризировала этот термин. Не знаю. Но такая вот история.
Пропустив этап технологической гонки на суперкомпьютерах, мы фактически создали свой собственный термин, который описывает идеальную систему. Идеальную, потому что она обрабатывает много запросов. Идеальную, потому что она масштабируется. Идеальную, потому что она надежная. Идеальную, потому что она дешевая. Идеальную, потому что она быстрая и отзывчивая. Идеальную, потому что она безопасная. Идеальную, потому что она удобная и красивая. Тут еще можно долго продолжать, и думаю, что вы поняли идею.
Важно упомянуть и то, что индустрия сместила фокус от мейнфреймов и суперкомпьютеров в тот момент, когда стала понятна стоимость их увеличения мощности и масштабирования под растущие задачи. Новому бизнесу было не по карману покупать дорогое «железо», и он стал использовать простые и дешевые 1-2-процессорные серверы с не очень большим объемом памяти, но вкладываясь в разработку софтверной бэкенд-части, которая могла бы масштабироваться по мере роста бизнеса. И вот тут потребовались новые практики, впоследствии названные SRE и DevOps.
Можно по-разному относиться к термину Highload, но в целом он используется, поэтому для общего понимания предлагаю использовать следующее тезисы:
Уточнять еще можно долго, но в целом это то, что вижу вокруг себя, то где находятся или куда движутся компании.
Зачем придумали DevOps?
DevOps/SRE-практики предназначены прежде всего для ускорения процесса разработки и внедрения нового функционала. Причем не просто ускорения, а ускорения без потери качества.
Как проектировать архитектуру High Load, не впадая в крайности
Можно рассуждать про культуру, а можно еще раз вспомнить, что цель новых компаний — найти свою нишу на рынке и начать зарабатывать деньги. И чем скорее идеи будут превращаться в действующие продукты, тем быстрее станет понятно: хорошая идея это или нет. И еще хотелось бы в случае сбоев, которые неизбежны, быстро их устранить, чтобы не потерять репутацию и клиентов.
Развитие Highload с 1990-х до настоящего времени
Первые Highload системы: поисковики и электронные площадки
Первые поисковые системы стали основой для той сети Интернет, которую мы знаем сегодня. 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 и т. д. Читайте также
Крах эпохи Intel? В конце января Intel представила финансовый отчёт за 2024 год, и если кратко — всё плохо. Чистый убыток составил $18,8 млрд, что стало антирекордом за всю историю компании. Падение идёт уже семь лет, но 2024-й стал особенно болезненным. Бывший гигант чипостроения теряет рынок, клиентов, сотрудников и даже своё место в индексе Dow Jones. Что пошло не так и есть ли у Intel шанс выбраться из этого кризиса, задается вопросом IT-World?
BigData
BigData появилась в недрах компаний, которые уже обрабатывали большие объемы данных. И внутри этих компаний BigData начала приносить пользу. А вот широкое сообщество ограничивалось мемом «Big Data — это как подростковый возраст: все о нем говорят, но никто толком не знает, как их делать». И значимых новых компаний на этой волне не появилось. Данные как нефть, но не каждый может ее добыть и обработать.
BigData усложнила задачи Highload-систем, разделив их на два сегмента: транзакционный и аналитический. Также потребовались инструменты для обработки больших объемов данных, и вот тут на помощь пришли 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), да и электронным площадкам это дало новый толчок к развитию.
Как принципы Agile и DevOps взаимодополняют друг друга, создавая культуру непрерывной интеграции и непрерывной доставки (CI/CD)
Рост числа пользователей потребовал новых инженерных решений. Так, в 2014 году появился Kubernetes — фактически стандарт для оркестрации контейнеров, который позволил масштабировать Highload-системы на новый уровень и без которого трудно сейчас представить работу DevOps-инженера.
Банковские и финансовые системы
В первую волну появились PayPal (1998), Qiwi (2007), «Яндекс.Деньги» (2002), но это были скорее платежные системы, чем банковские, с ограниченной функциональностью и ограниченным числом пользователей. Во вторую волну появились Тинькофф Банк (2006), N26(2013), Revolut (2015), которые предложили новые услуги и стали конкурировать с традиционными банками. Причем без офлайн-офисов, что позволило им сэкономить на аренде и персонале и вложить эти деньги в развитие Highload-систем.
Экосистемы
На данном этапе уже существующие игроки начали создавать экосистемы, предлагая своим пользователям все больше услуг. «Яндекс» (2014), Google (2004), Сбер (2018), Microsoft (2010) все больше стали конкурировать за внимание пользователей, за их данные и деньги.
Развитие Open Source-проектов и сообществ
Фактически это контекст, происходивший вокруг Highload-систем. Ускорение старта новых бизнесов, снижение порога входа и упрощение рефакторинга существующих систем — то, на что повлиял Open Source с точки зрения бизнеса.
Стандартизация технологий еще один неоспоримый плюс Open Source-сообществ. Разработчикам и DevOps-ам стало проще работать, с потенциально меньшим количеством ошибок, а бизнесу — проще ротировать специалистов и уменьшить затраты на обучение.
При всех плюсах Open Source работы безопасникам прибавилось. Сообщества по типу OWASP (2001) несколько смягчают техническую проблематику, вместе с DevSecOps-практиками. В широком смысле безопасность Open Source — это большая тема, которая заслуживает отдельного разговора.
Тренды и Вызовы нового времени
Хайповые темы
Стоит учитывать реалии рыночных и политических взаимодействий, обособление как российского, так и китайского рынков, их закрытость и требования к хранению данных. Европейский рынок в принципе очень зарегулирован, и требования, в том числе к хранению данных, там еще выше. Все это приводит к локализации технологических стеков и облачных сервисов.
Тематики идущие под капотом Highload-систем и бизнесов
Что изменится в Highload-системах?
Highload-системы будут все более сдвигаться от Compute-Intensive к Data-Intensive-приложениям. Причем это происходит даже с учетом AI и ML, которые вроде как должны быть Compute-Intensive. Требования к качеству данных (Data Quality Requirements) обретают такую же значимость, как и качество кода.
Бережливое использование ресурсов становится заметным даже на уровне БД. Если раньше мы могли скопировать одни и те же данные несколько раз, например, для аналитического сегмента в отдельную column-oriented БД, то сейчас это в некоторых случаях коммерчески нецелесообразно. Multi-model-функциональность появилась в PostgreSQL, Redis, MongoDB, YandexDB и других БД, что позволяет хранить разные типы данных в одной БД и использовать их в разных сценариях. Появилось много Open Source баз данных под разные задачи, которые мы не можем просто взять и разместить в Kubernetes для увеличения надежности. Для каждого такого элемента с данными нужно продумывать стратегию хранения, доступности, обработки и восстановления в случае сбоев, катастроф и атак. Не то, что это раньше не делали, но сейчас разных БД с данными различных типов становится все больше и больше.
Появилась плотная работа LLM, которая предусматривает взаимодействие с Nvidia CUDA, что, в свою очередь, требует специфической инфраструктуры. Читайте также
«Половина компаний закроется, вторую половину купят» — итоги импортозамещения в ИБ В 2022 году, после ухода большинства поставщиков, рынок информационной безопасности остался без проверенных временем решений. Однако российские вендоры получили широкие возможности для развития собственных продуктов: пустующие ниши и спрос на новые ИБ-решения.
Михаил СоколовРуководитель центра компетенций DevOps в компании ГНИВЦ