Технологический радар – это удобный инструмент, который помогает компании управлять своей платформой разработки и технологической стратегией. Мы изучили радары наших партнеров и ведущих ИТ-компаний, собрали свой и теперь хотим поделиться выводами: как радар помогает бизнесу и куда движется рынок.
Зачем создавать свой технологический радар:
Чтобы держать под контролем свои компетенции. Подготовка радара – это анализ происходящего, способ посмотреть, в какую сторону движется рынок и как общие тренды соотносится с технологиями в ваших проектах. Сразу становится понятно, где развитие компании идёт энергично, а какие темы стоит подтянуть.
Чтобы принимать правильные архитектурные решения. У команд появляется источник информации о том, какие решения рекомендуется использовать для тех или иных целей.
HR-специалистам радар помогает искать людей с нужными компетенциями, а также наглядно показывать кандидатам, с каким стеком им предстоит работать.
Другими словами, компании становится проще выстроить осознанное развитие своих технологий: концентрировать усилия на проверенных решениях, чётко понимать, зачем её сотрудникам нужно уметь работать с тем или иным сервисом и какие навыки разработчиков будут самыми ценными в ближайшей перспективе.
Как устроен технологический радар
Инструмент объединяет четыре категории: (1) техники и языки, (2) платформы и инфраструктура, (3) фреймворки и инструменты, (4) управление данными.
Каждая из этих областей делится на 4 кольца:
Adopt — технологии, которые активно используются в проектах.
Trial — технологии, которые прошли боевое тестирование и готовятся перейти в актив компании.
Assess — технологии, к которым компания ещё присматривается.
Hold — морально устаревшие технологии или решения, которые себя не оправдали на практике.
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 (менеджер репозиториев кода для хранения и распространения релизов) – как раз потому что последний обеспечивает более низкий уровень безопасности.
Заключение
Чтобы такой инструмент приносил максимальную пользу, стоит регулярно проверять свой стек технологий – хотя бы делать ежегодные срезы. Так все команды будут на одной волне, а компания будет развиваться более осознанно, не тратя ресурсы на технологии, которые не дают ей максимальной отдачи.
Если хотите создать свой радар, план действий такой:
Собрать у технологических экспертов внутри компании мнения о том, какие тенденции в данный момент играют важную роль в их сфере.
Провести инвентаризацию решений по каждому из этих направлений. Полезным может быть свериться с существующими радарами крупных компаний – многие из них публикуют свои наработки, как это сейчас делаем мы.
Выстроить структуру в формате, который вам удобен – таблица, база знаний, визуализация вроде той, которую использовали мы.
Договориться с ответственными за технологии о том, чтобы они периодически проверяли и обновляли набор продуктов по своим направлениям.
