Cloud Computing Architecture
Cloud Computing Architecture
Cloud Computing Architecture – an Executive summary
Cloud Computing Architecture – the layer model
The ‘more complete’ cloud computing architecture
The cloud computing architecture is generally represented as a ‘stack’ model.
In the more complete model, there are five layers –
| Client |
| Application |
| Platform |
| Infrastructure |
| Server |
A brief description of the layers –
The Client layer represents the devices that a User to connect to ‘the cloud’ – the Desktop PC, Laptop, Smartphone, Blackberry, iPhone, etc. (or more correctly, the software running on those devices.)
The Application layer represents the ‘apps’ that the User accesses ‘in the cloud’ – email, CRM, HR, messaging, etc.
The Platform Layer represents the technology ‘stack’ that the apps are built on – Google Apps Engine, LAMP, WINS, etc. This layer tends to dictate the relative technical strengths and weaknesses of the apps that are built on them, e.g. speed, volume of users, volume of data etc.
The Infrastructure Layer is roughly – but not exactly – equivalent to what would previously been called the operating system – e.g. Windows, Linux, Solaris, etc.
The Server layer represents the actual hardware that ‘the cloud’ runs on that is generally hidden away in the data centre – ‘racks’, ‘blades’, SANS, tape drives, storage devices, etc.
A Simplified cloud computing architecture
It is quite common to use a simplified cloud computing architecture comprising only of the middle three layers. (Since perhaps the ‘raison d’être’ of cloud computing architecture is to ‘hide’ actual computing hardware in Server layer, and since the Client layer mostly represents external devices that are connecting into ‘the cloud’.
| Client |
| Application |
| Platform |
| Infrastructure |
| Server |
This simplified cloud computing architecture model is particularly true of vendors’ representations; their products tend to exist in one or more of these layers. Additionally, Vendors’ products in any one of these layers may be closely tied to other products in other layers; Or, with products such as Google Apps, there’s a product offering that ‘blurs’ the distinction between the layers almost completely.
There are various trends associated with the layers of the stack.
- Each layer is built on the layer below.
- Each layer depends on the layer below.
- Users have less visibility of each layer as we move down the stack.
- Users are less aware of the existence of each layer as we move down the stack.
- The higher the layer, the more ‘customisation’ choices available.
Cloud Computing Architecture – key resource metrics
Cloud Computing products tend to operate on a ‘utility computing’ pricing model.
That means that products are sold as comprising one or more resources; resources usage is metered; the user is billed for the metered resource usage, typically on a monthly basis. While this lends itself to lower prices to users overall, a good understanding of the resource metrics (and predicting your likely usage) is critical to understanding cloud computing costs.
The type of resource metering you’re likely to encounter depends on which layer the product you are buying exists in the Cloud Computing architecture model. In the Application Layer, resources tend to be ‘bundled’ into a single usage charge, whereas at the Infrastructure Layer each low level ‘raw’ resource may be metered and charged separately. At the Platform Layer you may encounter ‘bundled’ or ‘raw’ resource charging, or a mixture of both.
Bundled resource pricing
Bundled resource pricing is typically on a ‘per item’ or an ‘x items’ basis. For example, $5 per user per month, or $9.80 per 1000 emails sent.
Raw resource pricing
Predicting and pricing raw resource usage is necessarily more complex, but can be the key to huge savings for bigger and/or savvier users. Raw resources are typically charged under the following types
Bandwidth
This is the amount of data transported between your client devices and ‘the cloud’. Sometimes ‘upload’ bandwidth and ‘download’ bandwidths are monitored separately.
For example, an email system would be expected to have similar bandwidth usage in both directions, whereas a video hosting site would expect many downloads for every video uploaded.
Processing/CPU
This is the amount of ‘brainpower’ you use on the host computer.
For example, an email application requires a relatively tiny amount of processing power compared with a scientific analysis or simulation applications.
Storage
This is the amount of data actually ‘persisted’ at the data centre.
For example, a messaging system with no audit records would use almost no storage when compared to a supermarket product database, or a video hosting service.
Cloud Computing Architecture – the vendors obligations and limitations
Finally, when discussing or negotiating the procurement cloud computer products there are a number of other elements that are key to success.
SLAs
A ‘Service Level Agreement’ or SLA is, or certainly should be, the cloud computing product vendor’s commitment of exactly what they will make available to your cloud computing clients to consume. You should view this as your ‘guarantee of supply’ and review it as you would any ‘small print’ document.
Scalability and Availability
These two terms are often confused, both with each other, and confused with being resources – which they are not.
Scalability is the ability or ease with which the ‘power’ of a particular resource ‘host’ can be increased (or decreased). For example, in the case of CPU power, to change from one processor to two or more processors, or to go from a 2GHz processor to a 2.5Hz processor, or to o from a 32 bit processor to a 64 bit processor .
Availability on the other hand is the measure of the amount of time the system will be available for use. This is normally expressed as a percentage – for example 90% availability over a year is just under 11 months, whereas 99.9999% availability is the loss of around half a minute over the period of a year.
Related Pages
Cloud Computing Security
Cloud Computing Platforms | Cloud Computing Behaviour