Cloud computing can be regarded as essentially the provision of computing resources and/or software as a utility, in the same way that your business uses familiar utilities, such as electricity, water, gas etc. Cloud computing enables you to pay for computing resources as you need them. These services are provided over the internet, on a consumption-based pay-as-you-use model, with short-term contracts and without up-front expenditure.

Whether you realise it or not, you’re probably already using cloud-based services. Facebook and Google are two prominent companies offering cloud-based software as a free online service to billions of users across the world. Google, for example, hosts a set of online productivity tools and applications in the cloud such as email, word processing, calendars, photo sharing, and website creation tools.

Broadly speaking, to be considered “cloud computing” an application’s data and core processing functions would be hosted/stored and managed online or ‘in the cloud’, and accessible from any PC, laptop or mobile device with a network connection in real-time.

In this context, “in the cloud” actually means that the application, along with the data it uses, is installed one or many powerful computers called servers, which are similar to home computers but in a different form factor and without screens, that reside within specially adapted buildings called data centres. Data centres are like warehouses filled with banks of servers in cabinets called racks. Data centres have powerful air conditioning systems to keep the servers cool and highly resilient power and internet connections. A picture of one of ours before being filled up is here.

Three Flavours of Cloud – the “service models”

One of the biggest confusions over cloud comes from the fact that it actually applies to a number of different layers in the “stack”. Don’t worry about what I mean by the stack, but if you’re curious see this post. There are three flavours of cloud, which broadly go down in cost but up in the required level of technical know-how in the order I have listed below:

Software-as-a-Service (SaaS)

These are usually applications or services that you access via a Web browser. Google Mail and Google Docs are examples of this kind of cloud computing. Some companies host an application on the internet that many users sign-up for and use without any concern about where, how, by whom the compute cycles and storage bits are provided.

Some SaaS is delivered via customised client applications, for example if you use Twitter or Facebook from an app on your phone. Our own SquirrelSave personal cloud backup product is also an example of SaaS in that sense – you, the user, doesn’t have to worry about where the data is getting stored nor the internal workings of the platform we have developed.

A better term than “software” might be “application”, since the platform part is also really just software, but SaaS has already gained wide acceptance. SaaS is usually the most expensive form of cloud since you are paying for the software as well as the underlying infrastructure and it requires no technical know-how. Examples of paid SaaS include Salesforce.com, though presently the most widely known examples are “free”. Of course, nothing is truly free, and by giving away their services companies like Facebook and Google are getting something – your information and time.

Platform-as-a-Service (PaaS)

This is a set of lower-level services such as an operating system or computer language interpreter or web server offered by a cloud provider to software developers. Developers write their application to a more or less open specification and then upload their code into the cloud where the app is hosted and automagically scalled without the developer having to worry about it overly. Microsoft Windows Azure and Google App Engine are examples of PaaS.

In old-school hosting parlance, a managed hosting service might also be considered PaaS – the developer gives the hosting provider some code, and the provider worry about how many servers, how much bandwidth (internet connectivity), etc. and just give the developer one bill. Because of the auto-scaling and ease-of-use afforded by PaaS, and the abstraction/obfuscation it gives the vendor, it usually costs a premium over renting the underlying infrastructure directly (IaaS).

For the more astute readers: You might hear people say that that Facebook is also a “platform”. This can easily get confusing; yes they provide a platform for developers to make add-ons, like the popular game FarmVille, but in reality they are just being a gateway (FarmVille runs on servers outside Facebook’s data centres) and are not providing any computer resources, so they are not providing PaaS. A similar example is Apple’s iOS platform – they provide tools to developers and a gateway to sell their apps (the app store) but if those applications that have a cloud component will likely be using IaaS or PaaS from elsewhere.

Infrastructure-as-a-Service (IaaS)

