Last week I bought a small app for my iPhone called Net Status (app store link). The premise is simple – you enter one or more websites that you want to check are running and it scans them and reports back. (Aside: It’s great as a quick check on the road when a client calls and says “my website is down” and gives you a quick way to prove or disprove this. Even when you have other tools that monitor and report uptime, plus a client can use the tool to check themselves).

The interesting thing that the tool does is scan the common ports for the website you enter and then provides a list of ports you want to monitor. You can deselect some, but it showed some very interesting differences between websites hosted on virtual servers, dedicated servers and cloud hosting. Here’s a quick table (based on a LAMP – Linux, Apache, MySQL, PHP – setup), but please read the notes following it!

Port	Cloud	Virtual	Dedicated
Ping
http
https
ftp	-
mysql	-
dns	-
telnet	-	-	-
ssh	-
smtp	-
smtps	-	-
pop	-
pops	-	-
imap	-
imaps	-	-
afp	-	-	-
smb	-	-	-
vnc	-	-	-
rdp	-	-	-
lpr	-	-	-
ipp	-	-	-
postressql	-	-	-

The in the table show the ports that can be scanned from the Internet, and so represent easiest routes for a hacker to attempt to exploit the server and your website. Out of the box, a dedicated server has many more possible attack vectors which a sysadmin needs to lock down or manage the security for.

The reason that there are so few attack vectors in the cloud is that the website, the database, email, and often FTP are all separated through different channels (IP routes). This is the nature of the Cloud and one which brings a greater default level of security obfuscation “out of the box”.

However, to provide a balanced view, ports and IP addresses for things such as the database server, the email server, etc, are actually shared between many different sites in the Public Cloud and you may inadvertently be exposed in other ways. For more information on this latter discussion see “When the Clouds break; Risks in the Public Cloud“

Note that these cases apply can equally to public and private clouds, just as they can to any type of hosted environment. These are not new situations, and the cloud in itself does not magically solve them, but the elastic nature of the cloud can often sweep them under the carpet.

Performance

In a single-server environment it is easy to see that when all your local resources are used up, things will run slowly or stop completely. In the cloud, the same thing is true, but the likelihood of it occurring is (mostly) mitigated by the fact that there is an extensive (but finite) network of computing resources available to scale the output of the web application, limited only by the number of devices available for the application to scale across.

Let’s look at Twitter as an example. In October 2009 we saw lots of “Twitter is over capacity” tweets. If you look at the data these are usually localised to a geographic region. Most of the tweets were Spanish when I checked and I am guessing this was South America experiencing the edge effect of their access route to Twitter becoming over capacity, ie their “corner” of the cloud had reached capacity, because (here in the UK) everything was running perfectly. So, although Twitter’s private cloud appeared to be running correctly (since tweets were being managed), some of the public parts of the network used to access it were not. For an overview of the Twitter infrastructure see this post (may be NSFW due to partial nudity involved to illustrate the discussion of the shared hosting used for Twitter status pages).

Moral of the story: Don’t just consider the availability of resources to run your web application, consider the availability of access points to reach it. Remember, ALL of these are shared, so you don’t want to fall foul of other people’s success. This risk is present for any form of hosting, but Cloud hosting serves to magnify this risk due to higher volumes of sites utilising these access points.

Security

Security in the public cloud space carries many of the same risks as shared hosting since, at some stage in the infrastructure, you will be sharing an IP address, and if this is compromised there is a risk that your data may also be compromised (unless your application has been coded using secure coding principles). You may have read others talking about the risk that your hosting company may have to give up its data to law enforcement agencies if they are subpoenaed, but this is true of any hosting company and any form of hosting and there is nothing you can do about it.

Back to your site security – your site may be vulnerable to, or a target for, hacking. Sites built using popular open source systems such as WordPress, phpBB, Drupal, etc., need to be patched regularly and continuously to stay ahead of the day when the site gets hacked and defaced, or, worse still, user data is stolen. Bespoke sites need to be coded securely and, while they are bespoke and less likely to be attacked, need to be monitored as they may eventually get on to the radar of hackers. Security probes put a continuous strain on the CPU and consume resources almost invisibly – they hardly appear in your bandwidth stats, and probably won’t appear in your web stats. But you will have to pay for them; and this blog is an example of this – the traffic and bandwidth are low relative to the Compute Cycles that are being consumed in order to operate it.

Relevant posts on Cloud Security (although the first is a little sensational in places) are:

