What is the most correct way to show microservice infrastructure on the technical level (for example, what objects must be used for docker, docker image, docker host, host machine and etc.) ?

Hi,

This is a very generic question, so I'll attempt a generic answer. Of course, depending on your exact needs things can (and should) be stripped out and derived relationships used instead.

Here is a (certainly too) detailed approach at it:

In fact, from an ArchiMate point of view, a microservice is nothing more than a service (usually an Application Service because it contains some business logic in it), so we can model the infrastructure needed to realize this application:

• The (micro)service is realized by the Application Component (derived through an unmodelled Application Function)
• The Application Component is realized by an unmodelled Artifact assigned from a System Software (the software platform running the code, SpringBoot in my example)
• This software platform itself runs on another System Software which is the "virtual OS" inside the running container instance
• All previous things can be contained (ie. Aggregated into or realized by) an ArchiMate Node which is the most generic way to model the Docker Container
• The docker container System Software is only a running instance created by docker containerization services (Technology Service) from a docker image (Artifact)
• This service is realized by docker software running (assigned from) on a "real" OS on a "real" machine (usually physical but can also be virtual)

Regards,

JB

Thanks for so detailed answear!

And now, let's put one more delails - let's add a volume. Must it be an artifact ? And must it be placed only out of the Node, or must be a nested element of the node to link inner objects with it ?

And one more question - what about copies of the Docker container ? For example - I have one image, which generates containers on many machines distributed among customers. So, I need to draw once, but use many times the inner structure of the docker-container, which is in fact a structure of the image.

Maybe it will be more correct to draw the inner strucrure of an image, including the content, which can come from a parent image ?

added 1 deleted label

Thanks for so detailed answer!

You're welcome.

And now, let's put one more delails

First thing first: you should clarify why you want so much detail. This is clearly not the level of detail useful for typical enterprise architecture work, and thus using ArchiMate for that might not be the right thing to do.

One has to remember that it is not because something is doable with ArchiMate that it should be done.

That being said, I would change and simplify a bit the proposed example:

