and mutually convertible. There is an OPA (Open Policy Agent) project by the CNCF (Cloud Native Computing Foundation) consortium that allows you to create rules in a declarative form to check that they match JSON configurations. The check is carried out in a synchronous and asynchronous manner. For most systems, the application of changes is possible in the form of IaaC, that is, as sending new configuration files to the systems, on the basis of which the state of the systems is brought into conformity with them. In fact, the differences between them apply. This means that you do not need to check the current state of the system, but you can check the poisoned configuration files themselves. As a result, we have a configuration file for validating changes in a declarative format – GaaS (governance as a code). Let's look at a few layers to check:
* 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,
* reuse of developed components,
* dynamics of closing technical debt.
It connects at the earliest stages of service approval by management, so that it can influence decisions regarding this service before they are made. Moreover, these are not technical decisions, but managerial ones, for example, timeframes and budget. If these decisions are made without it, then the architect will not have to decide the choice of the stack and the type of architecture, but choose what and to what extent he can implement. The architect also oversees the implementation of architectural solutions and architectural control when accepting the service. Usually, the service architect accompanies the service itself and at the reception, protects the architecture and carries out the acceptance of the work before the customer at the acceptance tests.
A service architect is a role, while by position he can be a developer, a database engineer, and a business analyst and director. Usually, when a direction is being formed, this role is played by the forming director. Later, when individual services are known, he connects either technical specialists with high communication skills, or a business analyst with an assistant in the form of leading technical specialists of this service.
Most often, this role is assumed by a technical specialist, since it is practically impossible for non-technical specialists to build up a technical base so that they can descend from the upper layers of abstraction to the lowest and see technical problems and bottlenecks. It is the ability to switch between different levels of abstraction and work effectively at them that is the key skill of an architect. But technicians use their communication skills to attract technicians where they lack expertise, which technicians are not used to doing. This is going away because the technicians do not have enough resources to cover everything themselves. Out of habit, when they had one task in their professional area 1, they plunged into it to solve it, in the role of an architect, they cannot become specialists of all technical profiles and do everything themselves, there are not so many resources for this and from them this and not required – the team and the specialists involved in the project will implement it. The downside is that technical specialists, by virtue of the ability to delve into the problems of each component, can take this into account, but this is possible on small projects, on larger projects it is solved by involving experts and corporate architects practitioners for auditing, following standards, which is familiar to managers… Another difference is the understanding of business requirements, in particular in the financial area, timing and integrations. If technical specialists, as a rule, do not have problems with integrations, then non-technical ones, on the contrary, shifting them to others, they may find themselves with the fact that it is difficult to put everything together. On the other hand, if you have strict financial and timing requirements in custom development, the project can fail, since the customer can refuse it and still demand a forfeit, and due to weak communication skills – at the end of the project. It is also observed when an architect defends a project from directors, especially from a financial one, when the architect cannot justify the choice of the technology he likes, but expensive, when in this situation there are no obvious objective grounds, for example, Java instead of PHP, Oracle instead of MySQL, micro-services instead of a monolith, a self-written solution instead of a CMS for a small online store.
In general, the tasks of architecture development are the coordination of components, the choice of new technologies, the achievement of the desired result without alterations, and the simplification of acceptance. The main task for managers of architecture development is to accelerate implementation and accelerate the entry of new employees. For the customer – compliance of the implementation with the intention and in case of deviations during the development of the correction at the early stages, which reduces the cost of fixes. For developers – quick and easy implementation into the production process.
Ideally,
