As described in an earlier post, another concept for cloud computing architectures is the concept of roles. But what exactly is a role? A role is something that shares common functionality. If we talk about a web shop, this web shop might consist of different roles such as:

• Product presentation role
• Shopping cart role
• Order processing workflow role
• …

The initial question of this is: isn’t this called SOA (Service oriented architectures)? The answer is: no. It is very similar to SOA and basically derives a lot of it’s concepts from SOA but it is rather a “SOA of SOA”. A role might contain one or more services, but a service is covered by exactly one role. Let us think about the shopping cart: an architecture for the shopping cart might hold different services. The role itself would be the shopping cart role with services for:

• Shopping Cart modification Service
• Checkout Service
• Payment Service

A role collects different services and makes it easier for us to understand the way how an application is built. With SOA, we can go more into detail and give a better overview for those that have to implement the platform at the end. Different roles should be able to be scaled independently from each other to achieve great elasticity in the cloud. Furthermore, a role should only be in charge of similar tasks. If we think about the shopping cart again, we can definitely say that services in that role are somewhat similar. The illustration below shows how different roles can be built.

Application Role Separation in the cloud

As described in the last post, we will now take a look at how it is possible to architect cloud computing applications with the support of Archimate. Archimate was developed by the Open Group and it’s target is to achieve a great enterprise architecture. We will discuss each layer and figure out how we can apply this to cloud computing architectures.
A core concept of Archimate are views. Views in Archimate allows the architect to show different levels for different stakeholders. We won’t focus on that now. If you are interested, you can refer to the Archimate Documentation. We also discussed the different layers – business layer, application layer and technology layer. To model each layer, you can use different tools. I personally prefer “Archi” for this purpose. In the Screenshot below, you can see the main window of Archi.

Archimate design with Archi

Archimate Business Concepts

Archimate Role and Actor

Archimate Processes and Events

To find out about the Cloud Architectures we want to use, it is necessary to know the characteristics of distributed systems. Another important aspect we should consider looking at are the aims of cloud systems. If we know what aims and characteristics are, it might be easier to build a software architecture for the cloud. However, each implementation requires different approaches since each system is different from each other.
Let us start with the characteristics of cloud systems.
Cloud computing systems have a characteristic, that it is a sum of many systems (instances), but it feels like a single system for the end user. This means that it is transparent for end-users and end-users typically don’t see how many servers are involved. End users might even believe that this is running on a single server (but it is not like that). End users should not be confronted with the challenges architects/developers have to face when building a SaaS-Application. Just imagine Facebook, Twitter or Flickr: end users don’t really care about distribution, they simply want to use that platform. This means that our application has to look like a single software and hide the challenges we face for distribution.
A cloud computing system typically consists of different components. Components are various things such as instances, services, … If we build a distributed system, we have to utilise different instances with different roles. Some roles might host the website, other roles might do some background work. Different components is often implemented by SOA (Service Oriented Architectures) which is described later.
Different components as described above have to communicate with each other. Communication can be done with various technologies such as messaging. This requires the use of a message buffer.
Users of a cloud computing system can use the system in a transparent and consistent way. If a user travels, the system should represent the same state as it did before traveling. If the user works on a presentation for a client and saves the presentation, it should look absolutely the same when the user arrives at the customer’s site. Consistency is a challenge we often have to deal with in the Cloud and we will focus on that in a later post.
Cloud computing systems have to be extendable. If we have a SaaS-Application, it might serve 90% of all use-cases, but what happens with the 10% it can’t serve? It should be extented by additional services. If we look at a very important platform – Salesforce – it can be extended by a PaaS-Platform named “force.com”. To achieve extensibility, the platform must offer well-defined interfaces for potential consumers.These interfaces are typically served via an API.
The last characteristic we want to focus on is that distributed systems are often using a middleware. This middleware abstracts things from the operating system and serves interfaces to handle common things. We can see this with PaaS, where the middleware spans a large number of virtual instances. However, we simply don’t care about the operating system that is under the middleware.
Picture Copyright by Moyan Brenn