`

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

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

BEST CIO

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

Человек года

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

Продукт года

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

 

Краеугольный серверный камень

Скорый приход сетей 5G, постоянное развитие архитектуры ARM и миниатюризация специализированных решений стали причиной появления и развития очень интересной идеи в рамках краевых вычислений – Smart NIC.

Собственно ничего из выше указанного не ново, даже сами Smart NIC всегда существовали просто c более узким функционалом - разгрузка с CPU основных сервисных задач Ethernet и TCP/IP или intelligent NIC, которые умели оптимизировать более узкий функционал, например, RoCE или DPDK. Но именно сейчас, и в связи с вышеупомянутыми процессами интерес к решениям Smart NIC проявляется все более активно.

Из трёх технологии – ASIC, FPGA и SoC - самым гибким и «демократичным» вариантом является именно последний.

Решение собственной разработки Smart NIC уже несколько лет использует Amazon в своём облаке, постепенно улучшая и расширяя функционал решения. Представленные в 2013 году ASIC, снимавшие с ЦПУ только задачи, связанные с блочным хранением, доросли до Project Nitro – полноценной платы для управления сетью, блочными дисками, безопасностью и даже гипервизором.

В свою очередь VMware уже несколько лет интриговала и обещала сборку своего гипервизора на платформе ARM, и вот на недавно прошедшем VMworld это таки случилось. Портирование лидирующей платформы виртуализации на платформу ARM открывает новые горизонты абсолютно всем, а преимущества даёт огромные.

Например, AWS с помощью Project Nitro смог продавать ~30% сервера ранее зарезервированные для управления облачной платформы. Если вспомнить что у самой VMware есть NSX и VSAN – SDN и SDS решения, соответственно, то интеграция их с Smart NIC какого-либо вендора позволит существенно сэкономить конечному бизнесу на серверах и закладываемой сервисной нагрузке.

В целом, это очень интересный релиз закладывающий основу на большое будущее и реальное наступление гибридных облаков, о которых говорят уже столько лет, а главное это проложит дорогу Smart NIC к более широкому применению, а не лишь в каких-то узко специализированных нишах. Ведь до этого такие решения, по большей части, были интересны либо для NFV (классические ASIC) либо в закрытых аппаратно-программных комплексах (AWS Outpost) и мало понятны широкому классу пользователей.

Shadow of Blue Colossus

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

IBM – один из таких колоссов в мире ИТ. В итогах недели уже хорошо описана краткая история компании в контексте отсечений неперспективного или малоприбыльного бизнеса, а также неожиданные покупки наподобие Red Hat. А теперь IBM отделяет ту часть бизнеса, которая, кажется, приносит заметную прибыль на фоне постоянного падения продаж, и вроде бы даже не сильно затратная, например, по R&D.

В целом, обособление managed services бизнеса в отдельную компанию, в целом, логичный и правильный шаг по самым разным причинам, исходя из:
• Культуры компании.
• Конкуренции на рынке managed services.
• Сброса баласта.

Культура компании, основной бизнес которой это операционная поддержка, в корне отличается от таковой у той, что занимается облаками, ПО и долгосрочными R&D-проектами. Не говоря уже о циклах и методах продаж.

Рост популярности облаков, как и уровень их использования, а также недостаток профессиональных инженеров приводят к интересу заказчиков не просто к аутсорсу или аутстаффу задач по обслуживанию своего ИТ, но и к усилению конкуренции на рынке управляемых сервисов. А предложений тут на любой карман и цвет: от полного сопровождения любых инфраструктур и облаков компаниями уровня RackSpace до разработок типа EPAM Syndicate, решающих задачи по развертыванию безсерверных приложений в AWS. К тому же и сама AWS предлагает такого рода услуги, да плюс еще Microsoft, которая, как обычно, полагается на партнёров. В общем, большая поляна – большая толкучка, и скоро будет уж совсем тесно.

Принтеры, системы хранения данных, ноутбуки и пр. – все эти бизнесы в какой-то момент из перспективных и приносящих для IBM прибыль превращались в балласт по мере развития технологий и рынка, а также из-за постепенного перехода в статус общедоступного. Как пример – сервера – когда-то это был высокомаржинальный бизнес еще с нишевыми и дорогими решениями. В нынешнее время сервера перешли в разряд commodity, производители консолидированы, а не продаёт их только ленивый. Именно поэтому производство серверов x86 было отпущено, в отличие от направления мейнфреймов – хоть и узкого, но всё еще интересного и недоступного широкому кругу производителей.

С приходом Сатья Наделлы на пост CEO в 2014 году Microsoft быстро и эффективно сделала шаг в новое настоящее – облака. IBM же, в том числе и из-за гораздо большего масштаба, оказалась куда инертнее, плюс ставка была тогда на другое - на блокчейн и искусственный интеллект в купе с Watson.

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

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

Блеск и нищета маркетплейсов

Маркетплейс... Как много в этом слове. Модная, горячая тема (кажется, я поддаюсь лишь последним веяниям и уже не пишу ни о чём другом), активно муссируемая.

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

Публичный и приватный маркетплейс

Чуть меньше 10 лет назад все вендоры возбуждённо продавали разные CMP (они же Cloud Management Platform). В эпоху рассвета приватных облаков это было логичное развитие каталога продуктов, предлагаемых ИТ для тех, у кого уже, или всё ещё-таки не, наступил ITIL головного мозга. Были интересные продукты: моими любимыми экземплярами до сих пор остаются два редчайших «в дикой природе» представителя — VMware Database и Application Director. Оба, в общем, быстро и бесславно умерли так и не развившись во что-то приличное, не говоря уже о том, чтобы выполнять основные функции.

Сейчас тема приватных %рынков% приложений переживает новый рассвет — VMware купила Bitnami, но там цель более глобальная и интересная так как компания не ограничена ни платформой, ни средой исполнения (облако или On-premise). Учитывая, что у них уже есть платформа — это логичный и вполне ожидаемый шаг. Явной причиной покупки Bitnami именно сейчас были два важных момента: создание успешной облачной SaaS платформы и развитие Kubernetes.

Как и зачем marketplace

Для успешного %рынка% приложений нужны две вещи: пользователи и платформа. В целом, замкнутый круг. Пользователи идут на платформу, где есть приложения, а приложения приходят на платформу, где есть пользователи.

Задача любого marketplace — повышать средний чек от пользователя платформы, реализуя все возможные его потребности, сторонними решениями, которые, возможно, еще не предоставляются платформой. Кстати, Джефф Безос на эту тему говорил что-то вроде «all your base belong to us». Так как если кто-то из партнёров сделает решение популярное на marketplace, то зачем делиться с партнёром и почему не сделать такое решение самому?

Другой момент, когда marketplace создаётся без привязки к какой-то определённой платформе. Такие решения скорее используются на приложениях-платформах — mash up приложений эпохи web 2.0. Что было интересной концепцией, и в настоящее время фактически умерло или было поглощено основными поставщиками контента (all your base...).

Marketplace от Azure vs AWS

Из основных маркетплейсов приложений можно выделить два типа: для SaaS и для IaaS. С первыми понятно: есть, например, великий и ужасный Salesforce, в котором либо нет какого-то функционала, либо он неудобно реализован. Зачем пилить самому если можно купить не за дорого? Выгоден всем: у Salesforce повышается удовлетворение заказчиков, авторы расширений зарабатывают на подписке и у бизнеса проблема решена. Влияния на средний чек тут особого нет.

С маркетплейсами у IaaS провайдеров ситуация другая: задача внешних предложений и решений — повысить средний чек предоставив функциональность или решение, которых нет на платформе.

Два игрока на облачном рынке, у которых отличаются задачи и цели маркетплейса это Microsoft и Amazon. Причина, в первую очередь, в историческом подходе к продажам и основному целевому рынку. Amazon начинала с «непокрытого» никем рынка старпапов. Достаточно агрессивного окружения, в котором большая часть используемых решений может быть заменена, должна быть бесплатна (денег нет, чтобы платить), и часто достаточно технически развитого чтобы всё сделать самим и быстро.

Microsoft со своим Azure хотя разными способами и заигрывает с рынком старпапов, но основным направлением является enterprise. Большой и неповоротливый бизнес, имеющий самые разные legacy решения и подходы. К тому же медленно обучающийся и ограниченный разными правилами и законодательством.

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

Marketplace Kubernetes

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

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

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

Согласно классификации развития ПО нынешние продукты — это первое поколение. Видение VMware, анонсированное при покупке Bitnami (в целом крупнейшего игрока на рынке по упаковке и дистрибуции приложений) — это второе поколение. То есть гибкость и настраиваемость уходят на второй план, а на первый выходит простота и повторяемость применимая для большинства случаев.

Marketplace вендора

Самый частный и маленький рынок. Из последнего, что привлекло моё внимание это маркетплейс от Tufin. Популярного решения по управлению правилами файрволла и CMP с самообслуживанием. Данный вид рынка приложений представляет собой уже подвид третьего этпапа — квадратно-гнездового способа доставки приложений. Как пример — любой appliance или black box. Но в данном случае от конечного пользователя спрятана любая подготовительная работа и предлагается частное решение одной маленькой проблемы. По сути своей это такой локальный marketplace как у SaaS вендора.

Из всего многообразия вариантов самым интересным и динамичным в следующие несколько лет будет именно рынок вокруг Kubernetes. Так как именно с приходом данного решения на рынок и всё большим принятием K8 рынком старые проблемы возникают на новый лад и их надо как-то решать.

Накал страстей в мире Kubernetes

Уже совсем не новость, что Rancher Labs был куплен Suse. В своем первом посте в данном блоге еще в прошлом году, признаюсь, я специально несколько обострил проблему развития и, вообще, судьбы Kubernetes, что вызвало оживлённые разговоры и оживлённые беседы и обвинения автора в посягательствах на святое.

Но в действительности, как мы видим, примерно так и начинает происходить: основные игроки на рынке K8 сейчас это уже бывший Rancher Labs и Red Hat с OpenShift. Есть много нишевых игроков, хотя и крупных, типа той же VMware со своим Tanzu, но сейчас не об этом.

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

OpenShift в первую очередь PaaS: коробочный продукт предоставляющий K8 как часть общего решения. Множество разных компонентов куда K8 был добавлен по мере развития контейнерных технологий и управления ими. То есть, Kubernetes в чистом виде не ядро решения, а один из компонентов. И местами даже не совместимый с «ванильным K8».

В итоге, Kubernetes в OpenShift работает как managed service или PaaS в облаке: некоторые настройки и параметры заложены в архитектуру решения (или сервиса) вендором, и не подлежат изменению и должны приниматься во внимание при разработке архитектуры окончательного решения работающего поверх данной платформы.

Или проще говоря RedHat делает с Kubernetes то что в своё время сделала с RHEL – разрабатывает корпоративное решение с длительным сроком эксплуатации и поддержки.

Rancher Labs же предлагала совсем другой подход. Практически первородный Kubernetes, поддержка проектов из CNCF, отсутствие жёсткой привязки к другим компонентам – основные отличительные черты.

Технически и подходы к управлению ресурсами у обоих решений тоже были разные. Как и количество развёртываний. Согласно публичным цифрам около 30 тыс. у Rancher и около 3 тыс. у Red Hat. С одной стороны, пугающе большой разброс, а с другой – Azure когда-то не входил и в 5-ку облачных провайдеров. Корпоративный рынок медленный, и до сих пор не осознавший всех прелестей K8, в отличие от стартапов и технически подкованного и более динамичного бизнеса.

Консолидация рынка – один из символов зрелости и гарантированного роста. Обе компании используют K8 как инструмент для продажи основного продукта – поддержки, так как это и повышает средний чек и является новой средой исполнения. Сначала в категорию commodity перешли сервера и, что более репрезентативно, сетевое оборудование, потом гипервизоры, а теперь и ОС. Предыдущие переходы в commodity сопровождались громкими заявлениями о грядущей смерти субъекта, хотя, воз и ныне там. В данном случае всё прошло незамеченным. «Ванильный» Kubernetes умер, кажется, быстрее чем смог захватить рынок. А теперь рынок будут делить его производные и разные концепции того, каким же должен быть этот framework framework`а.

