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
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
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
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?
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
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
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
In Cloud Computing Environments, we see a significant switch in how the industry treats Datacenters. Cloud Computing and Big Data transform the way how we think about Datacenters. But why should that be so? First of all, we have to look at how Servers and the market looked like some years ago. Many companies bought their Servers. Small and Medium Businesses (SMBs) used to run their own Servers, maintain them and own them. A datacenter often consisted of only one rack or some Servers. This means that there is a polypoly on the demand side (buyers). On the supply-side, we had some companies such as Dell, HP, IBM and others. This is named an oligopoly. In this market situation, the supply side is stronger and negotiations are traditionally harder. If you are a large enterprise, you could generally get better conditions. Nowadays with Cloud Computing, the datacenter design is shifting dramatically. Small and Medium Businesses will rent their services such