IaaS is the provision of virtual servers and storage that organisations use on a pay-as-you-go basis. This is the most powerful type of cloud in that virtually any application and any configuration that is fit for the internet can be mapped to this type of service, but is also the most technically challenging to exploit. Amazon’s Elastic Compute Cloud (EC2) and Simple Storage Service (S3) are examples of IaaS, as are our own Miniserver VM® cloud compute and Memstore™ cloud storage services.

In practice, cloud suppliers often provide additional services alongside IaaS offerings, so the boundary between IaaS and PaaS can become blurred. However in its purest form compute IaaS can be considered as a bunch of unmanaged virtual machines (VMs) for which you provide the operating system image, that can be scaled up and down (by spinning up and tearing down VMs) according to your application’s needs in near-real time (ie. within minutes). IaaS data storage is more simple, working like a giant disk drive where you only get billed for what you are using, usually on an hour-by-hour basis.

A virtual server or virtual machine (VM), is just like a normal server but is smaller in terms of CPU, RAM and disk than a whole physical server, and several sit on each physical host server. We typically put about 15 VMs on each host server, for example. VMs have the advantage that they can be created and destroyed effectively in real-time in dynamic response to demand.

Private vs. Public – “deployment models”

As well as IaaS, PaaS and SaaS (the “service models”), cloud has a number of “deployment models”. The ones I’m going to focus on here are “private” and “public” cloud. There are also “community” and “hybrid” clouds, but I’m going to save that for a later article. Also, here I am just going to briefly cover what public and private cloud means in the IaaS context.

Public cloud means that your virtual machines are sat on the same physical host servers as other clients. A private cloud is where the host servers, and in some cases the physical network or even an entire data centre facility, is dedicated to one client. When most people say “private cloud” what they usually mean is “a company’s own data centre with some virtualisation software”. This is arguably not cloud since you lose the scalability aspect. When we, as a cloud provider, say “private cloud“, we mean infrastructure dedicated to one client that we scale (by adding dedicated host servers into their set from our standby pool) as necessary. Some people would call that a “virtual private cloud”.

Moving To The Cloud?

One of the great things about cloud is that it can be experimented with very cheaply. If you are looking to make use of cloud services then I suggest just dive in! Start small, with one service, and then move more services once you are ready.

Analysts have indicated that future technology leaders will gravitate to cloud-based models as a way to deploy software and to store content, and we are certainly seeing that trend. A lot of customer start using our cloud as their development “sandbox”, costing a few £10s of pounds per month, and as they gain confidence gradually migrate more critical applications across.

I started with calculations based on our own power consumption (servers and in-datacentre network gear) and bandwidth output. We measure all power consumption and network activity, so all I had to do was design queries for our master data base.

Sampling one of our data centre suite’s energy consumption and bandwidth output, and dividing the former by the latter, gives a figure of 2.58 Watt-hours (Wh) per Megabyte (MB). That suite is our newest, and contains a mixture of Web hosting, application hosting, storage and other services. Some servers are used inefficiently at low utilisation, and some very efficiently, notable those which are part of our Miniserver VM^® grid.

For example, if we restrict the data to that from a selection of ten of our latest Miniserver VM^® host servers (quad-core 1U Dell Power Edge servers stuffed with RAM) the figure is only 0.61 Wh/MB, but I’m trying to be conservative here and make the calculations applicable to any Web-delivered service, not just the efficiently-run ones.

We must not forget the cooling and infrastructure losses (UPS, wiring etc). Our power usage efficacy (PUE) is about 1.4, but let’s err on the side of caution and add 50%, giving a total for electricity requirements at the data centre of 3.87 Wh/MB.

My educated guess of a typical 1U server’s embedded energy is 1,000 kWh (explanation here). If we assume a 3 year lifespan (it is actually more like 4-5 years in our case) then we get 333 kWh/year. Such a server uses about 100Watts continuously, or 1,100 kWh/year, so applying that ratio (1,100:333 = 3.3:1) we get an embedded energy cost of 0.78 Wh/MB.

