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

Внимательный читатель заметит, что пропущен один важный этап переиспользования кода – общие библиотеки. И последствия, которые он принёс в виде DLL hell. Понадобилось без малого лет 20, чтобы минимизировать его влияние и избавиться от проблем с зависимостями.

В современном мире ситуация чуть сложнее: непонятные сторонние библиотеки превратились в открытые продукты, разрабатываемые сообществом. В итоге вместо одного чёрного ящичка с небольшим API и относительно понятными багами надо использовать целый чёрный короб собираемый целой деревней. А развитие и гегемония Linux на серверах привела к популяризации *nix way – один инструмент на одну задачу.

Но в последнее десятилетие мир сместился в сторону DevOps и ощутил значительное влияние части со стороны разработчиков на операционную (и инструментальную). Простые, кажется, инструменты стали целыми framework`ами. Всё обросло API. Конечно же, RESTful, ибо SOAP сложен, избыточен и вообще Java жаба.

Продукты, разрабатываемые сообществом (с ударением) имеют и тёмную сторону медали: сообщество определяет всё. От видения продукта до манеры общения внутри и снаружи. Некоторые продукты, достигшие критической массы и при должном желании со стороны сообщества, переходят на следующий этап развития – более зрелый и корпоративный. Примеров таких много хотя они и очень разные: Kubernetes, ядро Linux, Apache (оба варианта), Python и т. д. Туда же можно добавить CNCF как питомник, школу и акселератор.

У всех этих продуктов одно интересное общее свойство: коммерческий продукт, выпускаемый на основе открытого ПО. Мне кажется, что в момент, когда видение развития продукта переходит с этапа я (автор) или мы (ядро сообщества, скорее всего близкое автору ментально) так вижу/видим на нужды внешних пользователей, происходит слом необходимый для дальнейшего развития продукта.

Например, возьмём тот же REST API. Не существует чёткого определения или стандарта - что такое RESTful API. Есть, выработанный годами, набор практик и подходов, огромное влияние на которые оказал AWS API. С помощью него AWS решала проблему заказчиков (читай - искал способ заработать) и на его примере показала, как именно удобно реализовать инструмент для всех. Не только для себя и не для решения собственных узконаправленных задач.

Почему простые продукты становятся framework`ами? Вопрос настолько же многогранный, как и почему не все продукты-фреймворки, в итоге, успешны.

Одна из причин форки. Форки сделанные или форки несделанные. Другая - количество и избыточность технологий. Решение своей чуть отличной от стандартной задачи своим чуть другим способом.

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

В своих предсказаниях на 2021 год Вернер Фогельс, AWS CTO, написал примерно следующее: «…и настанет интернет машинного обучения. И будет оно везде и много его станет. А всё потому, что вычислительных ресурсов много ему надо. А ещё круто же! А ещё - мы активно пилим такой функционал».

Именно так: пророчество библейских масштабов объясняется тем что это дорого продаётся, и мы это активно разрабатываем. Ну как-то всё-таки не хватает больших данных. Видимо эти БД уже СБД – старые большие данные, и нужны новые. Которые мы честно и радостно соберём отовсюду.

Будем собирать фоточки полей и урожаев, аналитику на каждый чих и, конечно же, M2M и прочий IoT который вот-вот прорвёт плотину и зальёт всех миллионами таких нужных данных. Надеюсь ничего не упустил важного. Кроме, разве что, TikTok.

