Cloud Computing Architectures: Application layer and technology layer with Archimate

As described in our previous post on cloud computing architectures, I would like to continue with the architectural approach given with Archimate. Archimate comes with two more layers, the application and the technology layer. The Application layer has some core concepts we can use for cloud computing architectures:

• Services. Services are provided by our platform and expose and endpoint for other applications or services. This is often implemented by a web service. With a service, data is usually exposed to consumers or operations are made available. A typical service could be a customer service, that exposes customer data.
• Interfaces. Interfaces are built for interoperability between different services or applications. A service typically provides an interface to the consumers. Consumers use the Interface but the implementation is done at the service side.
• Application Component. An application component is a software application, that provides some way of interaction, maybe via a service. We could use an application component to retrieve data or so.
• Data Object. This basically describes an object that contains data. This is typically a row in a database.

Of course, this list is not complete. For a more detailed description please refer to the Archimate Documentation. In the following sample, we will model a very simple application layer case.

In the above sample, I modelled a very abstract customer service. This service is used by a shopping system. The service itself queries Salesforce.com to retrieve the data via the Salesforce API. Salesforce.com is represented as a application component in our architectural sample. The customer service itself uses some data, which is contained in the customer data object.
The lowest layer for Cloud architectures is the technology layer. In this layer, we can model different instances – or let’s say roles (I will describe the concept of roles later on). This is basically useful when using Infrastructure as a Service (IaaS) or Platform as a Service (PaaS). With the technology layer we model the overall components used by our platform in an infrastructural way. Core concepts are:

• Nodes. A node is normally an instance in Archimate, e.g. a single server. However, we use the node for a complete role. Imagine Netflix would model each of their servers with an individual node – they might end up having such a complex model that nobody would understand the model. A individual role (such as the front ends) are represented by a Node.
• System Software. A system software is a software that fulfils elementary tasks. A sample for a system software is the apache web server or PHP, MySQL, … System software usually runs on a node. It is also possible to have more system software installed on a node.
• Network. Individual Roles communicate with each other – either within the Role or with other roles. Therefore, some type of transportation must be available. This is represented by the network.
• Communication Path. The communication path is another way of communication. This is not the network itself but it is a more abstract way of communication. Normally, the communication path could be represented by a message queue.

In the following sample, I tried to model a very basic architecture for an IaaS-Platform based on the concepts introduced above.

In the sample above, we have three major roles for our cloud platform architecture: front-ends, database and backend. The Front-end is one or more (if load balanced) virtual instances running Linux. On each instance, there is Apache and PHP installed. This is also called a stack, the shortcut for this stack is “LAP”. Normally, we would also use MySQL, which would be named “LAMP” (Linux, Apache, Mysql, Php). However, since our architecture should be scalable, I decided to outsource the database to another role. This gives us the possibility to scale the front-end and database independently. On the database role, we instal MySQL and some sort of reporting services for business intelligence. These two roles are connected via a LAN. The third role is a backend role. On this role, there is a custom application with OpenXML installed. This backend role basically processes data and returns documents. The communication isn’t done directly but it is done via a message queue. I will also explain this in a later post why I don’t communicate directly.
Picture Copyright by Moyan Brenn