Технологический радар – это удобный инструмент, который помогает компании управлять своей платформой разработки и технологической стратегией. Мы в True Engineering изучили радары наших партнеров и ведущих ИТ-компаний, собрали свой и теперь хотим поделиться выводами: как радар помогает бизнесу и куда движется рынок. Зачем создавать свой технологический радар: Чтобы держать под контролем свои компетенции. Подготовка радара – это анализ происходящего, способ посмотреть, в какую сторону движется рынок и как общие тренды соотносится с технологиями в ваших проектах. Сразу становится понятно, где развитие      компании идёт энергично, а какие темы стоит подтянуть.  Чтобы принимать правильные архитектурные решения. У команд появляется источник информации о том, какие решения рекомендуется использовать для тех или иных целей.  HR-специалистам радар помогает искать людей с нужными компетенциями, а также наглядно показывать кандидатам, с каким стеком им предстоит работать.  Другими словами, компании становится проще выстроить осознанное развитие своих технологий: концентрировать усилия на проверенных решениях, чётко понимать, зачем её сотрудникам нужно уметь работать с тем или иным сервисом и какие навыки разработчиков будут самыми ценными в ближайшей перспективе. Инструмент объединяет четыре категории: (1) техники и языки, (2) платформы и инфраструктура, (3) фреймворки и инструменты, (4) управление данными.  Каждая из этих областей делится на 4 кольца: Adopt — технологии, которые активно используются в проектах. Trial — технологии, которые прошли боевое тестирование и готовятся перейти в актив компании. Assess — технологии, к которым компания ещё присматривается. Hold — морально устаревшие технологии или решения, которые себя не оправдали на практике. Наш радар включил в себя почти 160 технологий. По этому списку можно получить представление о том, какие технологические направления сейчас занимают наиболее заметные места на нашем ИТ-ландшафте.  Три больших тренда enterprise ИТ-радаров  1. Распределённые облачные среды. Это, разумеется, главный тренд последних нескольких лет. Монолитные продукты в прошлом – сейчас компании используют микросервисные приложения и облачные платформы, обеспечивая себе большую производительность на единицу затрат.  В этой технологической корзине у нас такие решения, как: Kubernetes и Openshift, на которых строятся частные облака Docker и Docker Compose – всем известные средства для разворачивания приложений в средах с поддержкой контейнеризации Harbor – используем в качестве Docker Registry и для проверки контейнеров на уязвимости Cтек продуктов ELK для мониторинга и логирования распределённых систем.  Jaeger - платформа для мониторинга, трассировки и управления транзакциями в распределённых      архитектурах Istio – управление трафиком и балансировки нагрузки, аутентификации и авторизации пользователей. KNative - платформа для построения Serverless-продуктов, благодаря чему удаётся оптимизировать ресурсы и упростить операционные затраты на сопровождение (логи, мониторинг, метрики). Публичные облака Microsoft Azure и Google Cloud – используем для тех случаев, когда данные можно отправлять в стороннюю инфраструктуру, например, для dev-окружений. 2. Упрощение продуктовой разработки. В эту категорию попадают технологии, которые помогают ускорить конвейер разработки, чтобы компания могла быстрее поставлять релизы, получать обратную связь от пользователей и развивать свои продукты, и всё это без потери качества. Вторая важная задача – это упрощение жизни разработчикам, т.е. максимально автоматизировать повторяющиеся операции, избавить от ручных проверок кода.  Что мы используем, чтобы решать эти задачи: Azure DevOps – создание и тиражирование DevOps-пайплайнов, внедрение и распространение лучших практик разработки. SonarQube – статический анализ кода, проверки на покрытие тестами, общую удобочитаемость и т.д. Google Analytics, Google BigQuery, Grafana – средства аналитики и визуализации данных, чтобы отслеживать поведение пользователей и проверять рабочие гипотезы Kotlin для бэкенда – более лаконичный и безопасный язык, чем Java  Подходы к разработке: Continuous Delivery Trunk Based Development Feature Flags Техники А/Б-тестирования 3. Безопасность продуктов. Сдвиг к распределенной облачной архитектуре меняет требования к безопасности – теперь нельзя выстроить защищенный контур вокруг продукта, каждое приложение внутри системы теоретически представляет собой источник угрозы. Требования к безопасности конкретного микросервиса значительно повышаются и подход к поиску уязвимостей меняется и смещается на ранние стадии разработки продукта.  Например, Docker-образы и сторонние библиотеки, которые используются и переиспользуются в продуктах нужно проверять на уязвимости, причём такие проверки следует встраивать в пайплайн, чтобы небезопасный код не мог добраться до боевого окружения.  Облачные платформы и потребность в удалённом обслуживании и удалённом подключении к рабочему месту, развитие Интернета вещей меняют подход к безопасности экосистем. Количество точек возможной атаки выросло и будет расти экспоненциально, компаниям требуется распределенный, модульный подход к обеспечению безопасности. Если можно так сказать, то периметр безопасности так же переживает переход от монолитной к микросервисной архитектуре.  Поскольку компания не может позволить себе использовать незащищённые технологии, тема безопасности так или иначе распределена по всему радару. Например, SonarQube помогает нам проверять код на базовые уязвимости, а использование Kotlin для бэкенда снижает риски, что в продукте появятся опасные ошибки. Упомянутый в первом разделе Harbor позволяет сканировать используемые контейнеры на безопасность и заменяет в нашей практике схожий инструмент Nexus (менеджер репозиториев кода для хранения и распространения релизов) – как раз потому что последний обеспечивает более низкий уровень безопасности. Чтобы такой инструмент приносил максимальную пользу, стоит регулярно проверять свой стек технологий – хотя бы делать ежегодные срезы. Так все команды будут на одной волне, а компания будет развиваться более осознанно, не тратя ресурсы на технологии, которые не дают ей максимальной отдачи.  Если хотите создать свой радар, план действий такой: Собрать у технологических экспертов внутри компании мнения о том, какие тенденции в данный момент играют важную роль в их сфере.  Провести инвентаризацию решений по каждому из этих направлений. Полезным может быть свериться с существующими радарами крупных компаний – многие из них публикуют свои наработки, как это сейчас делаем мы. Выстроить структуру в формате, который вам удобен – таблица, база знаний, визуализация вроде той, которую использовали мы. Договориться с ответственными за технологии о том, чтобы они периодически проверяли и обновляли набор продуктов по своим направлениям. Создаем цифровые продукты