• Is Our Data Too Vulnerable in the Cloud? (NY Times)
• Security in the Ether (MIT Technology Review)

Moral of the story: Code securely in the Cloud, monitor how many and what types of sites are on the same IP as you, and definitely monitor Compute Cycles. If you are using open source software, patch often.

Disaster Recovery

This is often overlooked when setting up any form of hosting – the most important question in the client’s mind is “how much is it going to cost?” And they don’t usually want to pay much. Consequently, lower cost services – and this includes Public Cloud Hosting – do not include a backup option, or any means for disaster recovery. So, if there is a problem (with security, or systems failure at the hosting facility) you can quickly find yourself with no means of recovery.

It is possible to adopt the DIY approach and build your own backup and disaster recovery solutions, but good web companies prefer to specialise in one or two aspects of the whole picture – for example, design, coding, CSS, SEO, etc. When it comes to system administration and hosting, these are usually not handled, or outsourced. A good web company will look for a solution that protects its clients in the worst case, and if the (Cloud) Hosting provider does not offer these options, then the promise of the benefits of Cloud Computing can quickly be erased if your web company doesn’t address these issues.

Private Clouds may offer these third-party services as ISPs already offer for dedicated servers – these are often called Managed Services and provide an array of support from patching and upgrading servers, through to backups and 24/7 monitoring.

Moral of the story: Think about the worst case scenario, and what it would cost you to start over. Think about how you solve this issue – through the DIY route, or via third-party managed services of some sort. Talk to your web company to find out what they can do for you.

Personal Experience

I have been experimenting with the adoption of Cloud Computing and, in general things have gone well. It has also highlighted the amount of “under the radar” traffic sites like WordPress blogs get, and how new this technology is.

The benefits have been clearly demonstrated to me – the availability and scalability of the hosting environment to provide consistent performance of the website. As have the risks – random short periods of downtime due to routing issues and database server quirks.

Since Cloud Hosting is a new technology, it is suffering from the inherent issues with anything new – it doesn’t always work, and the people setting it up haven’t quite figured out all the details yet. However, this doesn’t mean it’s not ready and that you should not adopt it. If you are prepared to live with a few glitches (like unexpected downtime when a database cluster has an issue, or an access point gets routed back on itself by the team setting it up and all the websites it serves disappear for an hour) and put some disaster recovery in place (which you should do whichever hosting service you use) then you will be ahead of the competition. Remember that many of your competitors probably used virtual, shared (cheap) hosting and suffer from the same sorts of issues – unexpected downtime, no disaster recovery, and little or no support – so you’ll be getting a better future-proof platform with lower mid-term risks once the ISPs sort out the complicated details of operating this new type of fluid environment.

My company has been using managed dedicated servers from Rackspace for some time now – these are about the best in the business and benefit from 24/7 monitoring and a team on standby to intervene if anything happens to your own database or web server. Issues are resolved within a few minutes. It’s great.

A move to Public Cloud Hosting – to enable greater scalability of business (ours and our clients) at affordable rates – introduces risks which we will need to mitigate to be truly effective. The Public Cloud is managed 24/7 – it has to be to be viable as a business for companies like Rackspace, Amazon and others – but resolutions to issues take more than 5 minutes as they affect much greater sections of infrastructure than just a single server when it has a problem.

Moral of the story: The Public Cloud is a fantastic opportunity but there are risks which need to be mitigated. If you are going to adopt the Public Cloud as a platform to grow your business, ensure you understand the risks and partner with companies that understand them also. This will ensure you mitigate the risks and enjoy good results from your chosen hosting platform.

The Thing Private Clouds Can Do that Public Clouds Can’t | Cloud Computing Journal

Unfortunately, the main argument outlined was actually one of business process engineering, and the writer claimed that adopting the Private Cloud would highlight your inefficiencies and help you streamline your processes while the Public Cloud could not do this.

Sadly, there are numerous examples of companies adopting virtualisation technology (a precursor to the Private Cloud) that have still fallen foul of the same problem by not fixing their operational processes, leading to parts of their IT inventory being underutilised or not working as they should. This shows that the Private Cloud has no bearing on the improvement of operational efficiencies, and this looks like another case of leveraging the term “Cloud” in just because we can.

Having been a management consultant in the field of business process engineering, a company has to decide first if it wants to streamline/improve its processes: this is completely independent of the technology involved. I believe that the 3 Ps (People, Processes, Products – ie technology), considered in order, make a better company and not the other way around.

