We are almost at a point where we can get more hands-on in terms of cloud architectures. However, there is still something we have to mention prior to talk about architectures itself. Cloud Computing is not an easy thing you can achieve since it involves a lot of knowledge: you need to know about resource automation (in case you use IaaS; with PaaS it is often easier) and than you definitely need to know everything about concurrency, distributed databases, …
This complexity in a cloud environment requires us to build a cloud architecture not only on some “core technologies”. An architecture needs to be planed in detail. It is also important to figure out how you want to iterate in an project or how you deploy your software once there are upgrades or bug fixes. But how is it possible to achieve an architecture that is detailed but still gives us the possibility to show the architecture to different stakeholders? CXOs need a more abstract model as their focus is on deciding whereas a software developer needs a lot of details. The short answer is: there is no easy solution for that. The long answer: we have to learn additional tools.
In the next few blog posts, we will look at Archimate and UML for a high-level architecture.
As we need to address different stakeholders with each stakeholder needing a different level of detail, we need to “layer” our architecture. A first hint for that can be found with Archimate. Archimate basically knows 3 different levels for an enterprise architecture. This is described in the illustration below:
Archimate knows 3 main layers. Let us brief look at each layer and figure out how each layer can be applied to cloud computing architectures.
The Business Layer is the most abstract layer. This layer allows us to model everything that is related to the business functions and processes. In the business layer, we define the business processes, business actors, different services and general interactions.
The Application Layer models all services that are used by the Business Layer. We also model the application components, services and interactions associated with it. We can model the inner behaviour of an application in this layer and combine our application components with other application components. This leads to SOA – which we will discuss later on in detail.
The Technology Layer is the lowest layer. We define all infrastructural elements on this layer. This might be some IaaS or PaaS components. We can use this layer for cloud computing architectures to model all external services and instances.
As already mentioned earlier in this post, we will look at each layer in the next posts and will also model some examples.
Picture Copyright by Moyan Brenn