Skip to content
Agile Enterprise Architecture
  • Home
  • Services
    • Remote Services
      • Looking for EA modelling?
      • Why Arch-as-a-Service?
      • Modelling-as-a-Service
      • Assess Arch Maturity Free
      • Arch Modelling Notations
        • Archimate model types
        • Quadrant model types
        • Canvas model types
        • UML model types
        • BPMN Model types
        • DMN Model types
        • ERD Model types
        • Structured Info types
        • Cisco model types
      • Arch Modelling tools
    • Consultancy Services
      • Digital Integration Services
      • Business Architecture
      • Health check services
        • Arch Risk Assessment
        • Arch Governance checkup
        • Arch Models health check
        • Arch Content health check
    • Cloud Hosting services
      • EA SaaS – Orbus iServer
      • EA SaaS – EVA Netmodeler
      • EA SaaS – Dragon1
      • Meta-Model Structuring
  • Blogs
  • About
    • Our AgileEA Business Model
    • Our AgileEA Principles
      • Open & Transparent
      • Value for money
      • Keep it simple
      • Love what we do
      • Efficient & effective
    • Location
Cloud Openstack

OpenStack Cloud in Archimate – Part 1

  • 2017-04-272018-05-08
  • by Charles

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.

Openstack Cloud Application Components by Function

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.

OpenStack - Core high level Architecture showing interactive Behaviour

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.

Cloud Openstack

Hosting and Cloud Software Delivery modelled in Archimate

  • 2017-04-192018-05-08
  • by Charles

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.

IaaS-PaaS-SaaS

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.

On Premise Hosting

 

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.

IaaS-Hosting

 

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.

PaaS-Hosting

 

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.

Containerised-PaaS-Hosting

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.

Next

See Open Stack Cloud modelled in Archimate – part 1

Posts pagination

1 2 3

Categories

Tags

Agile AgileEA-Process archimate architecture practice business-arch Business Uses cases Capabilities cloud culture Data Architecture Enterprise Architecture health checks IoT maturity openstack Requirements Services strategy System Use Cases techical debt train44ir Use Cases Values visual models

Recent Posts

  • Announcing Our Train44Ir.org charity 2020-04-24
  • Data Fabric Framework – Archimate 3.0 model 2018-05-10
  • OpenStack Cloud Metering in Archimate – Part 10 2017-04-28
  • OpenStack Cloud Orchestration in Archimate – Part 9 2017-04-28
  • OpenStack Cloud Identity in Archimate – Part 8 2017-04-28
  • OpenStack Cloud Object Storage in Archimate – Part 7 2017-04-28
  • OpenStack Cloud Images in Archimate – Part 6 2017-04-28
  • OpenStack Cloud Block Storage in Archimate – Part 5 2017-04-27
  • OpenStack Cloud Compute in Archimate – Part 4 2017-04-27
  • OpenStack Cloud Networking in Archimate – Part 3 2017-04-27
  • OpenStack Cloud Dashboard in Archimate – Part 2 2017-04-27
  • OpenStack Cloud in Archimate – Part 1 2017-04-27
  • Hosting and Cloud Software Delivery modelled in Archimate 2017-04-19
  • Why do Architecture Maturity Assessments regularly? 2017-03-22
  • Archimate 3.0 introductory basics videos 2017-02-28
  • Example Services and Capabilities with Meta-Model 2014-11-09
  • Why a CV in Archmate? 2014-07-14
  • Charles Edwards Archimate CV 2014-07-10
  • EA Conference 2009 – Agile EA: A Step change is required 2009-06-13
  • Who should own Enterprise Architecture? 2009-03-28

Previous Posts

Our Twitter Feed

My Tweets

Recent Comments

    Translate site

    Tag Cloud

    Agile AgileEA-Process archimate architecture practice business-arch Business Uses cases Capabilities cloud culture Data Architecture Enterprise Architecture health checks IoT maturity openstack Requirements Services strategy System Use Cases techical debt train44ir Use Cases Values visual models

    Blogs about

    AgileEA Process Blogs Charity Cloud Openstack Enterprise Architecture Health checks Information & Data Modelling Strategy Technical Debt Thoughts Use Cases
    Copyright: Time 2 Talk CC T/A AgileEa.com, 2006 - 2026.
    Theme by Colorlib Powered by WordPress
     

    Loading Comments...
     

    You must be logged in to post a comment.