Datrium в портфеле VMware

Лет семь назад VMware начала движение в сторону облаков - то есть превращение из коробочной в сервисную компанию (это само по себе, вообще, заслуживает отдельного поста, но сейчас о другом).

Был у VMware не очень удачный опыт с vCloud Air, продукт в итоге ушёл в OVH, и есть дружба со всеми возможными игроками на рынке по созданию VMware Cloud on X. Основные мировые игроки — это, конечно, Top3 облачных провайдера, ну, и вдобавок еще Oracle с IBM, которые по своим заказчикам успешно сервисы продают.

Из основной тройки единственный случай, когда VMware сама разрабатывает и поддерживает сервис – это AWS. Что мало известно – VMware Cloud это не только IaaS, но еще и много разного SaaS. На слуху, в основном, CloudHealth позволяющий считать стоимость и оптимизировать траты на облачных провайдеров. Но кроме этого есть решения для мониторинга, безопасности, CI/CD, управления/автоматизации и т.д.

С IaaS всё просто – сделали драйвера под облачное железо, допилили технологии где надо чтобы поддерживать overlay сети, и всё. С SaaS же чуть сложнее: что-то из имеющегося либо куплено на стороне, либо внутренние продукты переделаны под Cloud Native Application. Благо опыт есть и внутренняя инициатива по разработке продуктов именно таким образом существует давно.

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

