(OpenStack, VMWare vSphere JSON Template);
* Слой сети (VMWare NSX);
* Слой настройки серверов (Ansible AWX);
* Слой настройки сервисов (Hashicorp Terraform/AWS CloudFormation);
* Слой настройки контейнеров сервисов (Kubernetes/OpenShift);
* Слой маршрутизации трафика между сервисами (Istio, Envoy);
* Слой библиотек приложений (NPM для JavaScript, Maven для Java, Composer для PHP).
Взаимодействие между сервисами (маршрутизация трафика) описывается конфигурационными файлами Istio и Envoy (более тонкая настройка), которые подаются в Kubernetes и являются конфигурационными файлами Kubernetes. OpenShift предоставляет расширение Kubernetes, но и его конфигурационные файлы является нативными к Kubernetes. Сам Kubernetes настраивается с помощью YML или JSON конфигов, передающихся асинхронно. Например, конфигурационные файлы Kubernetes полностью описывают состояние контейнеров (kubectl get deployment -o yaml), разрешённый входной и выходной трафик из сервиса (kubectl get NetworkPolicy -o 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 архитектор отвечает за разрабатываемый сервис. Он подключается на самых ранних этапах согласования сервиса менеджментом, что иметь возможность повлиять на принимаемые решения в отношении этого сервиса до того, как они будут приняты. Причём, это решения не технические, а управленческие, например, сроки и бюджет. Если эти решения будут приняты без него, то архитектору придётся не решать выбор стека и типа архитектуры, а выбирать что и в какой степени он сможет реализовать. Также архитектор осуществляет надзор во время реализации архитектурных решений
