* Layer of virtual machines (OpenStack, VMWare vSphere JSON Template);
* Network layer (VMWare NSX);
* Server configuration layer (Ansible AWX);
* Service configuration layer (Hashicorp Terraform / AWS CloudFormation);
* Layer for configuring service containers (Kubernetes / OpenShift);
* Layer of traffic routing between services (Istio, Envoy);
* Application libraries layer (NPM for JavaScript, Maven for Java, Composer for PHP).
The interaction between services (traffic routing) is described by the Istio and Envoy configuration files (more fine-tuning), which are submitted to Kubernetes and are Kubernetes configuration files. OpenShift provides a Kubernetes extension, but its config files are Kubernetes native too. Kubernetes itself is configured using YML or JSON configs transmitted asynchronously. For example, Kubernetes configuration files fully describe the state of containers (kubectl get deployment – o yaml), allowed inbound and outbound traffic from the service (kubectl get NetworkPolicy – o YAML), service accounts (kubectl get ca – o yaml), encryption between services when applied Istio (kubectl get Destination Rule – o yaml) and so on.
Many cloud providers that provide APIs for their service management clouds either have their own IaaC configurations on top of them, such as AWS CloudFormation, or integrate with the Terraform abstraction for which you can develop your model. The configurations themselves are described in a declarative form, but in their own configuration language. But, you can get the state of the reduced system state in JSON format:
terraform init
terraform plan – out tfplan.binary
terraform show – json tfplan.binary> tfplan.json
Ansible AWX is built on top of Ansible and accepts its configuration files. The configuration files themselves are written in YAML format. Ansible converts the state of servers from the list (in the inventory file) to the one described in the configuration file. Allocation of servers in OpenStack, to some extent, can also be described in YML format. At the level in VMWare NSX describes intersegment communication in configuration files in the same YML format as others. If we talk about the library layer, then many builders install and install packages according to the configuration files, so NPM in NodeJS works with JSON configuration package.JSON, Composer in PHP also works with JSON configuration composer.JSON. Conda in Python uses the conda.YAML configuration file in YAML format, which is unambiguously converted to JSON. The exception is Maven in Java, which stores XML configuration in the pom.xml file, but, as practice shows, it is not difficult to convert pom.xml to valid JSON format using Python / NodeJS.
Solution architect
The solution architect (Solution architect, Software architect), for example, a service or system, is responsible for the detailed design of the architecture of the developed solution and its API. As part of the solution, he defines the detailed design of the solution, manages the dependencies and technical debt of the solution. His work depends on the enterprise architecture (standards), the architecture of the area in which his solution belongs, and the architecture of the platform he uses. His work is judged by:
* quality and speed of development of a detailed architecture of the service,