Несколько лет назад в западной ИТ-тусовке активно бурлили дискуссии на тему - если вы можете это сделать с SQL, то не называйте это ML. По-хорошему это правда: зачем создавать какие-то сеточки, наборы данных, арендовать кучу ресурсов, чтобы получить очевидный результат. Попахивает битком немного… Зато сколько задач и ресурсов! Пара JOIN`ов не могут стоить столько сколько стоит хороший ML, увы.

Зато есть идея для стартапа! И даже имя есть: UroBOroSS. Значит ML анализирует неструктурированные данные и генерирует SQL запросы для аналитики и корреляции данных. С sharing экономикой оценка начнётся с 9 нулей после запятой!

И хотя есть очень интересные, и главное полезные, стартапы завязанные на ML (например, поиск следов рака на флюорографии там, где человек ещё не видит в силу разных причин) не привлекают внимание (хайп всё также modus operandi современного мира) или не привлекают внимание медиа. Те, которые где-то в середине (например, определитель съедобных и не съедобных грибов - обычный ответ облачного ML что-то вроде "хрен его знает что ты там накопал - на трюфель вроде не похоже, ну его нафиг, лучше не ешь") бесполезные от слова "вообще" либо требуют сотню фоток со всех сторон и со всеми типами освещения, обещая всего через недельку родить ответ. С гарантией отличить «кота» от «собаки» в 97%.

M2M-коммуникация требует же ещё больше аналитики! Ведь если машина А едет 40км/ч, и по радио получает пакеты о том, что машины вокруг едут 30км/ч нужна, необходима сеточка! Лидар и тормоза не справятся. А прокладке между рулём и сиденьем, вообще, никакого доверия. Она же не умеет if … than в облаке считать. А банкомат? Ведь он как раньше сообщал о заканчивающейся наличке? По GSM! Ну фу же! Ну как так? А вот с M2M уже намного круче и интереснее. И GSM надо заменить на LTE как минимум. Так быстрее бумажки по воздуху летают.

Хотя на производствах это всё-таки полезно. Помню одну историю лет с 10 назад (ещё до эпохи аббревиатур из 3ёх букв) внедрение датчиков отправляющих данные в SAP (это такая немецкая вундервафля, антисмузи) позволило узнать сколько топлива водилы сливают из карьерных грузовиков на производстве и прочие приятные мелочи. Например, что кто-то ходит без каски или зашёл на закрытую в данный момент территорию. Или же вообще делает что-то опасное и против ТБ. Но это так не современно и скучно, что и вспоминать не хочется.

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

Но, вот если взять больше вычислительных ресурсов, то, наверное, всё будет быстрее. Но не точнее, для этого мало данных.

О! Ещё один стартап!

А, нет, это уже было в Silicon Valley… Или у Simpsons?..

Именно так решил Amazon сделав свой форк ElasticSearch. Компании нового поколения, зарабатывающие на OSS, сталкиваются с новыми проблемами, которых не было у их предков (типа Red Hat). А именно с апроприацией продуктов со стороны облачных провайдеров.

Интересная, в целом, ситуация в которой личные предпочтения остаются таки не на стороне облаков. Ситуация эта тянется уже достаточно долго, и начал её не ES. Ещё в 2018 году MongoDB выпустила новую лицензию собственной разработки SSPL и являющуюся изменённой AGPL 3.0.

Единственное и главное ограничение данной лицензии – если компания создаёт какой-то сервис на базе продукта она должна либо выложить все исходники, либо купить корпоративную лицензию. Проще говоря, не даёт права облачным провайдерам зарабатывать на бесплатном продукте (опционально) с открытым исходным кодом, ничего не возвращая взамен.

И началось… Часть сообщества ополчилась на это, в целом здравое решение, и сделала свою Mongo c sql и "женскими командами поддержки". OSI признала SSPL прориетарной и ограничивающей лицензией. В результате API-совместимый с MongoDB сервис БД, представленный AWS, поддерживает только версию 3.х, выпущенную при старой лицензии.

С тех пор на новую лицензии перешли менее раскрученные и известные, но достаточно популярные решения – Graylog и CockroachDB. Кстати, примерно с тем же результатом, в итоге.

Теперь вот настала очередь ElacticSearch сменить лицензию. Война между поисковым движком и облачным гигантом идёт уже достаточно давно. Сначала AWS выпустил свою бесплатную и открытую версию расширения для ES, которую сам разработчик продаёт в рамках enterprise лицензии. Elastic не нашёл варианта лучше, как сменить лицензию на все свои продукты, на что AWS и объявил о создании своего форка.

Шаг, со стороны AWS, весьма логичный – управляемый сервис ES даёт отличную добавочную стоимость к обычному EC2 и продаётся как горячие пирожки. Поэтому в отличие от сервиса с MongoDB нельзя просто, например, отложить выпуск сервиса и переделать его с нуля. Никто не будет рубить голову курице, несущей золотые яйца.

Интересно каковы будут последствия для каждого из игроков. Думаю, что в реальности AWS будет развивать свою ветку и добавлять функции, связанные именно с поиском, тогда как Elastic будет и дальше развивать опции по безопасности. И напрямую продукты особо конкурировать не будут.

Но в данном случае важен именно случай, прецедент. И я не исключаю что война бобра с ослом ещё не окончена и скоро мы увидим новые «серии».

На прошлой неделе горел один из ЦОДов OVH. В ИТ-сообществе «горело» ещё ярче, чем у OVH. Мнения были разные: некоторые вспоминали слова из песни БГ о так и не пришедшем подкреплении, другие - хоронили облака/OVH/"всех и сразу".

Самые трезвые головы вспоминали слова Эрика Шмидта (вроде бы) что облака — это просто чей-то чужой компьютер. И особо не важно находится он в чужом же ЦОД или собственном: горит и тонет всё. А еще - отключается питание, интернет и пр.

Можно сказать, что имело место сразу два события в прошлую среду: одно для OVH и другое для Европы. С первым понятно, а вторая вступила в клуб. Облака «падали» в Австралии (несколько раз уже) и в Штатах. Крупных сверх ЦОД в других регионах особо нет, вот мы и не знаем о таких случаях. Плюс всё что далеко - не так интересно.

Все привыкли к отключениям AWS и Azure, у Google периодически тоже что-то ломается, про утекшие BGP-маршруты в приличном обществе, вообще, вспоминать - моветон. Повседневность же!

Архитекторы и специалисты по ИТ также извергали возмущение насчет дизайна и всего проекта ЦОД у OVH. Там, мол модульные конструкции и пожароопасные решения. В общем, всё плохо. Некоторые провайдеры тут же заявили, что у нас ЦОДы в огне не горят, и в воде не тонут. Раз таких аварий не было, то обратное не доказано.

А еще зачем-то целых 4 зоны доступности или суб-ЦОДа были размещены физически на одной площадке! Моветон в высшей степени. Правда есть два момента: Azure начинал с регионов, которые были физически в одном ЦОД и, опционально, с общим питанием и сетью, а AWS делает так сейчас со своими Local Region.

Вспоминается ситуация у давнего заказчика, который выбирал облако для запуска managed DB и у одного провайдера был multi AZ дизайн, а у второго - выше SLA, но нету multi AZ. Сопровождался выбор длительными обсуждениями что же лучше и важнее…

Падает всё и все, и никакие облака это не изменят. AWS во всех своих руководствах и рекомендациях говорит о том что сервис должен быть спроектирован с учётом того, что нижележащая облачная инфраструктура может упасть. Двадцать лет назад люди делились на тех, кто делает бекапы и тех, кто нет (с тех пор, правда, ничего особо не изменилось). Надеюсь, что этот случай научит хранить копии в другом месте. Например, тот же Veeam чуть ли не с самого начала говорит о правиле 3-2-1 (три копии, два медиа, одна копия на другой площадке). Современные технологии делают этот процесс ещё проще чем 5 или 10 лет назад.

P.S. немного повангую что кто-то из поставщиков управляемых сервисов будет предоставлять услугу аудита/гарантирования сохранности данных удалённо на случай таких аварий.

В прошлой заметке я упоминал сервера HPE на платформе ARM, которые через пару лет после анонса, без особой огласки, переехали на х86. А ведь такие чипы и сервера на них производили многие компании. Почему же основные игроки свернули такое производство и почему ARM оказался востребован в серверных системах основных провайдеров облаков?

Итак, к середине 2010-ых cloud native application вполне оформились в своей архитектуре. Появились решения, неиспользуемые особо в классических приложениях: Redis, ElasticSearch и шины сообщений. Приложения очень сильно сместились в сторону веба и горизонтального масштабирования.

Именно веб и горизонтальное масштабирование — зона интереса применения ARM в серверах. К моменту начала из использования в таких задачах — достаточно маломощные ЦПУ, но и потребляющие мало энергии. Самое оно для серверов с низкой нагрузкой типа веб, или для модного тогда MapReduce, или даже для обработки IoT. В общем, всех тех приложений, которые могут не загружать ЦПУ на 100%, и там где, количество иногда важнее качества.

Но рыночек, как всегда, порешал по другому. Для начала мало кому из крупных заказчиков были нужны ARM сервера в собственном владении для вышеозначенных задач, когда есть облака. Второй момент производительность — её таки оказалось мало. Ну а добила весьма слабая поддержка со стороны ПО. Если Linux ещё мог стать и работать, то большая часть прикладного софта либо не поддерживала платформу, либо не использовала возможности и особенности ЦПУ (непонятно что хуже).

В итоге прекрасное ARM-будущее оказалось никому не нужны в массовых серверах. Но ARM Holding, как разработчика, мало волновали такие мелочи и они смотрели в свое собственное светлое будущее, которое можно разделить на две части: облака и решения около 5G.

Amazon не зря в начале 2015 года покупает Anapurna Labs — разработчика ARM-процессоров. В масштабах облака переход на энергоэффективную платформу собственного приготовления позволит сэкономить миллиард-другой в год.

Самый крупный и яркий пример — Project Nitro. Программно-аппаратное решение которое позволило вынести на отдельную плату все операции связанные с виртуализацией и управлением облачных серверов. То есть если раньше примерно 1/3 сервера была зарезервирована на сервисную нагрузку, то теперь 100% можно продать.

Во-вторых, есть много SaaS и PaaS сервисов: DynamoDB, S3, SQS и т.д. которые можно перевести на новую платформу. Выгоду из этого можно привести самую наглядную: Apple со своими M1 и A14 в телефонах добавляет в процессор блоки оптимизированные под определённые задачи. А если точнее, то целый сопроцессор, но уже встроенный. Таким образом старая идея обретает новую жизнь!

В результате Amazon, Microsoft (которая разрабатывает свой чип на ARM), как владельцы платформы, получают специализированное решение оптимизированное под свои нужды. Примерно как IBM «пилит» процессоры оптимизированные под свои мэйнфреймы, а не использует ЦПУ общего назначения от Intel (ну, почти).

Если ARM в облаках это уже реалии сегодняшнего дня, то есть еще ниша из будущего: маломощные и встраиваемые сервера для 5G, SmartNIC и краевые вычисления. Эта область применения оценит нетребовательность платформы и расширяемость под задачи. С распространением 5G и постепенным расширением умного всего и сами приложения станут ближе к источникам данных. Интернет вещей пока так и не стал повседневной реальностью, но у него появился промежуточный этап — «туман вещей». И именно он должен стать вычислительной мощью всех датчиков и измерителей. А ещё будут умные машины — сейчас моделей с поддержкой M2M немного, но концепция выходит на рынок.

Таким образом, Intel никуда не денется и не умрёт, а скорее сама выпустит свой ARM-чип (снова). И будет работать над тем чтобы х86 мог подвинуть на новом рынке растущего гегемона. В серверах же и компьютерах ARM явно останется ускоспециализированным решением: бизнес ноутбуки, ультрабуки и прочее. Microsoft обеспечит платформу поддержкой со стороны ОС и основным ПО, а вот поддержат ли инициативу игроки типа Adobe, Corel, Autodesk выпускающие весьма требовательное ПО — ещё отдельный вопрос который так же будет иметь существенное влияние на развитие ARM как платформы для компьютеров. Последним оплотом тогда останутся игры, но я совсем не удивлюсь если Unreal Engine в ближайшие пару лет также освоит и новую платформу...

В любом случае остаётся только ждать поддержат ли инициативу производители серверов и каким будет «ответ Чемберлену» от Intel.

В связи с выходом Apple M1 не высказался только ленивый. Процессоры сфотографировали в рентгене со всех сторон, померяли производительность во всех возможных сценариях и даже слили информацию об обновлении чудо процессора. И, конечно же, опять похоронили х86 как архитектуру.

Последним гробовщиком х86 из мира ARM, не считая AWS с инстансами a1, был HPE со своим Moonshot Project, который, правда, плавно съехал с этой темы, вернувшись на традиционные платформы.

Такое впечатление, что современные похоронщики х86 не знакомы с "кратким курсом истории". Борьба между x86 и RISC уже один раз состоялась. И хотя в той битве RISC, в итоге, таки проиграл из-за особенностей своей архитектуры, обе платформы за прошедшие годы существенно видоизменились, интегрировав в себя лучшие стороны конкурента.

Дошло даже до того что считается что х86 процессоры теперь по сути RISC`овые. Ну хоть не совсем наоборот.