SRM даже задачу DR в облако успешно решает с минимальными изменениями. Но самая большая проблема заложена в архитектуре решения и подходе к обеспечению катастрофоустойчивости. Ее не решить декомпозицией монолита на контейнеры или разделением data, management и control plane между собой. Проблема в самом SRM.

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

Компания Datrium – один из лидеров сегмента DR, основана несколькими уважаемыми людьми, ранее работавшими в VMware и EMC, а если точнее, и важнее, то из DataDomain которую в своё время и поглотила последняя. Вообще, из бывшей команды DataDomain и RecoverPoint вышло много интересных стартапов с продуктами для резервного копирования. Преимущества Datrium в упоре на скорость, интеграцию в vSphere, для минимального управления самой платформой DR, а также возможность копировать данные в облако для долгосрочного хранения.

Недавняя покупка Datrium - логичный и правильный ход, который говорит, что VMware чётко видит своё место в будущем ИТ и четко следует стратегии достижения этого самого светлого будущего. В течении нескольких следующих лет очень интересно понаблюдать, как гигант виртуализации будет переваривать все свои покупки и превращать их в продукты, формирующие портфель сервисов. С нынешней весьма широкой линейкой как коробочных, так и SaaS решений, такие покупки и гибкость их внедрения в существующую линейку не вызывает ничего кроме интереса с толикой удивления (когда это удается).