• The "Docker Container #1 (closed)" System Software was introduced as a replacement for the Operating System that you see at the Host level, but in fact it does not really exist because Docker uses the actual host OS.
• The Docker Image Artifact can well realize the Docker Container Node (that's very similar to an Application Component realized by an Artifact)
• In fact, I would go one step further and remove the service (which is in fact somewhat internal to the docker host and not really exposed outside) and use the exact same pattern than for a System Software assigned to an Artifact which realizes an Application Component.

All of which leads me to:

let's add a volume. Must it be an artifact ?

Yes, I would model a volume as an Artifact attached to (assigned from) the Docker host device, then Docker containers can access it.

And must it be placed only out of the Node, or must be a nested element of the node to link inner objects with it ?

It doesn't matter. In ArchiMate, nesting is just another way to present a relationship. The choice between nested or not depends only of the "communication quality" of the resulting view.

My personal preference would usually be to nest it if it is used only by one container, and keep it outside if it is (potentially) shared. In my example, I would keep it outside the container so that it works the same in all cases. I would also not represent the assignment from the Device and keep the (nested) assignment from the Docker Host Node:

what about copies of the Docker container ? For example - I have one image, which generates containers on many machines distributed among customers. So, I need to draw once, but use many times the inner structure of the docker-container, which is in fact a structure of the image.

You can of course model once the inner structure of your container (i.e. the Node content, realized applications, exposed services...). In fact, this is not at all specific to the docker technology, and a container is modeled like any other server. In such case, I would suggest to have per container image views to describe the content and inner logic of the container, such as :

And then (if really needed) simple use the container node as a kind of "black box" without its inner details in other views. In this case, instead of modelling instances of your container through different Artifacts and Nodes, I would use the same Artifact and Node shown multiple times (thus only suggesting the number of instances if it makes sens):

Such a full and detailed answear - thank you!

And my comments on more detailed schemas (excuses for it's ugly view - it'a fast drafts):

That is about how I suggest to show multiple instances and inner structure of a docker-container:

(anothe way is to put the structure directly into the artifact - but it's not allowed by standard) :)

And this is an implementation of the instances:

And another little question - why the assignment relation is directed from device to OS to docker and etc. ?

Why not the oposite direction ?

And why not to use composition (host is composed of OS, docker and etc, and docher is assigned to OS) ?

Replying to this one for the moment (the previous question needs more time that I don't have atm)

And another little question - why the assignment relation is directed from device to OS to docker and etc. ? Why not the oposite direction ?

In ArchiMate, assignment is used to model two major ideas hich are tighly related:

• A structural element is assigned to its behavior elements to indicate that the structure exibits or runs or is accountable for some behavior. So the direction is always from the structure to the behavior element.
• A structural element is assigned to another structural or (passive in the technology layer) element it stores and/or executes.

Don't be fooled by spoken langage here. In several languages (that's the case in french for example) the 'assign' verb can be used in both ways ('I'm assigned to a task' or 'a task is assigned to me' are equivalent), but the structure of ArchiMate is a bit different and strict.

And why not to use composition (host is composed of OS, docker and etc, and docher is assigned to OS) ?

Composition is allowed but for other reasons. Composition is a 'whole vs part' relationship, so it is more related to identity and lifecycle of 'things'. It's of course not false to use this relationship, but it doesn't convey the idea of something which runs something else:

• A 'Java Virtual Machine' System Software literally executes compiled bytecode, thus a 'Java Virtual Machine' System Software is assigned to a 'my-application.jar' Artifact.
• A 'Apache HTTP Server' System Software usually comes with a set of tools like 'htpasswd' to maintain a basic authentication password file. These tools are included in 'Apache HTTP Server' distribution but are not run by the server itself, thus 'Apache HTTP Server' System Software is composed of 'htpasswd' System Software.

That being said, while this is (strictly speaking) the 'right' way to model it, this doesn't mean that it doesn't make sens to simplify this a bit. In the past, while helping people to start with ArchiMate and establish a modelling capability for their team, I often decided to limit the number of different elements and relationships types to the minimum. This helps avoid inconsistencies and makes people less intimidated by the language.

Hm... But can we say, that, for example, device usually comes with an OS ? :)

From the hint of relation: "A specific kind of server can be modeled as a node composed of a device and system software"

Hm... But can we say, that, for example, device usually comes with an OS ? :)

Yes, but the device runs the OS, thus the assignment relationship. But again, you can decide that in your practice you want to simplify this a bit, it's your choice.

From the hint of relation: "A specific kind of server can be modeled as a node composed of a device and system software"

That's right too (both Device and System Software are Nodes in ArchiMate metamodel, so because a Node can be composed of other Nodes, it can be composed of Devices and System Softwares too). Not the exact same semantic, but perfectly acceptable.

Everything is a matter of compromise IMHO: when defining a pattern or a viewpoint, the first step should be to find the 'perfectly' valid modelization, then (starting from it) to gradually simplify it to meet stakeholders' needs and team's maturity. All accepted simplifications and trade-off should then be documented and shared.

And what about my suggestion with docker-containers/images specialization, and visualizing TCP/IP ports and volumes ?

According to your words, I think TCP-IP-ports, as interfaces, must be assigned to an docker-container, and OS must be assigned to a ports, because it realises/runs them... Is it right ?

This is the first docker model I saw that has been represented in Archimate. Certainly few learning points for me. So, thanks @jbsarrodie for the model

Thank you !

That is a fabulous example, clear and easy to understand, and powerful enough to be useful!

So... does that go into this repository as a template somehow?

That is a fabulous example, clear and easy to understand, and powerful enough to be useful!

Thank you

So... does that go into this repository as a template somehow?

Let's wait for more people to comment on it. I've already tagged this discussion as FAQ and at some point (if most people agree) I (or another volonteer from the community) will move this to the wiki.

Very interesting discussion indeed :)

