Привет, я Александр Радаев, аналитик компании proCATT. В последнее время занимался вопросами переезда клиентов в облака. И постоянно сталкивался с тем, что постоянно приходилось сопоставлять сервисы различных облачных провайдеров друг с другом.

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

В России сейчас всего 3 облачных провайдера, предлагающих  облачные функции. Я расскажу, у кого что есть, и как это соотносится с сервисами общеизвестных облаков Google, Amazon и Azure.

Термин CloudOps широко распространен в западной ИТ-среде, но почти не используется в России. На Хабре, например, он всего 1 раз вскользь упоминается в статье "Кто такие DevOps". Прочитайте это краткое описание, чтобы, встретившись с CloudOps, вы сразу понимали, о чем идет речь.

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

Иностранные рейтинги ПО – хороший способ найти что-то новое и полезное. Старый  добрый американский IT-портал Infoworld каждый год публикует подборку «лучших продуктов года» в сфере разработки ПО, облачных решений, ML и обработки данных. Наверняка в него затесались «засланные казачки», проплатившие свое размещение, но есть и по-настоящему перспективные решения, о которых в Рунете еще не известно. 

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

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

Платформ на рынке значительно больше, как минимум 40, в наше сравнение попали следующие: WSO2 API Manager, Axway Amplify, Red Hat OpenShift API Management, Microsoft Azure API Management, Gravitee, Mulesoft Anypoint Platform, Tyk, Google Apigee API Management, IBM API Connect и Tibco Cloud API Management.

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

В один ненастный момент мы осознали, что без комплексного, и главное, продуманного управления несколькими десятками API, что есть в нашем ПО, всё больше времени тратим на борьбу с хаосом. Привычный Postman спасал лишь от малой толики проблем, и мы начали выбирать себе API Management платформу.

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

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

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

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

Стандартную восьмерку DevOps вы все видели, вот она.

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

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

Недавно позвонил мне старый знакомый, Павел Петрович – ИТ-директор одной окологосударственной организации, «перетереть за облака». Зная, что у них весьма консервативный подход к инфраструктуре, я был мягко говоря заинтригован. В уютной кафешке за рюмочкой кофе Петрович объяснил мне свой интерес очень просто.

«Понаберут в управляющую компанию всяких CDO, CDTO и прочих дятлов, вот они и начинают стучать в черепушку: давай проекты по цифровизации! Ёлки-палки, зайди ко мне в серверную, посмотри, на каком металлоломе там все крутится, а потом про цифровую трансформацию рассказывай! В общем, поставил нам товарищ задачу – перейти на облачную архитектуру, чтобы софт, который мы сами пишем и активно используем, был прям Cloud-Native приложениями. Ты человек в теме, объясни на пальцах, чем мне это грозит?»

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

Павел утвердительно вздохнул.

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