`

Schneider Electric - Узнайте все про энергоэффективность ЦОД


СПЕЦИАЛЬНЫЕ
ПАРТНЕРЫ
ПРОЕКТА

Архив номеров

Best CIO

Определение наиболее профессиональных ИТ-управленцев, лидеров и экспертов в своих отраслях

Человек года

Кто внес наибольший вклад в развитие украинского ИТ-рынка.

Продукт года

Награды «Продукт года» еженедельника «Компьютерное обозрение» за наиболее выдающиеся ИТ-товары

 

Взгляд на Kubernetes как развитие ядра Linux

Первой публикацией в данном блоге были размышления на тему возможной смерти "ванильного" Kubernetes.

Повторю вкратце идею: архитектура K8 предполагает что это framework и, своего рода, middleware. В чистом виде этот продукт стремится к ядру Линукса - оно существует, но именно чистое ядро, не в рамках дистрибутива, мало кто видел. Об этом свидетельствует как дорожная карта продукта - выкинуть из ядра всё что не критично, и сделать модулями, так и подход разных игроков рынка.

Хороший пример изложенного тезиса: OpenShift от Red Hat — платформа построенная на базе Kubernetes, включающая в себя дополнительно набор инструментов, и изменений в сам K8 в соответствии с тем, как их видит сама компания для обеспечения безопасности, надёжности и пр. Но, в данном случае, изменения не кардинальны, и платформа является надстройкой на ОС желательно от того же вендора.

Гораздо более увлекательным и интересным является подход VMware. В рамках недавнего анонса мажорного релиза своей платформы виртуализации vSphere 7 компания анонсировала публичный релиз Project Pacific, также стали доступны технические детали реализации.

Так как изначально vSphere и весь функционал платформы заточен под виртуальные машины, а контейнеры исполняются в ОС, то Project Pacific реализовывает интерфейс оркестрации контейнеров, представляя платформе именно ВМ. Для разработчика при этом доступен ABI (Application Binary Interface) по управлению контейнерами, хотя на самом деле это специальный компонент, разработанный VMware и называемый Spherelet, а не Kubelet как оригинальный управляющий компонент.

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

В итоге, перспектива видится очень радостной, несмотря на определённую "смерть", ванильный K8 получает внимание и развитие как от конечных заказчиков так и вендоров, а вся необходимая функциональность выносится во внешние модули. На данный момент кажется, что продукт всё таки постигнет скорее судьба Linux чем OpenStack - вносят код и используют продукт все и вся, а не пишут код те немногие кто используют OpenStack в науке или продают под NFV.

Два подхода к гибридному облаку

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

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

Вариант первый: AWS Outpost. Это как раз вариант когда облако спускается на землю. AWS уже достаточно давно и плотно захватил рынок стартапов и даже приличный кусок корпоративного пирога. И если стартапы рады оставаться в облаке и расти там, то крупный бизнес часто и густо не собирается переезжать в облако по самым разным причинам - начиная от внутренней безопасности заканчивая требованиями регуляторов.

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

Другой же подход предлагает DellEMC - VMware Cloud on Dell EMC. Серверный бизнес Dell плюс бриллиант VMware в короне купленной несколько лет назад EMC позволяет собрать интегрированное решение.

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

AWS Outpost предлагает тот же фиксированный набор размеров и типов инстансов что и в облаке, тогда как DellEMC использует VxRAIL как аппаратную платформу, а программно-определяемый стек от VMware позволяет гибко управлять всеми ресурсами: приоритетами на ЦПУ, количеством IOPS и трафиком никак не ограничивая этот момент.

Каждое из решений имеет свои плюсы и минусы: t-shirt модель размеров ВМ ограничивает гибкость, но зато управление всей конфигурацией происходит только через одну панель. Гибкость в управлении требует специалиста который знает как именно настроить решение в соответствии со всеми требованиями и также требует аккуратной предварительной калькуляции ресурсов. При этом важно отметить что у решения от Dell есть возможность мигрировать ВМ вживую с локального облака в VMware Cloud будь оно запущено в AWS, Azure или у какого-либо другого поставщика.

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

Интернет сломан и что с этим делать неясно

То что глобально интернет "сломан" известно давно и ни для кого особым секретом не является.

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

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

С завидной регулярностью приходят новости о том что какие-то крупные ASN отправлены в чёрную дыру (YouTube и Пакистан). В Африке кто-то так сложил Google, ну а в апреле 17-го года сети Visa и Mastercard были анонсированы из России, и так далее.

В дополнение к таким человеческим (хочется верить) ошибкам бывают именно хакерские атаки связанные с подменой BGP. Пока таких атак немного, но их количество растёт как и опасность, которую они несут.

IETF работает над решением проблемы как может: разрабатываются дополнения и расширения к BGP для исключения ситуаций с подменой маршрутов и минимизацией возможных аварий и последствий.

В последние несколько лет появилась третья, по сути, сила - глобальные облачные провайдеры. Интернет бизнесы, будь то Facebook, Google или локальные игроки, типа Яндекса, уже давно прокладывают свои кабельные сети и строят свои CDN для оптимизации маршрутов и доставки контента. Им не важно как и откуда доставляется контент, главное быстро и качественно.

Ситуация с глобальными провайдерами другая: они не могут себе позволить падения какого-либо ЦОДа, а качество сетевого доступа должно быть как можно выше. В том числе между собственными регионами ЦОД на разных материках. Для этого прокладывается еще больше собственных кабелей, но уже не просто между материками, а между регионами на материках. И чтобы не учавствовать в войнах Tier 1 такие игроки и сами становятся своего рода провайдерами Tier 1 . Ведь, на самом деле, приличный кусок трафика облачных провайдеров остаётся внутри. Ситуация усложняется дополнительно из-за SD-WAN решений предлагаемых вендором.

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

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

customer zero

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

Самый свежий пример такой оптимизации от Microsoft. Если и раньше её обновления бывали нестабильными и глючными, что вполне еще понятно учитывая зоопарк решений который надо поддерживать, то последние релизы Windows 10, да, и обычные патчи могут спокойной добавить седин на ровном месте. Стоит отметить что глюки и нестабильность были чаще связаны с безопасностью и ошибками в работе компонентов между собой, а не риском потерять все данные как бывает сейчас.

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

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

Это мне напоминает, как достаточно давно в VMware была внедрена такая же программа. Ну а как же: в отличие от Microsoft количество аппаратного обеспечения ограничено и хорошо известно. Драйвера выпускаются либо самими вендорами серверов (привет, HPE), либо используются стандартные решения типа Intel. А задача VMware протестировать и гарантировать качество нового функционала в своём стеке продуктов. А раз так - то можно всё автоматизировать и запускать в виртуальных машинах, благое сие дело.

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

Через какое-то время когда стало понято, что новая система не работает, была представлена новая концепция - сustomer zero. Идея очень проста и в середине 90-ых была весьма популярна внутри Microsoft: eat your own dogfood или же, проще говоря, свой собственный бизнес это первый заказчик, которому надо продать какой-либо новый функционал и на ком его тестировать. Результаты были достигнуты очень быстро: оказалось собственное ИТ не обновляется на новые версии из-за проблем со стабильностью, а новые функции продукты и функции не нужные как таковые в существующем виде.

В нынешней ситуации с Microsoft остаётся только ждать когда маховик закрутиться в обратную сторону.

Количество не всегда значит качество

На Re:Invent, о котором я уже писал, был представлен ещё и десяток сервисов AWS - теперь их у компании почти 200. И среди базовых, всем и всегда нужных, баз данных, серверов и разнообразных вариантов хранения данных есть совершенно диковинные, например, БД временных рядов или QLDB на основе blockchain.

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

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

Например, Athena - такой себе Hive в браузере - у вас есть данные на S3, а в веб консоли вводятся SQL-запросы для поиска и анализа по этим данным. Очень удобно и быстро. На момент запуска, году в 2016-ом, даже интеграция с S3, на базе которого и работает сервис, оставляла желать лучшего. А интеграция с CloudWatch, сервисом для мониторинга, появилась только в начале 2019 года. То есть раньше не было реального способа отследить время исполнения запроса и выявить узкие места.

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

И так в большинстве случаев происходит со всеми сервисами: AWS выпускает, по сути, MVP который потом допиливается по мере развития и необходимости. Не сказать, что такой подход не оправдан с точки зрения бизнеса - если продукт не выстрелит, то зачем его развивать. Или вектор развития по мнению команды отличен от заказчика, что не менее важно. Тем не менее, обеспечивать изначальную интеграцию между новыми сервисами и существующими core-продуктами для повышения привлекательности и работоспособности сервиса явно что-то нужное изначально. Иначе это напоминает облачное решение от одного из производителей БД который поставив свои программно-аппаратные комплексы в свой ЦОД назвал их облаком, при этом напрочь забыв что такое облако по NIST.

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

Большой не значит успешный

Слухами земля полнится. Dell рассматривает возможность продажи RSA, а Google просчитывает варианты развития своего облака, вплоть до закрытия направления через несколько лет в случае неуспеха.

От непрофильных активов надо уметь избавляться - явно именно с этой идеей Dell подошла к  возможной продажи компании RSA, которую получила в комплекте с EMC. Даже покупка RSA в далёком 2006 вызывала вопросы, так как уже тогда компания не очень то справлялась со своим зоопарком СХД, хотя и приобретение и было направлено на диверсификацию бизнеса. Как показала история, в итоге решение не особо взлетело - портфель СХД расширялся, горизонтальной интеграции бизнеса не произошло (тут стоить напомнить что EMC также владела VMware и Pivotal, где и была явная интеграция решений), взрывного роста тоже. Увы, современная RSA уже неколько не та и не на устах у каждого, как в свое время, когда являлась по сути синонимом безопасности и шифрования.

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

Другой слух, в свою очередь менее публичный, а скорее кулуарный. Google рассматривает возможность закрытия своего облака через 3-5 лет в случае не достижения необходимых показателей в его продвижении на рынке. Признаться в таком решении также есть своя логика: рынок стартапов съеден AWS, и лидер прилагает все усилия для того чтобы ситуация не менялась."Кровавый энтерпрайз" таки ушёл в Azure в основном благодаря опыту и связям Microsoft на этом рынке. Есть еще много нишевых игроков: Oracle,которой кровь из носу нужно было предложить какое-то решение, IBM, зарабатывающая на аутсорсе, Virtustream и Rackspace играющие в своих закрытых песочницах. Сверху мелкой крошкой можно насыпать всех остальных игроков от OVH до локальных компаний-партнёров кого-то из лидеров.

С другой стороны, с технологической точки зрения ЦОДы для облака нужны совсем не такие как центры обработки данныхдля поиска. Если собственный внутренний ЦОД умрёт этого никто, вероятнее всего, не заметит. В случае падения публичного региона облака репутации будет нанесён существенный ущерб,плюс финансовые потери на возмещение убытков и все связанные расходы. При этом облачный IaaS и PaaS бизнес куда менее прибыльны по сравнению с SaaS. Чтобы догнать лидера нужны многомиллиардные инвестиции с не совсем понятной целью и результатом.

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

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

AWS Re:Invent 2019 — все важные анонсы. Часть вторая

Итак, вернемся к теме Re:Invent 2019. Во второй части, как и было обещано, основное внимание уделим программной части и разнообразным сервисам.

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

Другой многообещающий сервис, построенный с использованием ИИ — CodeGuru и анализирующий исходный код на предмет соответствия наилучшим практикам внутри Amazon, а заодно и проверяющий скорость его исполнения (благодаря функции профилировщика). Мне не совсем ясно, где тут реальное применение ИИ, а где хайп вокруг модных технологий.

NoSQL базы данных прочно заняли свое место на рынке. Год назад был представлен сервис СУБД API совместимый с MongoDB, а сейчас дело дошло и до Cassandra. Плюсом управляемых баз данных, безусловно, является отсутствие лишней нагрузки на администраторов и скорость развертывания. Причём в отличие от прошлогоднего анонса новый релиз является безсерверным решением.

Уже несколько лет происходит тихая революция, связанная с сетями. В деталях о причинах этого планирую рассказать отдельно, сейчас же остановимся на шагах, предпринимаемых AWS. Ранее был представлен набор сервисов, связанных с облегчением управления сетями и связностью VPC в разных регионах. На Re:Invent было анонсировано, что AWS Transit Gateway будет поддерживать пиринг VPC между регионами и, что особенно важно, multicast. Стоит отметить что ранее в AWS была почти религиозная борьба с multicast трафиком, и официальная позиция состояла в том, что это поддерживаться не будет никогда. В отличие от Flash vs Apple в этой битве выиграл multicast.

Весь сетевой трафик внутри VPC теперь может быть отправлен на специальный ENI подключенный к инстансу с IDS/IPS решением для анализа трафика. Теперь нет необходимости пересылать весь трафик из AWS что существенно должны сократить траты пользователей.

Также в области безопасности было представлено два новых сервиса — Detective и Fraud Detector. Второй, хоть и более узкоспециализированный сервис, призван решить насущную проблему фрода в интернете. Благо у Amazon многолетний опыт борьбы в этой сфере, и они готовы помогать своим заказчикам решать вопросы, связанные с этой специфической темой. Detective же анализирует логи и сетевую активность на предмет подозрительной или аномальной активности и позволяет найти корневую причину связанных проблем. Теперь у AWS целая плеяда решений для безопасности образующая вертикальный стек, из набора разнородных кубиков.

Обилие сервисов и слабое развитие инструментов управления и контроля привели к тому, что последние года три AWS развивает инструменты оптимизации и контроля трат. При этом новые сервисы вполне успешно могут использоваться для upsell существующих. Так, например, Compute Optimizer использует метрики и данные из CloudWatch и помогает подбирать правильные типы инстансов и необходимый размер.

А для архитекторов и инженеров будет полезен Amazon Builders’ Library — сложно сказать какой подход к предоставлению информации о лучших практиках и стандартизированных решениях, используемых разными заказчиками.

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

Из историй успеха отдельно хочется отметить индустриальное облако Volkswagen. Эта огромная корпорация выбрала именно AWS, а не Microsoft как своего облачного провайдера, а CIO группы презентовал амбициозное глобальное видение по трансформации всех процессов компании с помощью современных подходов и технологий, включая IoT, машинное обучение и пр. Это может стать таким же примерным заказчиком как в начале нулевых был Netflix.

Венцом мероприятия, конечно же, является анонс сервиса по квантовым вычислениям. Событие, невероятно обласканное профильной прессой, в целом осталось мало освещено с технической точки зрения. На данный момент доступны три вида устройств: сверхпроводящие устройства на основе вентилей Rigetti, сверхпроводящие устройства по технологии квантового отжига D-Wave и устройства на ионных ловушках IonQ. Для всех типов устройств предоставляется единый API абстрагирующий разницу в таковых у каждого решения. Для отладки и тестирования предоставляется возможность симуляции на кластере машин EC2.

Ну а так как квантовые вычисления тема новая и многие вещи требуют изучения и обработки Amazon запустили Quantum Solutions Lab для исследовательскими данными и поиска новых областей для запуска приложений.

Ну и, наконец, лично мне непонятный сервис, целью которого является то ли курьёз то ли привлечение внимания. Предыдущие годы эту задачу выполняли DeepRacer и DeepLense позволяющий создавать автономные машинки и анализировать видео. Представленный же DeepComposer позволяет создавать музыку из небольшого набора семплов используя генеративные алгоритмы ИИ. Хотя при более глубоком анализе цели и задачи становятся яснее, но об этом как-нибудь отдельно.

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

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

AWS Re:Invent 2019 - все важные анонсы. Часть первая

На днях завершилось главное мероприятие AWS за год - Re:Invent 2019. Все анонсы и стратегию хотелось бы разделить на две части: официальные презентации и личное впечатление.

Начнём с официальной части и ключевого доклада. Последние несколько лет главным спикером на конференции является Питер Де Сантис (Peter De Santis), сменивший Джеймса Хамилтона (James Hamilton), сессии которого я настоятельно рекомендую посмотреть отдельно. Но, не будем отвлекаться: замена выступающего в данном случае стоит отдельной публикации.

Питер много внимания уделил росту объемов east-west трафика - внутри ЦОД между приложениями. Контейнеры и машинное обучение, как ключевой фактор роста. От себя бы я добавил, что сервисы-кубики требуют перегонять весьма много трафика.

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

Такое длинное вступление требовалось для рассказа о Project Nitro и о том, какие преимущества даёт специализированное программно-аппаратное решение по сравнению с commodity and/or bare metal. Начали за здравие, кончили за упокой.

Надо, конечно, признать, что Project Nitro прекрасное решение необходимое для такого гипероблака, как AWS. И преимущества в его использовании есть как для заказчика - выше производительность, меньше overhead, так и для самого AWS, так как нет необходимости резервировать ресурсы на сервере для виртуализации.

Второй ключевой доклад состоялся в понедельник вечером, как всегда от Энди  Жесси (Andy Jassy), главы AWS. Первая половина доклада в целом повторяет воскресный доклад с разговорами про AI/ML, важности инноваций и самого-самого аппаратного обеспечения. Итогом стал анонс второго поколения ARM процессора Graviton 2.

На этом чипе стоит остановиться отдельно. AWS делает осторожные, но уверенные шаги в сторону эффективности энергоресурсов, закрытия аппаратной платформы и предоставления её в виде black box. Первое поколение инстансов имело индекс а1 - производная от ARM. Второе стало C6g, M6g, R6g. От compute, moderate (если я не путаю) и RAM + g как подтип. Кстати, актуальное поколение этих типов серверов 5ое, так что, возможно, с публичным выходом серверов на Graviton 2 мы увидим и новое поколение x86-серверов которые не заслужили анонса на ReInvent. Второй интересный анонс. связанный с серверами, был не особо обласкан вниманием СМИ. Новый тип инстансов inf1 оснащённый специальном чипом Inferentia опять же от AWS позволит резко увеличить выводы от AI/ML. Основная область применения - чат боты, переводчики, голосовые ассистенты и т.д. Посмотрим не повторит ли он судьбу инстансов F1 с FPGA. Хотя, учитывая усилия, которые AWS в частности и индустрия в общем прикладывают к данной теме, то не должны.

У AWS глобальная инфраструктура по всему миру - Северная Америка и Европа покрыты де-факто полностью, анонсированы регионы в Персидском Заливе и Южной Африке. Не хуже ситуация и в Азии, за исключением Океании. Каждый регион — это минимум три зоны доступности. Присутствие уже такое, что горизонтальный рост имеет мало смысла в силу стоимости инвестиций и близости регионов друг к другу. Несколько лет назад был представлен локальный регион Осака, доступный для местных заказчиков для катастрофоустойчивости в сейсмоактивном регионе. Широко доступным он не был. Особенность локального региона в том, что зоны доступности находятся в рамках одного ЦОД и часть ресурсов, например, питание, используют общие.

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

Плюсы - в близости инфраструктуры для заказчика. О краевых вычислениях говорят уже несколько лет и такой подход решение многих проблем, связанных с туманными вычислениями. Особенно в сочетании со следующим крупным анонсом - AWS Wavelength. Совместное решение с провайдерами Verizon, Vodafone, KDDI, SK Telecom когда часть инфраструктуры AWS разворачивается у операторов связи и оттуда приложение или данные доставляются напрямую через 5G к конечному устройству.

Как инфраструктура явно будет использоваться AWS Outpost вышедший в релиз. Энди Джесси на моей памяти впервые признал, что не все может уехать в облако, но для тех, кто уже активно использует AWS и хотел бы перенести эти практики в свой ЦОД собственно и предназначен Wavelength. Аппаратное решение в виде готовой стойки, управляемое через консоль AWS, но работающее на площадке у заказчика. Также поддерживается VMware Cloud on AWS. Вообще стратегия гибридного облака - ранее непримиримого врага, а теперь друга, также стоит отдельного детального изучения.

Вообще, похоже, что AWS решил расширить свою стратегию гибридного облака начав с сервиса Kendra - корпоративного поиска неструктурированных данных в Sharepoint, Dropbox и хранилищах файлов. Если мне не изменяет память, то лет 6-7 назад Google перестал продавать такое свое решение. А попытки построить поисковик по "тёмным данным" пытаются многие. По словам Энди Джесси, новый сервис будет использовать все наработки ML, обучаться и понимать суть запросов? по контексту выводить результат.

Последний анонс связанный с "железом" - AWS Nitro Enclaves. Решение по защите сверх критичных или персональных данных в защищённой выделенной среде.

Повторит ли Kubernetes судьбу Openstack?

Необходимо признать что Openstack де-факто мёртв. Громко запустившись в 2008 году при поддержке NASA и RackSpace к 2019 проект остался востребован в очень узкой нише NFV у телеком-провайдеров.

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

Если рассмотреть детальнее оба проекта, обнаружится, что у них много общего: это фреймворки с масштабируемой архитектурой на основе плагинов, сами не являющиеся инфраструктурными сервисами. «Ванилька» из коробки представляет из себя конструктор типа Lego с подходом собери сам. Конкуренция друг с другом внутренних проектов с одинаковым или похожим функционалом. Болеее менее вменяемый продукт поставляется в виде готового коммерческого продукта разными вендорами — от Red Hat до DellEMC.

Быстрое развитие, амбициозные планы по захвату вселенной и особенности, описанные выше, и привели Openstack к нынешнему состоянию.

Можно возразить что Kubernetes разрабатывается под патронатом Google (известное кладбище проектов) и массово внедряется в проектах самого разного уровня. Что все ошибки прошлого были учтены и приняты во внимание. А принятие рынком и поддержка, в свою очередь, гораздо больше и шире, чем у проекта 10-ти летней давности.

Все современные проекты пытаются решить примерно одну и туже проблему роста сложности поддержки приложений. Если посмотреть ретроспективно, то до Kubernetes был Docker, до него были CMP — Cloud Management Platform, абстрагирующие облака за единым порталом управления (кстати, изначально Openstack тоже CMP). Немного разные подходы для, в целом, одной задачи. И до сих пор нет единого успешного решения или подхода по управлению вычислительной системой, хранением и сетью. Исключением является облако IaaS как таковое, но это управляемое решение, «чей-то чужой компьютер» как выразился Эрик Шмидт, если я не путаю.

Kubernetes — прекрасное решение, закрывающее потребности, которые Docker решить не может уже при среднем масштабе. И подход с плагинами и идеей framework по своему хорош, хотя и имеет уже известные проблемы и риски.

AWS как legacy

AWS имеет самую долгую историю как публичное облако — больше 10 лет. За эти годы было выпущено около 100 сервисов покрывающих все возможные варианты использования. Вопрос насколько сильно устарели некоторые из решений предлагаемых AWS? Современные технологии развиваются очень быстро и скачкообразно, а парадигма развития open source как бизнес модели в последние годы позволила выйти на рынок очень многим интересным бесплатным продуктам.

Некоторые сервисы находятся «в форме» в силу своей простоты и незаменимости — S3 для хранения данных, виртуальные машины EC2 или шина сообщений SQS. С другой стороны — технологии которые, как оказывается при ближайшем рассмотрении, можно заменить более современными и менее затратными решениями.

Недавно я сотрудничал с одним стартапом, цель проекта — оптимизация затрат на AWS. Это была небольшая компания, владеющая крупным развлекательным сайтом. Как и положено современному бизнесу, собиралось максимально возможное количество аналитических данных с сайта и приложения. Основное долгосрочное хранение, конечно, S3. Аналитика и обработка выполнялись с помощью продвинутых сервисов AWS.

AWS Redshift — колоночная база данных для хранения и аналитики больших данных. Именно это решение в сочетании с MongoDB использовал Amazon для миграции с решений Oracle. Система, купленная много лет назад, в своей основе построена на сильно модифицированном ядре PostgreSQL 8. Имеет огромное количество инсталляций с количеством нод больше 100 и данными, исчисляемыми в сотни ПБ.

С другой стороны есть современное бесплатное open source решение написанное с нуля — ClickHouse. Изначальная задача для которой разрабатывалась БД — хранение данных сервиса Яндекс.Метрика.

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

В итоге после небольшого тестирования оказалось что кластер из 30 нод Redshift можно спокойно заменить эквивалентными 10 нодами r4 и получить прирост в производительности в несколько раз, а общую стоимость владения снизить в 3 раза.

Воодушевившись такими результатами стартап решил провести полный аудит, после которого заменил все ноды i2 на i3, что позволило снизить стоимость на 30%.

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

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

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

Лет пять назад разные поставщики продвигали идею среди заказчиков CoE — Center of Excellence, группы инициаторов и глубоко технических специалистов, которые бы решали проблему развития ИТ,миграции в облако и пр. Стартап, о котором я упоминал выше, решил раз в год собирать такую группу для аудита инфраструктуры и понимания что бы еще «выкинуть».

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

 
 
Реклама

  •  Home  •  Рынок  •  ИТ-директор  •  CloudComputing  •  Hard  •  Soft  •  Сети  •  Безопасность  •  Наука  •  IoT