Later the author talks briefly about the impact of DDoS attacks on Public Clouds and that these attacks are hard to spot and difficult to resolve due to the large scale of the Public Cloud. I touched on this at the end of my recent post on hosting types, and agree that these types of attacks are harder to spot and take longer to fix in Public Clouds than Private Clouds simply due to the relative scale of the Public Cloud to the Private Cloud, but then if you added a thimble of water to a lake you’d probably not notice the difference, but if you added it to a glass you’d be able to spot the change more easily.

For a good insight into thoughts on Private Cloud, read Private Clouds: A Valuable Concept or Buzzword Bingo? and Why Cloud is at the Top of the CIO’s Priorities.

In this revision of the 2006 post I will add a summary of each of the types of hosting including Cloud to clarify the terms and help provide a clearer picture of the marketplace. This is very much an overview of the types of hosting and not an in-depth discussion of each; a hosting 101.

Shared Hosting

Shared hosting is the starting point for most businesses. It offers a low-cost entry to market, but has pitfalls and usually offers little guarantee of reliability or support.

Cheap
Appears to offer a complete package
No sysadmin skills required
Multiple points of failure
Lack of support
Lack of control
Risk of poor performance

While many users of shared hosting report no problems with the service, there are many others who have experienced them. The principle source of issues comes from the fact that you are sharing the resources of a single server (ie a single computer like the one on your desktop) with many other users. This sharing also extends to email systems and both can be prone to abuse. Potential breaches or performance problems on websites outside of your control can take down the server and leave your website offline for prolonged periods. Also, since the IP address (the address of the computer on the Internet) is also shared, your email may eventually be considered as spam because somebody else on your server is sending spam (and both your email and theirs track back to the same IP address).

Virtual Private Servers

By using virtualisation, a single server can be partitioned into what appear to be multiple servers. This provides you with a private (or dedicated) space on the server, as well as a dedicated amount of resources – disk space, compute cycles, bandwidth, etc. This gives you more control and generally better performance but can still suffer from edge cases of shared hosting like the server being offline (although this is rarer as problems in another virtual private area are usually ring-fenced and prevented from leaking into your space by the virtualisation technology, but it can still happen).

More Control
More Reliable
Usually requires self-management, and therefore deeper sysadmin knowledge
Easier to break if you don’t have the skills, but this can be outsourced
Other virtual servers on your server may disrupt your service (e.g. bandwidth)
Single point of failure (it is still only one server)

Dedicated or Co-Location

With a dedicated server, you remove all of the third-party risks as the server is for you and you alone. You also usually get the option of defining an SLA with the data centre where the server is hosted to guarantee performance, so you also get better reliability. For example, with Rackspace (our company hosting partner) you get 100% network availability.

Complete Control
Guaranteed Reliability through SLAs
External data security risk mitigated through SLA
Corporate Governance risk mitigated through SLA
Expensive
Single point of failure
Sysadmin skills essential unless the server is under a managed contract

Clustered Servers (aka Private Cloud)

For larger enterprises, there is a need to ensure consistent performance and reliability. This is usually achieved through a set of clustered servers which share the load (load balancing) of the required performance. The content and applications are also mirrored across the cluster to ensure that performance is always maintained at an optimum level no matter what. This is more expensive but removes the single point of failure risk as, even if one of the servers breaks down, the rest of the servers keep running and delivering results of visits to the website or application.

Complete Control
Guaranteed Reliability through SLAs (if outsourced)
No Single point of failure
No external data security risk
Corporate Governance Assured
Expensive
Sysadmin skills essential unless the cluster is under a managed contract

With the adoption of Cloud terminology, the Private Cloud is essentially synonymous with Clustered Servers. It is simply an application of new jargon to existing infrastructures. Sadly, matters are further confused by everybody adopting the new jargon and applying it to associated tools and services – such as virtualisation. We have the marketing people to thank for that one!

Hybrid Cloud

A hybrid cloud is simply an environment that uses aspects of both private and public cloud services to deliver the required service.

Public Cloud

See also Cloud Computing vs Dedicated Servers for some of the considerations companies need to make when deciding between Cloud or Dedicated servers. Public Cloud Hosting (see Cloud Computing for a description) is a large cluster of servers that provide all your hosting requirements in an elastic manner, scaling up and down as you need it in response to demand for your web applications or websites. It is generally paid for as a utility, meaning you only pay for what you use.

