Cloud Openstack
Hosting and Cloud Software Delivery modelled in Archimate
Introduction
I set out to define a set of good simple ready-made Hosting and Cloud models (something like this diagram below) in Archimate 3.0 notation. I decided to model Openstack in Archimate.
Even this diagram above does not really explain the Platform-as-a-Service concept of virtualised O/S components at all, using the concept of Containers as implemented by Docker and Kubernetes for example. Containers give us Scalability, Availability, implement Microservice Architecture, Deploy much quicker, etc. So I started simple and want to evolve the thinking. This is my first attempt and am happy to take comments and observations to improve it and get it stable.
On Premises Hosting Model
This is a simple Archimate Model showing the left most Column in the initial diagram above. In this model, the company is responsible for its own IT equipment at all levels. You scale, make resilient and manage.
Infrastructure-as-a-Service Hosting Model
This is a simple Archimate Model showing the second from left Column in the initial diagram, being Infrastructure-as-a-Service hosting in both on Premise and in the cloud. In this model, the company is responsible for its own IT equipment down to and including the operating system on a server (be that virtual or base metal). You scale, make resilient and manage all the items from the O/S upwards. The rest is managed and owned by the vendor.
Platform-as-a-Service Hosting Model (Standard)
This is a simple Archimate Model showing the third from left Column in the initial diagram, being Standard Platform-as-a-Service hosting in both on Premise and in the cloud. In this model, the company is responsible for its own IT Applications and Data. You scale, make resilient and manage only Applications and Data. The rest below that is managed and owned by the vendor. This includes Software Virtualisation as well as Hardware Virtualisation.
This is the Standard method that has been used and evolved for decades, however this does not cater for Containerisation. I have added a simple Containerised version of this in a later section below.
Software-as-a-Service Hosting Model
This is a simple Archimate Model showing the third from right most Column in the initial diagram, being Software-as-a-Service hosting in the cloud. In this model, the company is responsible for none of its IT, with the possible exception of End User Computing. The rest, Server side is managed and owned by the vendor. The Vendors scales, makes resilient and manages everything including Applications and Data.
Platform-as-a-Service Hosting Model (Containerised)
This is a simple Archimate Model showing the third from left Column in the initial diagram, further extended from the Standard Platform-as-a-Service to Containerised PaaS hosting in both on Premise and in the cloud. In this model, the company is responsible for its own IT Applications and Data. You scale, make resilient and manage only Applications and Data. The rest below that is managed and owned by the vendor. This includes Software Virtualisation as well as Hardware Virtualisation. It is of course made easier to manage, scale and is way more resiliant using the Containerisation concepts.
What this model does not show is any Orchestration of Containers and Pods, but this will be done in a separate blog that shows the concepts of Cloud Microservice designs looking in more depth at OpenStack, then Docker and Kubernetes.
Conclusion
The first thing I noticed, is that it is possible to model this stuff relatively easily in Archimate as above.
However I also noticed that because the various Cloud Components that make up a cloud implementation (made more visible by looking at for example the OpenStack Software) mean that there is a bluring of the lines between Infrastructure and Applications. Why do I say this? Because each module of any Cloud Component element is actually made up of a whole set of Microservices that can be described as an Application in its own right, made up of Services, Databases, Queues, etc.
Another thing to notice is that while it is relatively easy to show a static / structural view of these elements, the value and understanding of how the Containerisation works is in the Behaviour and dynamic aspects. Things like creation of Containers pulling from a public cloud registry, Orchestration and Deployment of Pods, Security Tokens, etc. Even Locations become blurred in terms of exactly where shared Object storage resides, etc. More to come.
You must be logged in to post a comment.