Конспект ИТ-архитектора. Евгений Сергеевич Штольц

YAML), сервисные аккаунты (kubectl get ca -o yaml), шифрование между сервисами при применении Istio (kubectl get Destination Rule -o yaml) и так далее.

      Многие облачные провайдеров, предоставляющие API к своим облакам по управления сервисами, имеют либо свои конфигурации IaaC поверх них, например, AWS CloudFormation, или интегрируются с абстракцией Terraform, под который можно разработать свой модель. Сами конфигурации описываются в декларативном виде, но на своём языке конфигураций. Но, можно получить состояние приводимое состояние системы в формате JSON:

      terraform init

      terraform plan –out tfplan.binary

      terraform show -json tfplan.binary > tfplan.json

      Ansible AWX является надстройкой над Ansible и принимает его конфигурационные файлы. Сами конфигурационные файлы пишутся в формате YAML. Ansible приводит состояние серверов из списка (в файле inventory) к описанному в конфигурационном файле. Выделение серверов в OpenStack, в какой-то мере, можно описать также в YML формате. На уровне в VMWare NSX описывает в конфигурационных файлах межсегментное взаимодействие в том же YML формате, что и другие. Если говорить о слое библиотек, то многие сборщики устанавливают и до устанавливают пакеты в соответствии с конфигурационными файлами, так NPM в NodeJS работает с JSON конфигурацией package.JSON, Composer в PHP работает также с JSON конфигурацией composer.JSON. Conda в Python использует конфигурационный файл conda.YAML в формате YAML, который однозначно преобразуется в JSON. Исключением является Maven в Java, который хранит XML конфигурацию в файле pom.xml, но, как показывает практика, преобразовать pom.xml в валидный JSON формат с помощью Python/NodeJS не составляет труда.

      Архитектор сервиса

      Архитектор сервиса или Solution архитектор отвечает за разрабатываемый сервис. Он подключается на самых ранних этапах согласования сервиса менеджментом, что иметь возможность повлиять на принимаемые решения в отношении этого сервиса до того, как они будут приняты. Причём, это решения не технические, а управленческие, например, сроки и бюджет. Если эти решения будут приняты без него, то архитектору придётся не решать выбор стека и типа архитектуры, а выбирать что и в какой степени он сможет реализовать. Также архитектор осуществляет надзор во время реализации архитектурных решений и архитектурный контроль при принятии сервиса. Обычно, архитектор сервиса сопровождает сам сервис и на приёмке, защищает архитектуру и осуществляет приёмку работы перед заказчиком на приёмочных испытаниях.

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

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