Как Технологический Радар Помогает Осознанному Развитию Ит-Экосистемы Предприятия

Technology Radar — это удобный инструмент, который помогает компании управлять своей платформой разработки и технологической стратегией.

Мы в True Engineering изучили радары наших партнеров и ведущих IT-компаний, составили свои и теперь хотим поделиться выводами: как радар помогает бизнесу и куда движется рынок.

Зачем создавать свой собственный технологический радар:

1. Чтобы держать свои компетенции под контролем.

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

   Сразу становится понятно, где компания активно развивается и какие темы нуждаются в доработке.

2. Принимать правильные архитектурные решения.

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

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

ценно в ближайшем будущем.

Как работает технологический радар?

Каждая из этих областей разделена на 4 кольца:

• Усыновить — технологии, которые активно используются в проектах.

• Пробный — технологии, прошедшие боевые испытания и готовящиеся стать активом компании.

• Оценивать — технологии, над которыми компания все еще присматривается.

• Держать — устаревшие технологии или решения, не оправдавшие себя на практике.

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

Три основные тенденции в сфере корпоративных ИТ-радаров 1. Распределенные облачные среды.

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

• Kubernetes и Openshift, на которых построены частные облака
• Docker и Docker Compose — хорошо известные инструменты для развертывания приложений в средах, поддерживающих контейнеризацию.

• Harbour – используется в качестве реестра Docker и для проверки контейнеров на наличие уязвимостей.

• Стек продуктов ELK для мониторинга и регистрации распределенных систем.

• Jaeger — платформа для мониторинга, отслеживания и управления транзакциями в распределенных архитектурах.

• Istio – управление трафиком и балансировка нагрузки, аутентификация и авторизация пользователей.

• KNative — платформа для создания бессерверных продуктов, позволяющая оптимизировать ресурсы и упростить эксплуатационные затраты на обслуживание (логи, мониторинг, метрики).

• Публичные облака Microsoft Azure и Google Cloud — мы используем их для случаев, когда данные могут быть отправлены в стороннюю инфраструктуру, например, для сред разработки.

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

Вторая важная задача — облегчить жизнь разработчикам, т.е.

максимально автоматизировать повторяющиеся операции и исключить ручную проверку кода.

Что мы используем для решения этих проблем:

• Azure DevOps — создание и репликация конвейеров DevOps, внедрение и распространение лучших практик разработки.

• SonarQube — статический анализ кода, проверка тестового покрытия, общей читабельности и т.д.
• Google Analytics, Google BigQuery, Grafana — инструменты аналитики и визуализации данных для отслеживания поведения пользователей и проверки рабочих гипотез.

• Kotlin для серверной части — более лаконичный и безопасный язык, чем Java.
• Подходы к разработке:
  • Непрерывная доставка
  • Разработка на основе магистральной линии
  • Флаги функций
  • Методы A/B-тестирования

Переход к распределенной облачной архитектуре меняет требования к безопасности — вокруг продукта больше невозможно построить безопасный контур; каждое приложение в системе теоретически представляет собой источник угрозы.

Требования безопасности к тому или иному микросервису существенно возрастают, а подход к поиску уязвимостей меняется и смещается на ранние этапы разработки продукта.

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

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

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

Если можно так сказать, то периметр безопасности также переживает переход от монолитной к микросервисной архитектуре.

Поскольку компания не может себе позволить использовать незащищенные технологии, тема безопасности так или иначе распространяется в поле зрения.

Например, SonarQube помогает нам проверять код на наличие базовых уязвимостей, а использование Kotlin для бэкенда снижает риск появления опасных ошибок в продукте.

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

Заключение

Таким образом, все команды будут на одной волне, и компания будет развиваться более осознанно, не тратя ресурсы на технологии, которые не дают ей максимальной отдачи.

Если вы хотите создать свой радар, план действий следующий:

1. Соберите мнения технологических экспертов внутри компании о том, какие тенденции в настоящее время играют важную роль в их области.

2. Проведите инвентаризацию решений в каждой из этих областей.

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

3. Постройте структуру в удобном для вас формате — таблица, база знаний, визуализация, подобная той, которую мы использовали.

4. Договоритесь с ответственными за технологии, чтобы они периодически пересматривали и обновляли набор продуктов в своих областях.

• Что Такое Правильное Время? Разработка Шкал Времени От Gmt До Utc И Ntp-Серверов

  19 Oct, 24

• Зачем Нанимать Разработчиков Laravel?

  19 Oct, 24

• Лекция Яндекса: Advanced Ui, Часть Вторая

  19 Oct, 24

• Окриджская Национальная Лаборатория Решила Главную Проблему Разработчиков Космических Аппаратов: Нехватку Плутония-238

  19 Oct, 24

• Путешествуйте С Google

  19 Oct, 24

• Новый Фильтр Может Спасти Владельца Model X В Случае Применения Биологического Оружия

  19 Oct, 24

• Php4 Прекращается

  19 Oct, 24

• Конгресс Сша Нанес Удар По Онлайн-Гемблингу

  19 Oct, 24

• Черная Пятница Для Хостинг-Провайдеров

  19 Oct, 24

• Как Я Подружился С Symfony2 И Vagrant

  19 Oct, 24