Archimate and Kubernetes concepts mapping
I'm leading a team of DevOps in charge of application deployment, mostly on Kubernetes. I was a former software developer and Solution/EA architect so I worked on Application Views with Archi, with DevOps point of view / concerns to easier the team job.
I wanted to share to this community the choices made to match Kubernetes objects (includes docker) to Archimate model concepts (from Application layer of Technology and Physical layer).
The goal of this issue is to consolidate the mapping choices proposed for Solution Architect point of view, and for DevOps point of view
Here I share the table of matching concept. And the Google Sheet link https://docs.google.com/spreadsheets/d/1vwkXa40-TxS_2JogJvwd8W8zHp63_kQuWfzwxYBekWc/edit?usp=sharing with allowed comments for easier exchanges I hope
|
Kubernetes |
Archimate |
Archimate properties |
Outgoing relationships |
Naming conventions |
Archi model location |
Note |
| Namespace or label | Grouping or Application Component | component_type='application' | CompositionRelationship to owned pod (Application Component) | Named in capital | Stored in Archi model "Application" root folder. Each application is it's own folder with the same name as the application name. Applications folders are grouped in a domain folder (in capital). Example: Application/DOMAIN/APPNAME/APPNAME |
An application can be viewed as a system represented as a Grouping or a root Application Component. An application is not a direct concept defined in Kubernetes API, it can be reduced as a namespace, or as a of https://kubernetes.io/docs/concepts/overview/working-with-objects/common-labels/#labels, a "higher level application" can be defined as a Kubernetes label like 'app.kubernetes.io/instance' or 'app.kubernetes.io/part-of'. |
| Workload | Application Component | component_type='kubernetes-workload' | CompositionRelationship to delivered Kubernetes service (Application Interface) or used Kubernetes PVC (Application Component). TriggeringRelationship to called Kubernetes service (Application Interface) | Owning application name prefix | In owned application folder | Workload name should be based on Kubernetes metadata name or 'app.kubernetes.io/component' label. Can be a Deployment or ReplicatSet or a StatefulSet |
| Kubernetes Service | Application Interface | interface_type='kubernetes-service' | TriggeringRelationship to called Docker container (Application Component) | In owned application folder. Can be grouped in a subfolder | ||
| Kubernetes PVC | Application Component | component_type='kubernetes-pvc' | In owned application folder. Can be grouped in a subfolder | |||
| Docker Container | Application Component | component_type='docker-container' | CompositionRelationship by owned Kubernetes pod (Application Component). AssociationRelationship to used Docker image | In owned application folder. Can be grouped in a subfolder | ||
| Docker Image | System Software | software_type='docker-image' | stored in Archi model "Technology & Physical" root folder, can be grouped in subfolders hierarchy | Should be isolated in a docker-images folder, with image editor sub folders | ||
| Kubernetes Cluster | Node | node_type='kubernetes-cluster' | RealizationRelationship to hosted Kubernetes pods (Application Component). CompositionRelationship to hosted Kubernetes ingresses (Technology Interface), and Kubernetes load-balancers (Node) | stored in Archi model "Technology & Physical" root folder; Each cluster is in it's own folder with the same name as the cluster name. Can be grouped in a subfolder | Should be isolated in a kubernetes-clusters folder, with location sub folders | |
| Kubernetes Ingress | Technology Interface | interface_type='kubernetes-ingress' | TriggerRelationship to called Kubernetes service (Application Interface) | in ingresses subfolder of owned Kubernetes folder. Can be grouped in a subfolder | ||
| Kubernetes LoadBalancer | Node | node_type='kubernetes-loadbalancer' | RealizationRelationship to called Kubernetes service (Application Interface) | in nodes subfolder of owned Kubernetes folder. Can be grouped in a subfolder | Same for Kubernetes NodePort and ClusterIP |
(for following chapters, I tried to follow the Model template for this issue)
Purpose
Model and viewpoints for Solution Architects and IT staff in charge of architecture implementation "in real"
DevOps Inputs are :
- Solution Architecture
- docker images of application component delivered by Development Team in an docker registry
- related documentations
Example
On Archi based on Kubernetes BookInfo sample application from Digital Ocean & Istio
deployed in a rancher-desktop Kubernetes cluster in "bookinfo" namespace, it looks like this :
Context
A DevOps team deploy dozens of applications in dozens of environments with Kubernetes for several projects and architects struggles for updated "to be" views that the team have to implement.
Usually DevOps had to work with inputs that are :
- Outdated
- Inconsistent (Visio, DrawIO, Powerpoint)
- Unmaintained after first production launch
Model file
ArchimateKubernetesConceptMappingExample.xml (without views)