Хайп - modus operandi современного ИТ

Мы живём в эпоху хайпа. Во всём, даже в IT. И если первопроходцы индустрии в 90-х не знали такого слова и методов продвижения, то сейчас стоит только появится какой-то перспективной теме и её уже не остановить.

Не ставлю задачу вспомнить абсолютно все хайповые технологии и подходы в ИТ, но ключевые всё-таки постараюсь.

Начну, конечно же, с двух мастодонтов – Java и Open Source. И хотя пузырь с идеей “write once – run anywhere” в реальности сдулся, Java заняла прочное место в этом мире и проинициировала так или иначе создание многих новых технологий и языков программирования. Java стала хайп-фениксом умирая уже лет 20 как. В общем, король умер, да здравствует король!

Второй титан и сейчас продолжает быть детектором, источником самых «ядерных» реакций и полем диванных битв. Надо признать, что в большинстве своём даже сами участники побоищ не в курсе всех течений и конфликтов: кто тру, а кто не GNU, «ванильное» ядро и бинарные драйвера, и так далее и тому подобное. Тысячи их!

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

И именно ПО с открытым кодом сейчас часто является источником инноваций и нововведений. Причём многие из крупных проектов ещё и написаны на всё умирающей Java. Круг замкнулся.

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

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

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

Достаточно быстро стало ясно, что от факта сбора всех возможных данных ясности не добавляется, и данные надо анализировать! На помощь пришли BI и BA – business intelligence и business analytics. Над кучей непонятных табличек надо построить dashboards которые скажут куда бежать и что делать. Чего тоже не случилось, но дало рост новым профессиям data scientist, а также вынесло Python как язык программирования на новую, недостижимую ранее высоту. Perl, как конструктор регулярных выражений, быстро упал после почти молниеносного взлёта из-за собственной сложности и того что сам является «регуляркой».