The network and firewall boxes are probably in the same ball park in terms of embedded energy, however compared to servers there are very few of them: 1 switch per 30 servers, 1 router-firewall pair per ~200-500 servers, 1 border router pair per 2,000-20,000 servers. Therefore that equipment’s embedded energy is not significant in our sums. The same goes for the embedded energy of the data centre itself; when compared to the thousands of servers housed within, it rapidly becomes an insignificant factor. Rather than ignore it entirely, however, I shall add 10% to the embedded server energy factor (0.86 Wh/MB total) as an allowance for the embedded energy of the supporting infrastructure.

After some conversation with ISP friends we decided that the only really significant part of the network delivery energy will be the end points. Even though some big core routers consume kilo-Watts, they are shunting hundreds of gigabits per second, thus their power requirements are spread over a huge aggregation of data flows and rendered insignificant. The end points are the Digital Subscriber Line Access Multiplexers (DSLAMs – the big modems that send an ADSL signal down your phone line), and power for the home phone line itself.

According to the EU code of conduct for broadband equipment DSLAMs with more than 100 ports should use no more than about 1.3 Watts per port when active, so a fair high estimate of their average usage would be 1Watt. The phone line is a bit more difficult to estimate, but with my rudimentary knowledge of electrical systems and telecommunications equipment I think an upper estimate of 2 Watts is reasonable. Counting the phone line, and even the DSLAM, may seem a bit pointless since they are likely to be there anyway, but we are aiming to illuminate a worst-case scenario (ie. someone who otherwise would not have the phone line).

Anyway, if counting them, then we have, say, 3 Watts continuous (2,190 Wh) which gets used for about 2GBytes per month (a low average usage estimate, but in line with many ISP’s fair usage policies), which gives another 1.09 Wh/MB.

So, to sum up:

According to Google the average Web page is about 320 KBytes these days. Therefore, downloading a single Web page uses about 1.9 Wh. Boiling the water for a mug of tea in a kettle, by comparison, uses about 50 Wh (a 3KW kettle takes 90 secs to boil 2 mugs-worth – 37.5 Wh – plus a bit for the wasted water).

A music album is in the region of 100 MBytes (a bit more for iTunes, and varies depending on quality and number of tracks of course), which would be 590 Wh. A typical small electric car uses about 300 Wh per mile, so you could drive about 2 miles on the energy required to download and deliver a music album, or do the tea round for 12 people. The energy required to deliver music on CD is vastly more, of course, and I will look at that in another article, but it is interesting to see that downloading is certainly not without its carbon impact.

While the above calculations are fun it is important to point out that equating downloading to absolute energy requirements is extremely crude and should be treated with caution. A heavy Internet user would be much more efficient, for example, and the nature of the configuration of the servers in the data centre will also have a large effect, as seen with the differences if only our virtual machine grid is used in the assessment.

I also made a number of assumptions about the home end of the network, and it is useful to see the lower-end of the range. Therefore, if we use the Miniserver VM^® figure of 1.22 Wh/MB (including cooling and embedded energy), assume that the DSLAM ports are efficient when idle (most of the time) and call that 0.5 Watt and that the phone line itself is just 1 Watt giving a total of 0.55 Wh/MB (the same as if we assume the average utilisation is double my estimate, at 4BGytes/month), then we get a total figure of only 1.8 Wh/MB as the lower end of our download energy estimate.

For instance, if we assume that Apple run an efficient data centre infrastructure for serving their iTunes customers with similar properties to our virtual machine grid (which is very likely), and that the above lower estimate for the phone line is accurate, then a 100MByte album from them would only take 180 Wh – or about 3.5 mugs of tea worth of energy.

On the flip side, I have not included the energy to run the home network and PC(s)/laptop(s), which many papers do, but that greatly skews the figures and we are assuming here that those bits of equipment are used for other purposes than just downloading.

