`

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

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

BEST CIO

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

Человек года

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

Продукт года

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

 

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

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

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

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

Чуть меньше 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.

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

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

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

Вариант первый: 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, а скорее несколько разных крупных параллельных интернетов и что будет с этим дальше не совсем пока понятно.

 
 

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