Less Expensive
Fully managed by a third party, meaning better reliability
No performance issues – it scales as needed
So large that external factors may affect your site and may take a long time to resolve (see below)
Difficult to assess external data risks and corporate governance issues

Because the public cloud is such a large virtual space, there can be huge volumes of websites and web applications operating within it. If one of these goes wrong and starts demanding lots of resources, the cloud will adapt to fulfil its needs. However, since the cloud is so large, this anomaly may not be detected for some time. There have been accounts of problems in Amazon’s ECC (elastic compute cloud), and others, where things like DDoS attacks have taken down large parts of the cloud. These issues are relevant to any type of hosting – and not just cloud – but in a public cloud, their detection and mitigation is often harder and longer to achieve because of the fluid nature of the environment. On the positive side, the cloud is more resilient to such attacks because it is fluid – a single server (shared or otherwise) would usually suffer immediately, although the resolution is easier to pinpoint.

However, the post just told me there was a lot of debate about the issue and that a task force was working towards a definitive definition.

Not much use, so I thought I would add to the corpus of articles and definitions by publishing my (Emissary’s) definition of Cloud Computing.

Cloud Computing is the technology used for the provision of web-based resources (i.e. storage, compute cycles and bandwidth) for web-based activities (e.g. content delivery) to a third-party without the third-party needing to understand how the resources are provided or needing to worry that there are enough. To use an analogy, the provision of the service of Cloud Computing is like the provision of electricity – it is a utility in the true sense – because the user of the electricity does not worry how it is generated and is able to consume as much or as little as they need for their purposes. Cloud Computing, like electricity, is then billed in accordance with how much is used.

Because this is a relatively new term, it is often applied to everything and anything so that companies can sound like they are at the cutting edge of technology. The most commonly associated utility with Cloud Computing is Software as a Service (SaaS). In general, this is provided on a licensed basis which is usually calculated on a per-user, or per-client basis. While it is a utility, unless it is delivered from a fully-scalable, black-box server infrastructure that meets the definition of Cloud Computing as set out above then it is simply SaaS. Another service commonly associated with the Cloud is virtualisation technology because it provides a black-box service to the end-user. However, unless it scales and provides the flexibility that a true Cloud should, it is simply a means to abstract technology knowledge from the end-user.

The reason that it is easy to blur the line between technology such as SaaS or virtualisation and Cloud Computing is that they originate in the same place – on a server somewhere out there on the Internet. By the same token that a kettle or toaster are not simply called “electricity” we should be clear that a program (e.g. website or virtualisation tool) running on a server infrastructure is not Cloud Computing, but may use it.

For further reading, please read my previous article Cloud Computing vs Dedicated Servers.

Related articles by Zemanta

• Big Pharma Exploring and Moving Data to the Cloud – IT Execs Talk about How It is Being Done (ducknetweb.blogspot.com)
• Amazon offers more cloud control (news.cnet.com)
• Akamai Edges Into the Cloud, Surveys State of the Internet (xconomy.com)
• White House Leading Cloud Computing Charge (elasticvapor.com)
• Sun’s new mantra: Call us the ‘cloud company’ (news.cnet.com)

The reason is principally one of reliability and accountability, or more to the point that you can call somebody at 3am when the dedicated servers that you are paying hard currency for fail and know that somebody is feverishly scurrying around a data centre ensuring your SLA is upheld. As Ted Dziuba put it:

No matter what the name, you, the developer, will still be dealing with reliability and accountability. Using someone else’s infrastructure for your application will forever be a business risk, but it sounds so much less so with a cuddly name. Your CTO will fall for the next cycle pretty easily. The compunction he feels for his latest data center build-out will outweigh the downsides of an external dependency.

Clouds have been notoriosly unreliable in the recent past (I am sure this will be remedied as Clouds are in their infancy in terms of infrastructures) and it can be very embarrassing when your data goes off-line for a long period, or your applications are down without warning. More to the point – who do you call, and how do you know they are fixing “your” problem when you are just renting a small corner of a nebulous, fluid environment (aether) which (theoretically) provides failover and mirroring to prevent just such an occurrence? When one server goes wrong it can be more easily diagnosed and fixed, but when a segment of the Cloud goes offline, it may be symptomatic of a wider disturbance in the aether.

If you are using Cloud-based systems, you might like to check out Hyperic‘s Cloud Status Monitor at http://www.cloudstatus.com/