Акамас спонсировал этот пост.
Во времена локальных центров обработки данных, когда циклы закупок измерялись месяцами, избыточное выделение ресурсов было логичной стратегией управления рисками — настолько распространенной, что никто не задумывался об этом.
Теоретически рост эластичных вычислительных ресурсов, предлагаемых поставщиками общедоступных облаков, должен был отвлечь нас от этого, но этого не произошло. Компании, с которыми я работал, обычно имеют избыточные ресурсы как минимум на 50 %, даже в облаке. Серверов-зомби, которые когда-то выполняли полезную работу, но больше не работают, предостаточно.
Почему избыточное выделение ресурсов в облаке сохраняется, несмотря на эластичные вычисления
Энрико Брускини, главный операционный директор поставщика платформ автономной оптимизации Akamas, считает, что знает, почему избыточное выделение ресурсов остается такой проблемой.
«Революция DevOps и рост команд платформ возложили ответственность на разработчиков. Разработчики не хотят, чтобы их будили посреди ночи, и они не хотят, чтобы их обвиняли в ненадежной настройке приложений. Поэтому они требуют избыточного выделения ресурсов», — сказал он в интервью.
«Мы наблюдаем две важные тенденции: постоянно растущее количество параметров конфигурации, вложенных в каждый уровень стека, и сокращение времени между выпусками. Из-за этого становится все труднее изучить, какой может быть правильная конфигурация. Постоянно приспосабливать ее к постоянно меняющимся потребностям просто немыслимо», — объяснил Брускини.
Правильно настроить среду выполнения, такую как виртуальная машина Java (JVM), действительно очень сложно, и уже давно сложилось так, что настройка JVM требует специальных знаний, которыми обладают лишь горстка разработчиков в типичной организации. Результатом может стать большое количество копий конфигурации.
«Кто-то в команде поднимет руку и скажет: «Я довольно много знаю о Kubernetes, JVM или Node.js; позвольте мне взглянуть», — сказал Брускини. «Они придут, что-то подправят, а затем в течение следующих нескольких лет появится супергеройская конфигурация, которую все копируют. Она становится статическим проектом, создающим приложения, которые плохо настроены по дизайну.
«Вы можете выделять столько ресурсов, сколько захотите, но если вы не настроили конфигурацию среды выполнения, вы просто увеличиваете неэффективность — и это в равной степени применимо, если вы используете Kubernetes Horizontal Pod Autoscaler», — сказал он.
Культура DevOps против надежности и оптимизации затрат
Это не просто дорого. Избыточное оборудование также вредно с точки зрения окружающей среды и представляет собой риск для надежности. Проблема усугубляется, как предположил Брускини, разными мотивами для разных команд и их заметностью.
«Мы неоднократно наблюдали с нашими клиентами разрыв между их платформой, SRE [site reliability engineering] и команды разработчиков, — сказал он. — Команда платформы оптимизирует затраты и стремится напрямую настраивать свою платформу. Команда SRE стремится снизить риск. Но обе команды имеют ограниченный охват. Они могут коснуться уровня инфраструктуры и платформы, которую они создали, но едва ли могут коснуться конфигураций рабочей нагрузки и среды выполнения, таких как размер кучи JVM, выбор сборщика мусора и т. д.; это ответственность команд разработчиков приложений».
Брускини имеет в виду разрозненность — те самые вещи, которые DevOps пытается искоренить. Трудность в том, что люди естественным образом формируются в группы вокруг четких стимулов. По словам Рассела Майлза, опытного руководителя группы платформ, работающего техническим владельцем продукта в ClearBank, это означает: «Для того, чтобы разрушить разрозненность, нужны не только энергия и намерение, но и постоянные инвестиции, чтобы гарантировать, что она останется сломанной».
Циклы обратной связи FinOps и устойчивого развития
Майлз сказал, что проблемы, связанные со стоимостью и пригодностью, следует рассматривать как расширение культуры DevOps, а не как конфликт. DevOps имеет циклы обратной связи, смоделированные по принципу «Наблюдать, ориентироваться, решать, действовать» (OODA), четырехэтапной модели принятия решений, разработанной военным стратегом Джоном Бойдом.
«Культура DevOps делает упор на обратную связь и постоянное совершенствование», — сказал Майлз в интервью. «Но в некоторых организациях он не очень хорошо работает, так это балансировать петли обратной связи, такие как устойчивость и стоимость».
Проблемы, связанные со стоимостью и пригодностью, должны быть… расширением культуры DevOps, а не конфликтом.
Циклы обратной связи FinOps и устойчивого развития часто крайне незрелы, даже в организациях, которые понимают их ценность, объяснил Майлз. При поддержке команды платформы ClearBank ввел такие показатели, как «воздействие выбросов углерода на каждую платежную транзакцию».
«Мы видим сокращение выбросов углерода, когда принимаем решения и связываем их с бизнесом», — сказал Майлз. Однако это еще рано. «В ClearBank мы видели, что вы часто сначала развиваете O в цикле OODA, поэтому, если инструмент может предоставить разработчикам части «Решить» и «Действовать», это здорово».
Устранение разрыва в оптимизации среды выполнения
Существует множество инструментов, помогающих разработчикам оптимизировать код, но Брускини видит на рынке пробел в инструменте, который может помочь в скоординированной комплексной оптимизации для повышения надежности, производительности и затрат. Это наблюдение привело к созданию платформы Akamas, которая в настоящее время имеет два модуля: Akamas Offline и Akamas Insights.
Akamas Offline предназначен для проведения того, что поставщик называет исследованиями по оптимизации, в конце нагрузочного теста. Чтобы использовать его, вы сначала определяете цель оптимизации, соглашение об уровне обслуживания (SLA) и другие границы, а затем запускаете исследование с нагрузочным тестом, генерирующим трафик.
«Инструмент предоставит различные итерации конфигурации с объяснениями, почему, а также всю необходимую конфигурацию, которую вы можете взять и применить», — сказал Брускини.
Akamas Insights, запущенная в бета-версии ранее в этом году и теперь общедоступная, представляет собой решение «Программное обеспечение как услуга» (SaaS), управляемое искусственным интеллектом, которое призвано позволить организациям легко объединить разработчиков, SRE и инженеров платформ вокруг одной цели: предоставления надежных и эффективных услуг. Это достигается путем предоставления готовых к применению конфигураций рабочей нагрузки, среды выполнения и Kubernetes для настройки всего стека на основе рабочей среды.
«Мы обращаем внимание на многочисленные возможности оптимизации, разбросанные по всему стеку», — сказал Брускини. «Модуль Insights стал результатом общения со многими корпорациями и обнаружения, что они не понимают, в чем заключаются возможности оптимизации», — добавил он.
Akamas Insights использует существующие данные наблюдения, а это означает, что установка другого агента не требуется. Поставщик строит интеграцию для каждого инструмента наблюдения отдельно. В настоящее время поддерживаются Datadog, Dynatrace и Prometheus, планируется интеграция с другими инструментами наблюдения.
Двухэтапная эволюция: от расширения возможностей к автоматизации
Долгосрочное видение поставщика представляет собой двухэтапную эволюцию, которую Брускини описал как «сначала расширяйте возможности команд, затем автоматизируйте и сократите их рабочую нагрузку».
«Мы начинаем с расширения возможностей, потому что мы устали видеть, как команды SRE или платформы гонятся за командами приложений, чтобы правильно настроить все между уровнями», — сказал он.
«Теперь SRE могут легко обнаружить ненадежные приложения и поднять PR [pull request] от Акамаса со всеми рекомендуемыми изменениями. Затем разработчики могут просмотреть и утвердить PR, легко оптимизируя весь стек, сохраняя при этом контроль».
Затем, когда команды обретут уверенность, они смогут позволить Akamas автоматизировать процесс до тех пор, пока «оптимизация не станет встроенной возможностью платформы: автоматизированной, непрерывной, а значит, легкой и всегда безопасной».
Брускини считает, что он может обеспечить непрерывную оптимизацию производства на основе искусственного интеллекта в режиме реального времени для клиентов Akamas. Технология готовится к этой реальности: размер модуля Kubernetes на месте меняется на один шаг в этом направлении.
Устранение растущего разрыва в эффективности облака
В то время как более крупные предприятия сталкиваются с конкурирующими задачами, связанными с быстрой доставкой, надежностью и оптимизацией затрат, проблема избыточного обеспечения не имеет никаких признаков решения сама по себе. Поскольку помощники по программированию с использованием искусственного интеллекта ускоряют циклы разработки, а роли инженеров по производительности отходят на второй план, разрыв между скоростью доставки приложений и эффективностью выполнения продолжает увеличиваться.
Такие инструменты, как Akamas, признают, что оптимизация больше не может быть второстепенной и полагаться на случайные «супергеройские конфигурации» — она должна быть автоматизированной, непрерывной, а значит, легкой и всегда безопасной.
Станет ли идея Брускини о непрерывной оптимизации на основе искусственного интеллекта отраслевым стандартом, еще неизвестно. Но одно ясно: эра случайного избыточного предоставления облачных ресурсов, серверов-зомби и всего остального не может продолжаться бесконечно.
ИИ Akamas с поддержкой приложений максимизирует производительность, экономию облачных технологий и надежность услуг, помогая инженерам платформ, SRE, разработчикам и инженерам по производительности работать быстрее, не нарушая работу. Узнайте больше Последние новости от Akamas ТЕНДЕНЦИОННЫЕ ИСТОРИИ YOUTUBE.COM/THENEWSTACK Технологии развиваются быстро, не пропустите ни одной серии. Подпишитесь на наш канал YouTube, чтобы смотреть все наши подкасты, интервью, демонстрации и многое другое. ПОДПИСАТЬСЯ Группа, созданная в Sketch. Чарльз Хамбл — бывший инженер-программист, архитектор и технический директор, который работал старшим руководителем и руководителем групп по технологиям и контенту. Он был главным редактором InfoQ в 2014–2020 годах и главным редактором Container Solutions в 2020–2023 годах…. Подробнее от Чарльза Хамбла
