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: how to build and plan your cloud


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?

read more Cloud Computing Architectures: how to build and plan your cloud

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

Strategies for Cloud Computing Application Deployment


As already mentioned in the last post, Application deployment in the Cloud is not an easy task. It requires a lot of work and knowledge, unless you use Platform as a Service. The later one might reduce this complexity significantly. In order to deploy your Applications to an Infrastructure as a Service Layer, you might need additional knowledge. Let us now built upon what we have heard from the last post by looking at several strategies and how they are implemented by different enterprises. Some years ago before joining IDC, I worked for a local Software Company. We had some large-scale deployments in place and we used Cloud Services to run our Systems. In this company, my task was to work on the deployment and iteration strategy (but not only on that ;)). We developed in an agile iteration model (basically it was Scrum). This means that our Team had a new “Release” every 2 weeks. During these two weeks,

read more Strategies for Cloud Computing Application Deployment

Data in the Cloud: SQL? NoSQL!


In recent years, one trend has become increasingly popular: NoSQL Databases. Databases built without relations, but made for high scalability. But is it really that “good” to go for NoSQL Databases? Doing so means removing the consistency that SQL Databases offers. Isn’t that a big tradeoff or is it worth going for more NoSQL Databases? What are the opportunities, advantages of NoSQL and why should you definitley keep an eye onto it? Join me for a tour on NoSQL. A world without relations, no joins and pure scalability! A key disadvantage of SQL Databases is the fact that SQL Databases are at a high abstraction level. This is a disadvantage because to do a single Statement, SQL often requires the data to be processed multiple times. This, of course, takes time and performance. For instance, multiple queries on SQL Data occur when there is a ‘Join’ operation. Cloud Computing environments need high-performing, and highly scaleable databases. Normally, SQL Databases have

read more Data in the Cloud: SQL? NoSQL!

The art of Cloud Computing Scalability


With Cloud Computing, we often hear that “Scaling” is very easy. In most cases, it is actually like that! You can simply go and add new virtual machines/instances on demand, with only some seconds or minutes to be provisioned. However, there are some other factors that improove Scalability or limit scalability. The reason for that is simply: if your software is built a way that dissalows scaling, you can never use the benefits of the cloud. Just because you can scale your instances on demand, it might not mean that your software allows that! Imagine the following scenario: your Web Application stores data like images in the File System. Suddenly, you have increased need for performance as your business grows. So what would you do? Exactly, simply add a new instance. After a while, your users and customers complain that they can’t find their images all the time. After a while, you figure out that the Load Balancer directs to

read more The art of Cloud Computing Scalability

Design Guidelines for Cloud Computing and Distributed Systems


Infrastructure as a Service and Platform as a Service offer us easy scaling of services. However, scaling is not as easy as it seems to be in the Cloud. If your software architecture isn’t done right, your services and applications might not scale as expected, even if you add new instances. As for most distributed systems, there are a couple of guidelines you should consider. I have summed up the ones I use most often for designing distributed systems. Design for Failure As Moore stated, everything that can fail, will fail. So it is very clear that a distributed system will fail at a certain time, even though cloud computing providers tell us that it is very unlikely. We had some outages [1][2] in the last year of some of the major platforms, and there might be even more of them. Therefore, your application should be able to deal with an outage of your cloud provider. This can be done

read more Design Guidelines for Cloud Computing and Distributed Systems