Description:

architectapi 0.4

The aim of this project is to provide unified service modeling, management and
visualization platform agnostic of delivery method. It creates virtual
representations of any software services or physical resources and allows
control over their entire life-cycle. The name of project comes from Architect
program in Matrix movie series:

In the Matrix the Architect is a highly specialized, humorless program of
the machine world as well as the creator of the Matrix. As the chief
administrator of the system, he is possibly a collective manifestation, or
at the very least a virtual representation of the entire Machine
mainframe.

The The Architect project was started as part of my thesis “Visualization of
cloud performace metrics”. Now we explore the possible implications of
combining the relational models of infrastructures with quantitative data that
relates to it.
Following figure shows high-level achitecture of Architect system.



You can find installation instructions, getting started guides, and API
documentation at https://architect-api.readthedocs.io/.

Architect Components
The Architect project consists of 4 core compontents (inventory, manager,
monitor and document). A quick summary of properties, capabilities and
integrations for each component.

Inventory Component
Inventory is the Architect’s metadata engine. It encapsulates and unifies data
from various metadata sources to provide inventory metadata for various
orchestration services. Basically serves as metadata proxy with clients. It
works best integrated with http://salt-formulas.readthedocs.io/.
Currently supported metadata backends are:

salt-formulas
reclass (python3 version)

The currently supported customers of metadata provided by Inventory using
architect-api client library are:

SaltStack
Ansible
Puppet
Chef

Following orchestrators have direct support for injecting context metadata:

Heat



Manager Component
Manager is the Architect’s orchestration engine. The aim of this module is to
enforce infrastructure topologies models and acquire live infrastructure
topology data from any resource provider for further relational and
quantitative analysis and visualisations.
The pull approach for querying endpoint APIs is supported at the moment, the
processing push from target services is supported for SaltStack events.
Currently supported resource providers are:

Kubernetes clusters
OpenStack clouds
Heat templates
Amazon web services
SaltStack infrastructures
Terraform templates
Jenkins pipelines



Monitor Component
Monitor is the Architect’s monitoring engine. It can connect to multiple
data endpoints and subject them for further analysis. We can define
queries for quantitative data or time-series in Document component.
Currently supported time-series databases are:

Graphite
ElasticSearch
Prometheus
InfluxDB



Document Component
Document component is responsible for analysis and visualization of
infrastructure resources in form of directed graph. We can perform several
transformation functions on this graph data. The other part is analysis of
quantitative data provided by monitoring solutions and corellating it to the
relational structures provided by Manager component.
Currently supported relational visualization layouts:

Adjacency matrix
Arc diagram
Force-directed graph
Hierarchical edge bundling
Hive plot
Circle packing
Node-link tree (Reingold-Tilford tidy trees, dendrograms)
Partition layout (sunburst, icicle diagrams, treemaps)
Sankey diagram

Currently supported quatitative visualization layouts:

Line chart
Bar chart, stacked bar chart
Horizon chart
Donut chart, pie chart

License

For personal and professional use. You cannot resell or redistribute these repositories in their original state.

Share

• Share on Facebook
• Share on Twitter