Что ещё более важно – абсолютно не учитывается контекст и развитие в ИТ как за прошедшие годы, так и уход прибыли с рынка ПК в серверно-облачный.

Рынок «персоналок» абсолютно потерял своё былое влияние: вектор развития процессорных технологий уже задают даже не сервера, а именно облака. Во-вторых, по сравнению с 80-ми, рынок решений стал намного шире. ARM может захватить тот сегмент, на котором просто нет места прожорливым ЦПУ:  IoT, машины, встраиваемые устройства т.д. Огромная область, где количество устройств в десятки раз больше, чем за всю историю продаж Intel.

И ещё один немаловажный момент: другие процессорные архитектуры и типы процессоров, с которыми придётся бороться ARM: MIPS и RISC V. А есть еще и специализированные решения типа ASIC и FPGA, которым также придётся противостоять на рынке smart NIC. В общем, покой нам только снится.

Именно с такой идеей маховик государственной антимонопольной системы США раскручивается уже несколько лет, и, наконец, достиг финальной фазы - обращения в суд.

В 90-ые монстром который всех давил была Microsoft, за что и получила, и весьма, на то время, сильно. Сейчас же это целый клубок - FAANG. Пока что недовольство у власть имущих вызывают два молодца из пятёрки богатырей - Facebook и Google.

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

