Previous

This blog on Openstack modelled using Archimate follows on from the previous Blog on Hosting and Cloud software delivery modelled in Archimate.

Introduction

One of the first things that struck me about the OpenStack cloud software was its naming of elements by the Project names they were/are developed under, which makes it a bit harder to learn, because you not only have to learn the name but also mentally map it to the functionality it provides. So one of the reasons for this blog was to model OpenStack, both to help me learn and understand it but also share the models at the same time.

The second thing that struck me was how well it conforms to the Microservices architectural style, with smallish isolated Applications that are independent and have an API to integrate into the broader context.

Thirdly I wanted to build up an Open Architecture Model using Archimate version 3.0, that would help others in Architecting Cloud Solutions. At the end of the ten part series I will publish this model for download.

This information has been pieced together from information available off openstack.org and google searches. This blog has been written around the Openstack Ocata release from Feb 2017. In other words, it could be wrong in places, because of modelling older versions, etc. If you spot items that are simply wrong and thereby misleading, please contact me and I’ll try and fix the model.

OpenStack Core Services

Openstack Cloud has core application collaborations that offer application services defined as:

• Neutron [Networking] Services
• Nova [Compute] Services
• Glance [Image] Services
• Cinder [Block Storage] Services
• Swift [Object Storage] Services
• Keystone [Identity] Services

Not included in the core list of application collaborations, but core if you don’t want to do command line interface (CLI) interaction and configuration of your cloud is:

• Horizon [Dashboard] – Web GUI for defining and configuring the Core elements

Also – two optional more recent application collaborations as shown in the diagram below

• Heat [Orchestration] Services – Automates provisioning of Compute, Images, Networks & Storage
• Ceilometer [Telemetry / Metering] Services – meters the usage of most core components

The diagram below is not in Archimate, but was one of the simplest clearest models I found to explain the concept at a high level.

There are other optional application collaborations such as Ironic (bare metal service), Fuel (deployment service), Octavia (load balancing service), Trove (database Service), Sahara (Data processing), etc. In fact there are many (+/- 50 odd) optional application collaboration projects.

Core Application Architecture showing behaviour

In Archimate the high level Architectural view would look like the diagram below. Most Openstack core Applications expose behaviour via Application Services through an Application Programming Interface (API) realised by Application Functions, implemented as lower level Application Components and grouped by one Application Collaboration. You will see this coming out in the models in later blogs.

Each Application is built as a project under the project names as described below, and it follows a microservices style architecture. Virtually all Application Functions offer an API that exposes both CLI commands and set of REST based services, so they can be accessed manually as commands or manipulated programmatically for automation. The Dashboard then cleverly uses these same services to offer a User Interface via a Web portal from which to control your cloud configuration.

We will explore each Application Collaboration shown in the white dotted line packages above. We will explore each applications Logical Structured Architecture and the Behavioural Service Architecture in subsequent blogs.

Next

The next blog in the series is OpenStack Cloud Dashboard in Archimate – Part 2.