One of the areas on which we reached clear agreement in the G-Cloud and App Store phase 2 was the definition the layers of the stack, infrastructure, platform and software, and their scalable, standardised “as a service” modes. Pleasingly, our delinations were very similar to prior work from two decades ago by IBM, except that ours incorporate virtualisation.

The diagram shows what we agreed we mean by Infrastructure as a Service (IaaS), Platform as a Service (PaaS) and Software as a Service (right hand side) and the areas encompassed by the individual terms infrastructure / platform / software on the left. A better term than “software” might be “application” since the platform part is also really just software, but SaaS has already gained wide acceptance.

It is assumed that “as a service” means all services within the definition are fully integrated up to and including the respective level, thus incorporating any sub-levels. Therefore, SaaS providers could either sub-contract to a PaaS provider, or would incorporate the PaaS themselves and provide it as part of the SaaS “stack”. In turn the IaaS could be sub-contracted or incorporated. The customer would see an integrated service.

It is also worth explaining the overlap between ‘platform’ and ‘software’; that is because some advanced platforms are built on complex software solutions which go well beyond just operating systems and a bit of infrastructure software.

For example, one could consider bare operating system as the platform, with the bespoke software application incorporating its own software infrastructure elements (eg. a bespoke CRM solution). One might also consider a Linux-Apache-MySQL-PHP stack as the platform in its entirety, with only the PHP code and databate structure being the software/application layer. The key differentiator between ‘platform’ and ‘software’ is that a platform is standardised and to an extent commoditised, with the software being the bespoke / custom element. A platform would also often, but not always, be highly scalable across multiple servers.

Standardised / commoditised software (hosted application) services, as opposed to bespoke / custom deployments, would most likely be considered to be SaaS.

Virtual differences

Until this point many experienced readers might be saying, “Yes, that that is just hardware, middleware and software renamed!”. To a large extent you would be right, with one small exception being subtle differences between modern platform or middleware, but there is an important difference between the old concept of “hardware” and ours of “infrastructure”: virtualisation.

It was agreed among the G-Cloud team that the virtualisation should now be considered as part of the hardware layer since it has become such an integral method of dividing and provisioning hardware resources. It is important to note that we drew the line precisely between the virtualisation layer (ie. the hypervisor) and operating system, viewing a bare-bones virtual machine without operating system or kernel as the unit(s) of hardware.

Of course, virtualisation is not ubiquitous. Indeed for many systems including highly scalable ones upon which PaaS and SaaS stacks are built do not use any virtualisation (Google App Engine does not, for example). In such cases one would simply view the stack without the virtualisation layer with the boundary between infrastructure and platform being between the physical hardware and operating system layers.

Network

Another critique of this model could be that the “interconnecting network” appears to link directly from the software layer through to the client device. In reality, of course, all network traffic has to sink back down through the layers from the software to via the networking & firewalling layer, then on to the client device. To keep the stack looking like a stack, however (which is correct from a logical perspective), it is better to stick the client device on top rather than off to one side. In the full postulated functional of the G-Cloud logical architecture the connections are more explicitly shown in a 2D rather than linear model. Hopefully that will be in the public domain soon!

• What does it take to be really green?
• What needs to be in IT policies?
• How can we tell myth from truth in an emotive area?

The protagonists:

• Chair: BCS managing editor Brian Runciman.
• Tracey Rawling Church from Kyocera Mita
• Louise Richards, chief executive, Computer Aid International
• David Critchley, director of retail and professional services at Cisco
• Kate Craig Wood, managing director of Memset and a member of the BCS Data Centre SG

I was at the preview of this tool on 30th April in Southampton Street, and it is an amazingly powerful tool. It allow you to rapidly put together a simulated version of your data centre (including characteristics of everything from power cables to server virtualisation systems to external temperature variation), and then ‘run’ it over a period of time to see the costs and power requirements.