У Google и Facebook есть одна общая черта - монополия и агрессивность. Google и постарше будет, уже менее агрессивный и более аккуратный игрок на рынке, больше занятый улучшением предложения чем созданием и захватом новых "полянок". Facebook же в отличие от старшего собрата, является компанией одного человека, и активно покупает конкурентов, возможных Кроносов.

Рекламных сетей и игроков на рынке - вагон и маленькая тележка. Большинство сайтов зарабатывает не только на рекламе от Google, но ещё и, как минимум, от одного-двух конкурентов. Тогда как Instagram и WhatsApp равноценной замены так и нет. Google достаточно мягко (как для такого колосса) и нежно заставляет использовать свои рекламные продукты, Facebook же просто засасывает, как в чёрную дыру всю доступную информацию и используют любую возможность для увеличения количества времени, которое пользователи проводят в эко-системе продуктов компании. А это, отчасти, приводит к той сегментации интернета на интернетЫ, о которой уже много лет предупреждают и волнуются "лучшие умы человечества".

Но не стоит забывать что у FB, как и у всенародного поисковика, основной источник заработка реклама. И гиганты заключили совместное тайное соглашение по которому компания Цукерберга получает преференции в рекламе, и за это не давит Google.

Но бог с ней с рекламой как таковой. Ведь её надо доставлять как-то. И если с социальной сетью всё понятно, то у Google есть ещё один туз в кармане - Android. Официально свободная и бесплатная мобильная ОС (за исключением некоторых нюансов) установленная на миллиардах самых разнообразных устройств - от телефонов и планшетов до NAS и IoT девайсов. А еще есть Chrome построенный на бесплатном и свободном (см. выше) браузерном движке. Фабрики по сбору персональных данных, анализу и улучшению таргетинга рекламы. Прекрасная в своей полноте экосистема!