IMO there is no right way to show .... ,rather there are different contexts where different representation may work better. For example i would not care about the docker host especially in a Cattle Service Model, where I don't really care which host runs which container. Image as well might not be of interest as we are more interested in the software that it runs when deployed. Here is how I model software stacks in general.

with docker:

no docker:

and some example with docker images used for containers that run some software:

there is another one representing a Swarm setup. The 'nodes' are actually swarm services with multiple containers within.

Cheers, K

Hm... but why are you showing Apache only on no-docker (2nd) schemam and NGINX on both 1 and 2 schemas ?

And what did you mean by using aggregation relations between docker images ?

Maybe specialization relation would be more pleasant ('cause it shows the inheritance if docker images) ? See my example above (and a part of it down here):

but why are you showing Apache only on no-docker (2nd) schemam and NGINX on both 1 and 2 schemas

they are just different architectures no relation :)

Related to the specialization I do not think it really fits here semantically. If you have speialization from a generic "docker image" to a specific one yes, but if you want to show relationships between stacks that is a completely different story. For example it could be misleading to say that Nginx is a specialization of Alpine Linux, it is just a stack on top of Alpine which in run time turns to be a different software. Imagine how would you model that, but instead of docker images you have stack of JARs for example.

@kalin I meant only the inheritance if images (not stricktly their inner structure elements). For example, Docker image A is based on openjdk:12-jdk-alpine docker image, thus, I think, "A" specializes "jdk-Alpine". And further alpnie 3.6 is inherited (specialized) by jdk-alpine.

I.e. docker image A includes all of jdk-alpine and ads NGINX :-)

As for modeling without dockers - I fully agree with you, but our discussion is about modeling with dockers :-)

hm .. there is a potential to go philosophical here :) now, specialization does not necessarily imply inheritance even in the UML generalization, which influenced the ArchiMate term.

It is true that you can say Nginx Image is a more specific than a Linux Image, however IMO that's way too 'specific'. In fact Nginx image is based/built on top of the Alpine Image. This is a clear structure dependency and in reality it actually is i.e. layers are literally built on top of each other. Images can also include more artifacts like configs, jars etc. and these also could be modelled as aggregated/composed by the image artifacts. Conceptually I use specialization to classify elements which may or may not lead to inheritance of structure and/or behaviour, but it gives a nice overview of the 'kinds' of elements. Now, if we say that Nginx image is a kind of Linux image that would not help me much. I would rather say Nginx is a kinds of RP or Web Server image. On the other hand I would like to know what are the artifacts that this image is composed of. These are 2 different perspectives.

Another point to consider is how you are going to use your model as these are not just pictures with arrows. For example if you use derivation for specialization it will not be same as if you would be more specific and use directly structure relationships.

also your statement:

docker image A includes all of jdk-alpine and ads NGINX

is clearly a structure definition a not a classification otherwise you would say :
... image A is a type of jdk-alpine ...

Again this is just a personal VP and it really depends how you use your model :)

This thread is one year old, has there been more consensus on this topic?

Also, to make the matter simpler, I'm working with Kubernetes were you have a lot more concepts than in Docker: you have "pods" that run multiple containers, you have "deployments" that control multiple pods through "replica sets", exposed through a "service", configured using "config-maps", etc.

Has anyone tackled it yet?

Hi,

I've worked a bit more on that with some colleagues since. Hopefully I'll find time in the near future to update this post (or maybe create a new one).

Regardsn

JB

Hello @jbsarrodie ! We're back again since Archi was updated according to Spec 3.2. And now the Realisation relation is not allowed between artifact and a node... So what will we do now ? Use association? Assign a docker-container (Node) to a Docker-image (Artifact)? Or change a docker container representation from Node to an Artifact too, or even a System software?

Hi,

We're back again since Archi was updated according to Spec 3.2. And now the Realisation relation is not allowed between artifact and a node...

Good catch.

A bit of background for other people reading this thread...

before ArchiMate 3.2, some "strange" relationships were allowed because most technology layer active structure elements were (in the metamodel) specializations of Node.

Because of that (and the fact that a Node can be composed of another Node), this led to things such as a System Software can be composed of a Facility, which is obviously pure nonsense. This also led to Artifact realizes Node (deduced from Artifact realizes System Software composed of Node).