Ну что ж, раз не может человек, то сможет машина! Итак, на сцену вышла гидра AI, ML и DL. Для простоты понимания три сложные абстракции достаточно быстро схлопнулись в одну – AI. Теперь глупые человеки спрашивали умную машину, а она сама разбиралась в куче своих источников где, что и как надо собрать. Умы недалёкие пытались было протестовать, заявляя что-то про какой-то там SQL, но были выброшены на свалку как непрогрессивные.

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

Еще на заре больших данных, которые тогда не было где хранить, а потом уже и с AI, который требует огромных вычислительных ресурсов, появились облака. Действительно, зачем хранить всё у себя если можно у кого-то одного, где-то там. Код – в аутсорс, сервера и СХД – в облака. В облаках должны были быть всё и все и ещё немного. Что-то не сложилось и всё пошло не так: бизнесы не оценили, регулирующие органы сказали «Куда?!». В итоге облака действительно съели кусок от бизнеса ЦОДов, но так и не стали серебряной пулей. И хотя некоторые крупные компании (Netflix) уехали в облако полностью, некоторые (Dropbox) оттуда частично съехали так как свой ЦОД оказался дешевле.

А ведь сервер так и остался сервером. За ним надо ухаживать и смотреть чтобы ничего с ним не случилось. А в современном быстроразвивающемся мире главное это код и его разработчик. Написал – загрузил – запустил. Повторить. Ждать нельзя – надо делать. А сервер — это долго и муторно. Выход – делить не по серверам, а по ресурсам внутри ОС. А если еще подумать, то нужно нам что? Запускать код, а не сервера. А потому контейнеры, а потом и безсерверные приложения наше всё.

Правда, оказалось, что мириадами контейнеров очень сложно управлять, и архитектурных вопросов возникает больше чем ответов. Как дробить компоненты? Как обеспечить связность? API vs message queue. Вопросы безопасности возникли чуть позже – когда соответствующие специалисты пришли в себя от происшедших потрясений.

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

Венчает это всё идея Software Defined Everything – x86 стали быстрые и очень дешёвые, а аппаратно-программные комплексные решения замерли в своей дороговизне. Причём основную стоимость там составляет-таки ПО, а не железо. И именно с этой составляющей разнообразные вендоры нового поколения решили занять вотчину крупных игроков с историей. Таким образом возникли течения по убийству Cisco и EMC как символов рынка сетей и СХД. И если EMC в чистом виде ушёл на пенсию вместе с Джоном Туччи, то Cisco борется и даже представила свои решения по SDN. В целом скучная революция, быстро и тихо занявшая свою долю на рынке. И заставившая основных игроков принять новую парадигму.

Bonus: незаслуженно забытый тренд Internet of Things. Умные города всё еще в работе, но умные тостеры уже доступны. На самом деле революция прошла тихо и незаметно, но пришла не туда, где нужна – на крупные промышленные линии, а опять застряла на котиках. Крайне интересная тема, требующая отдельного и серьёзного рассказа, как и развитие IoT в мире автомобилей. Но это уже другая большая история.

NSX-T 3.0 – сети вновь на коне

Лет двадцать назад инфраструктура строилась базируясь на том, что и как скажут их Величества сетевики. Сети были краеугольным камнем любой ИТ-инфраструктуры, сложны в обслуживании и дороги (иногда безумно дороги). Они действительно были основой всего. Следом на трон взошли СХД, но сейчас не о них.

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

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

У героя этого поста – NSX-T очень интересная и сложная история. Изначально у компании Nicira, разработчика оригинального решения, было куплено решение похожее именно на NSX-T.