Именно вот эта комплексность и присутствие Google и Facebook во всех сферах, умноженные на популярность продуктов, которые не являются core, и сподвигают к разделению компаний. Вернуть, так сказать, конкуренцию на рынок.

Их оставшихся гигантов - Amazon, Apple и Netflix - пока не очень понятно, что делать только с последними двумя. Разделить Amazon на "запчасти" требовали крупные инвестиционные компании еще несколько лет назад. Ведь в короне Безоса бриллиант только - Amazon Web Services. Все остальные бизнесы (за исключением разве, что рекламы) существуют благодаря облаку, да и растут тоже.

По мнению тех же инвесторов выделение облачного бизнеса Amazon в отдельный только повысило бы его стоимость на рынке, и укрепило бы акции ритейл-бизнеса. Ситуация с Netflix и Apple немного сложнее.

Самый главный грех Apple, на данный момент - уход от налогов. А в своих попытках задобрить правительство США компания даже вернула часть производства из Китая на родину, и обещала увеличить объём производства там. Хотя не исключаю что история с монополией магазина приложений таки получит продолжение в ближайшие годы.

Netflix пока кажется самым безобидной из упомянутой троицы: развивается себе мирно, никого не поглощает, конкурентов много и растут как на дрожжах. С другой стороны эти же конкуренты и могут форсировать антимонопольное расследование против гиганта стриминга, как Oracle проталкивала дело против Google. И дело не в мести за Java, а в конкуренции на рынке маркетинга и рекламы, хотя казалось бы компании особо и не конкуренты там.

В недавней истории были уже два интересных и показательных дела против крупных монополий: AT&T и Microsoft. Они интересны тем, что очень хорошо позволяют соотнести нынешних гигантов к тому или иному судебному иску и оценить вероятные последствия. Если смотреть исключительно бинарно, то Facebook, Google и Amazon это "AT&T", тогда как Netflix и Apple скорее подобны "Microsoft" времен Гейтса. В общем, в следующие несколько лет будет очень интересно понаблюдать за развитием ситуации как с существующими исками, так и новыми. А также за возможными законодательными инициативами, которые могут последовать в результате выводов и судебных решений.

Конец года – время подведения итогов. На днях Максим Агеев (весьма уважаемый человек) опубликовал своё видение итогов года, на что с ним не очень согласился Владимир Поздняков (другой очень уважаемый человек) и выразил свои сомнения. В силу возраста и дерзости позволю себе не согласиться как с одним, так и с другим.

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