During the demonstration in April, Liam & Zahl (the technical and business brains behind the project) used the tool to great effect, neatly and intuitively demonstrating some of the following:

• The inadequacies of DCiE/PUE as useful a metric due to variation with light work loads; you need to measure facilities power and IT power separately.
• How virtualisation drops the total cost of a datacenter by 75% or more (or you can migrate to us and save >85% of course .
• How simply changing from nameplate (typically >400W on the label on the back of a£1,000 1U server) to peak power provisioning (most modern 1U servers never use more than 150W) reduces the 4-year lifetime server cost from £8,000 to just £5,000.
• That a modular build-out is good, but to be most energy- & cost-efficient you really need a dynamic modular approach so that you can switch M&E equipment on/off with diurnal load variations.
• How data centre costs vary with geo-location! Putting it in Iceland does not save you much after all, contrary to popular belief.

The simulator itself is a pure command-line driven tool that has been released under an open source software licence (OSL V3.0), but there is a Web-based interface that is now available to DCSG members, here, although you will need to read the user guide first unless you have a brain the size of a planet.. If you are a member of the BCS but not of the DCSG, you can find out information here: bcs.dcsg.org. If you are not a member of the BCS but are British and an IT professional, then shame on you!

The beta test is likely to last until Autumn, and feedback is welcomed so that the tool can be further improved and any bugs ironed out. Also, the Carbon Trust and BCS are looking for members willing to trial the tool on a case-study basis over the next few months. If you are interested, visit the Carbon Trust data centre sub-site.

Materials, manufacture and distribution of an average PC currently in use today is is between 750 kilo Watt hours (kWh) for the most modern “green” PCs, and 1,300 kWh for machines of a few years go. You then have to add on about 300kWh for a LED screen (500kWh for a CRT screen). Even if we take the best case scenario we are still looking at a minimum of 1,000kWh for a desktop system, and laptops will only be a little less (most of the energy in PC manufacture goes into making the small, complex components such as chips).

An average PC made within the last few years, with its screen, uses about 100W when powered up and 3W when in hibernate mode. If we assume that the PC is on for 8 hours per day, 5 days per week, and is hibernating overnight we get 200kWh/year “on” usage and 20kWh/year standby usage.

So, a 3-4 year old PC probably used 1,200kWh to make and uses 220kWh/year to run, whereas a modern super-green PC might use 1,000kWh to make and burn 150kWh/year. To look at it financially, you will save about £7/year by switching to a super-green PC. Therefore it makes neither financial nor environmental sense to swap out old PCs before about 6 years. If you need to update the software, then switch to some sort of virtual desktop infrastructure instead and use the PCs as thin clients.

The same sums applied to servers on 24/7 are quite different though. An average £1,000 1U rack-mount server bought 3-4 years ago probably “cost” about 1,000-1,500kWh to make and uses 120W at moderate load, which over a year is 1,050kWh, or at least 1,500kWh when data centre cooling is taken into account. The latest equivalent “green” servers use as little as 80W, so swapping to energy efficient servers will save 400kWh/year in electricity and get you 2-4 times more performance.

With good use of virtualisation to consolidate existing applications onto a smaller number of machines (thus taking advantage of the performance improvements) it makes clear environmental and economic sense to replace machines after 2-3 years. Alternatively, if IT is not your core business activity then you could always consider outsourcing your server infrastructure to a carbon neutral IT host such as Memset of course.

As for the old servers, why not give them away to Africa via Computer Aid International, where our “outdated” hardware is much needed and will be put to good & efficient use (ie. it will only be on when they need it).

Addendum June 2009: There are some very cool technologies like Very PC’s Greenhive (a hybrid between PCs and thin client) which are changing the argument around replacing desktop PCs.

Thin client is also reaching maturity now that you can get a decent amount of bandwidth from ADSL and that Windows Server 2008 includes most of the functionality of Citrix at no extra charge. Thin client is definitely the future I think.