ArchiMate 3.2 fixed this by changing the technology layer metamodel and explicitely adding some relationships that were still making sense (such as Material realizes Equipment)...

...but we (Open Group ArchiMate Forum Members) might have missed some of them.

An important aspect of these changes is that (since ArchiMate 3.0) Node is a very abstract active structure element which can be IT or Physical depending on the context. This changes from ArchiMate 1.x and 2.x where it was only a generic IT active structure element, which fitted perfectly the notion of "server" (encompassing hardware and software). Of course, Node can still be used to model a server, but it can also be used to model a Nuclear Power Reactor. Thus you can no longer have Artifact realizes Node because it wouldn't make sense in this context.

In some ways, maybe Node is no more the best element to model a server/container/..., and maybe Device (which can also be a virtual machine as stated here) is now a better option (but not the best one for a container, which is not an emulated hardware but more or less a way to distribute a some software).

As a matter of fact, I do think it should be possible to have an Artifact realize a Device (to model, for example, a VM image and a Virtual Machine), but that's not the case for the moment (@marclankhorst, maybe something to look at for the next version of ArchiMate).

So what will we do now ? Use association? Assign a docker-container (Node) to a Docker-image (Artifact)? Or change a docker container representation from Node to an Artifact too, or even a System software?

My personal preference would be to model (docker) containers as System Softwares realizes by Artifacts (docker images)

I'm with JB here. System Software is the best concept for modeling containers, hypervisors, and similar environments. It is originally based on UML's "Execution Environment".

Hm... In case of using System Software element - maybe it's time to change it's name to just "Software" ? And to use Specialization, to mark it as a 'System' software or 'application' software or etc. ?

P.S.: this is very sad - I must now redraw / remodel a pack of existing diagrams... even if changing the concepts types (thanks to some improvements in Archi 5) this is breaking the backward compatibility...

And another thought is about a role of a Node... if a server (physical or virtual - no matter) is a Device... so what is the difference between the Node and the Group (especially with the use of Specialization) ? Node here becomes just a structural element, that behave like a container for other elements/concepts...

It is originally based on UML's "Execution Environment".

@marclankhorst if a System Software is based on UML's "Execution Environment", than a Archimate "Device" is based on an UML "Node"... Thus - Archimate "Node" seems to be the extra element, which should be deprecated ?

even if changing the concepts types (thanks to some improvements in Archi 5) this is breaking the backward compatibility...

Not really because Artifact realizes SystemSoftware was already existing before. Of course, this is a slightly different convention than the one you had.

if a server (physical or virtual - no matter) is a Device... so what is the difference between the Node and the Group (especially with the use of Specialization) ? Node here becomes just a structural element, that behave like a container for other elements/concepts...

Grouping is a composite element and thus can compose/aggregate elements from multiple aspects (not just active structure, but also behavior and passive structure). Node is still a technology active structure element. Maybe in your practice the distinction between a physical server, a virtual server, a container... is important, but for most enterprise architecture work it is not needed. In such case it is easier to simply use a Node to represent the what that will host an application or expose some services, without having to care to much about how it will be implemented (appliance, server, container...).

if a System Software is based on UML's "Execution Environment", than a Archimate "Device" is based on an UML "Node"... Thus - Archimate "Node" seems to be the extra element, which should be deprecated ?

You only see IT here, you have to account for the physical world too. Node allows you to express that something from the technology layer must be in charge of some behavior. The added value of Node is that you don't have to decide (yet) if it is a physical thing or an IT thing. This is important for enterprise architecture, but not needed for (IT) solution architecture.

ArchiMate's Node is originally based on UML's Node, and ArchiMate's Device on UML's Device. But of course, EA tends to view things from a relatively higher abstraction level than software development. In case you do need to model the tangible reality of hardware, Device is the thing to use. If you're interested in (logical) servers, Node is the one. And for anything related to virtualization, containerization, etc., System Software works well.

mentioned in issue #72