Cloud Computing Architectures: application roles

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

read more Cloud Computing Architectures: application roles

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

read more Cloud Computing Architectures: Application layer and technology layer with Archimate

Cloud Computing Architectures: High-Level architecture with Archimate

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. Let us now start with some business layer concepts. In the image below you can find the business layer concepts

read more Cloud Computing Architectures: High-Level architecture with Archimate

Cloud Computing Architectures: aims and characteristics of cloud systems

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

read more Cloud Computing Architectures: aims and characteristics of cloud systems

Cloud Computing Architectures: 12 Design principles

As referenced in the last post, the book “the art of scalability” provided a very good approach to cloud architectures or what has to be done. They also define some other great principles, resulting in 12 design principles for software architectures. Most of the principles are very interesting for cloud computing as well. 1. N+1 Design There should be at least one additional System. Normally you should have 3 Systems. Premise: one System for me, one System for the Customer and one System for the Errors 2. Design for Rollback Applications should always be able to be downgraded. It should be easy to downgrade a System in case of an Error. 3. Design to be Disabled It must be necessary to disable a System or Parts of it, if there are problems. However, the overall System should not be effected by this. 4. Design to be Monitored Not only IO or CPU Performance is important, it is more about  „intelligent“ Monitoring. We want to

read more Cloud Computing Architectures: 12 Design principles

Cloud Computing Architectures: a Smart Architecture

The book “The art of Scalability” describes a very interesting approach to Software Architectures for distributed Systems. A key challenge is that a Software Architecture should be smart. But what exactly is “smart”? The book describes “smart” in a different sense and the letters are capitalised. We talk about a SMART architecture. Each of the letters represents an individual challenge to Software Architectures: Specific Measurable Achievable Realistic Testable Specific: The Architecture should solve a Problem. It doesn‘t need to be the „coolest“ one. Measurable: Application basics must be measurable. Sample: the Service must return the data within 1 second, if 1 Million People access it. WRONG: The Service must be fast if a lot of people access it. Achievable. The goals set by the architecture must be achievable. It makes no sense if the architecture allows everything but can‘t be done by the developers as it is too complex Realistic. It is necessary to use the potential within an organisation. If the developers in a company

read more Cloud Computing Architectures: a Smart Architecture

Cloud Computing Architectures: What needs to be scaled?

Whenever we think about scaling our Applications, we basically think about building a software architecture that supports scaling and selecting a technology such as IaaS or PaaS Platforms to achieve that goal. But scaling is more compliated than it seems. It is not only a thing that needs to be achieved in technology or software architectures. An important question is, what needs to be scaled in an enterprise. It is not only the software architecture but also other factors: Websites Applications Teams Organisations When talking about scaling organizations, some questions may arise: How easy is it to add a Person to a Company/Team or remove a Person? How can the work force be measured within the organisational structure? What effort has to be made if a new Person is added to a company? Does the company structure allows rapid organisational growth? The Output of a team is not proportional to the number of people in a team. This is similar with

read more Cloud Computing Architectures: What needs to be scaled?

Cloud Computing Architectures: Scalability vs. Elasticity

For Cloud Solutions, Scalability and Elasticity are key requirements. In private Cloud Solutions, this should also be supported, even if scalability and elasticity might has a lower border as we see in the public Cloud. Scaling applications means that we can add a new instance of Linux or a Windows Server. Elasticity is something “more advanced” to that as described by Reuven Cohen, an opinion leader in Cloud Computing (Cohen, 2010). Reuven describes scalability as the possibility to “grow to the demands of the users on a platform” whereas he states that elasticity is something that reflects real-time conditions. A platform might have millions of users, but if this platform is only available in the United States, there might be significant fewer load on the servers during night. The load will be much higher at peak times and elasticity means that unnecessary instances are shut down if the load is lower or that new instances are started if the load

read more Cloud Computing Architectures: Scalability vs. Elasticity