Тут необходимо сделать лирическое отступление: у компании VMware было две версии NSX: NSX-T и NSX-V. Первая - ориентирована на работу с KVM и OpenStack с помощью OVS и была нелюбимым ребёнком в семье. Чего не скажешь про NSX-V, которая плотно интегрировалась в vSphere, и основное развитие продукта шло именно в этой ветке. При этом два продукта были фактически параллельны и не совместимы между собой.

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

Именно с этим релизом VMware «сможет сделать то о чём так долго говорили большевики» - действительно помочь построить виртуализированную сеть независящую от оборудования. В данном случае я намеренно рассматриваю виртуальные сети в отрыве от физических как классических, так и SDN, хотя интеграция с последними весьма интересна и представлена в данном релизе с решениями от Arista.

Из всего многообразия изменений хочется особо отметить только два: NSX Federation и EVPN. Данный функционал выполняет одну и ту же функцию – взаимосвязанность ЦОД по L2 и L3, но разными методами. Для тех, кто уже мигрировал на NSX – как раз подойдёт Federation. С её помощью можно управлять несколькими инсталляциями из единого окна. При этом, наконец-то, появилась возможность не только растянуть сети между площадками без использования VPN, OTV или прочих сложностей, но и стали доступны правила брандмауэра.

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

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

Пример эффективного serverless приложения

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

Тем более, думаю, интересно было бы вспомнить успешный опыт одного крупного заказчика, с которым пришлось недавно работать. Речь шла как раз о переезде с монолита на serverless. Дано: существующее приложение для оркестрации инфраструктуры – от VMware до OpenStack. Большой монолит, много legacy, весьма широкий функционал. Проблемы очевидны: добавление новых функций сложное,  требует гору ресурсов и пр.

Бизнес принял решение - максимально отказаться от локальной инфраструктуры для запуска test&dev окружений и переехать в облако. Логично мигрировать инструменты также в облако. Однако провести это в существующем виде невыгодно и сложно – всё завязано на внутренние элементы, система не отчуждаема от своего окружения.

Вместе с тем система оркестрации не работает 24х7 и скорее является транзакционной. Как решение: рефакторинг кода и переход на безсерверную модель. Стек простой и понятный: AWS Lambda - вычисления, API Gateway – точка входа и управления вызовами к лямбда-функциям, DynamoDB – хранение данных. На момент создания решения ограничения сервиса Lambda никак не сказывались на функциональности продукта. Позже выяснилось, что для выполнения некоторых заданий, требующих сохранения состояния, Step Functions, сервис машин состояний, достаточно мало функционален и проще написать свое. Таким образом, итоговое решение могло само себя обновлять.

После переезда полностью на Lambda стоимость решения оказалась прекрасная – несколько десятков долларов на первых пять пользователей и далее по доллару в месяц на пользователя.

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

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

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

Как всегда, нужно использовать правильный инструмент под конкретную задачу.

Битва двух йокодзун

Нынешняя пандемия коронавируса вскрыла одну интересную вещь: в долгосрочной перспективе Azure явно выигрывает у AWS в корпоративном сегменте.

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

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

У Amazon, в свою очередь, совершенно другой подход к продажам и продвижению продукта – а-ля «это же облако! оно само себя продаёт!». Такая концепция может работать со стартапами и даже программистами в крупном бизнесе, но никак не с самим бизнесом.

И если раньше перевес явно не был виден невооружённым глазом, то недавний скачок на 775% в использовании Azure говорит о многом. Понятно, что это комбинированный рост вокруг Office 365 и самого Azure, но процент, тем не менее, впечатляющий. И отсутствие какого-либо ответа от Amazon, надо признать достаточно сдержанного в маркетинге цифр, весьма показателен. Дополнительным фактором и подтверждением является отсутствие сообщений или постов в интернете на тему резкого недостатка ресурсов в тех или иных зонах доступности.

Хотя самое интересное, безусловно, еще впереди: битва за проект Пентагона еще не окончена, кроме того AWS запускает новые регионы в Италии, экономически, возможно, пострадавшей больше всех и ЮАР, где у Microsoft уже есть регион.

Взгляд на 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.

 

Slack подает жалобу на Microsoft и требует антимонопольного расследования от ЕС

 
Реклама

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