Именно из этих двух нюансов возникает коллизия. Для начала - не все локальные компании платят локально плюс многие из крупных компаний, вообще, не привлекают к себе публичного внимания. Так, например, один из моих заказчиков входил в Top3 приложений AppStore в США и даже Google Play (тут могу ошибаться), а сам находился в прекрасном провинциальном городе СНГ. Или, другой пример — Ring, компания родом из Украины платила в Amazon напрямую никто и не знал особо об этом до тех пор, пока гигант электронной коммерции ее же и не купил.

Поэтому на вопрос - кто же занимает призовые места облачного рынка? Azure, AWS, De Novo, GCP или GigaCloud? Ответ зависит от того как мерять. У Microsoft с Azure, действительно, сильные каналы продаж, многолетний опыт, гибкость ценообразования и пр. Бонусом можно отметиться запихивание облака в EA. С такой точки зрения это битва двух титанов – Azure и De Novo. Платят, конечно же, в Украине так как основной бизнес здесь же. Легко оценить и посчитать, так как названия публичны, пресс-релизы популярны.

Можно посмотреть с другой стороны: аутсорсеры, гейминг-индустрия (особенно всякого casualware, очень интересная тема и рынок, кстати), стартапы и теневые ИТ-компании упомянутые выше. Те самые смузихлёберы в модных офисах. В большинстве своём ненавидят Azure за технические моменты (API меняется как, в своё время, WinAPI) и дружно сидят в AWS и GCP. Про De Novo, GigaCloud и прочих местных игроков они даже не слышали. Всех кто старше 30 считают мастодонтами, тихо ползущими в сторону ближайшего погоста. В большинстве своём платят не в Украине. Оценить примерно невозможно – пойди их всех в тумане найди. Публичные user case не популярны. В итоге сумма их трат на облако +/- ∞.

Есть еще сами вендоры. Пока остановимся на большой тройке. Azure работает с упором на большой бизнес и много вкладывает в евангелизацию среди молодёжи – всё без изменений. GCP – молодой и дерзкий. В чём-то самый лучший, а в чём-то наоборот. Когда понимаешь зачем и почему – лучшего решения нет. Если не знаешь и не понимаешь – пресейлы и сейлы быстро объяснят о качестве каналов связи даже в Украине, внутренних сервисах выросших во внешние продукты и лишат остатков сомнений. И только AWS тихой сапой не привлекая внимания пылесосит рынок обращая внимание своих сейлов только на перспективных и платящих заказчиков.

А завершить можно решениями cloud managed services от HPE, IBM и SaaS от компаний типа SAP, SalesForce и подобных, которых Максим Агеев вежливо упустил в своем обзоре. И хотя мне сложно оценить доходы SaaS-гигантов на украинском рынке в первую очередь из-за низкой доли в общем заработке, но HPE и IBM, как основные игроки, прекрасно себя чувствуют – стоит вспомнить про переезд ДТЭК в облако HPE или многолетний контракт IBM с Укрсоцбанком (правда, ныне почивший в бозе). Решения SAP поставляемые из облака это вообще подарок судьбы в силу сложности и длительности внедрения. Итого, SaaS и managed services еще один отдельный кусок пирога, который стоит рассматривать в рамках целой картины. Суть одна - забираем вашу функцию себе и предлагаем абстракцию какой-то части ИТ-процессов или всего процесса/приложения целиком.

Кто-то из авторов выразил разумную мысль о том что AWS, Azure, GCP в современных условиях это cloud 2.0, а HPE, IBM - 1.0. Очень хорошая и здравая мысль. Но есть один нюанс: с технической точки зрения они отличаются только интерфейсом управления и изменениями, которые необходимо внести в архитектуру приложений и инфраструктуры. Ведь главное в облаке, со стороны заказчика, это гибкость, а со стороны вендора - грамотное управление ресурсами ЦОД.

Учитывая данную мысль можно вспомнить про сервис VMware Cloud on AWS и его братьев в других облаках. С одной стороны это облако 2.0 - гибкость, скорость выделения ресурсов, и прочее. С другой это же именно 1.0 - что может быть привычнее стека VMware, управление и поддержку которому она же и оказывает, а запущено оно, для разнообразия, в AWS. Пока не вспоминаем про AWS Outpost...

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

Скорый приход сетей 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 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 делает неожиданный шаг, а трансформация начавшаяся декаду назад еще, похоже продлится столько же, не меньше.