Cloud Computing, for those who have to implement it

This is part 1 of an occasional series introducing cloud computing.

It seems to be that the computing industry - more specifically, the people in the computing industry - are split into two types. There’s the engineers who are actually making the product. We deal in concrete things. We use a tool because it fits our needs. But then there seems to be a whole world of the other type of people - CTOs and CIOs, analysts and industry experts. Although both groups are ultimately talking about the same thing, it’s in completely different terms, and in fact nearly a different language. This second group are almost exclusively working around multinational enterprises with many layers of management and thousands of servers. It’s hard for a software engineer like me, working at the coal face and writing code every day, to understand the relevance of this second group’s discoveries.

Take, for example, this press release: Gartner Says Relevancy of Search Results Can be Improved by Combining Cloud and Context-Aware Services. Well, good. As a software engineer I want my product to work well, and search is an extremely important aspect of usability. It’s galling to see a user go to your website and, say, search your city directory for “libraries”, only to get zero results back. Why? because the relevant pages are titled “Something Library“, not “Libraries“, and your search algorithm isn’t smart enough to distinguish plurals. So how would we get more relevant results? Well, database full-text search is obviously a starting point, and there are some interesting natural language processing tools out there. Perhaps one of these fashionable NoSQL databases might help - a graph-oriented database would help with linking concepts and therefore relevancy together. Or there’s Apache Lucene, which has a very good reputation. So that’s where my mind goes when thinking about increasing search relevancy - to the concrete, the tools that I can download and evaluate for my project.

But this press release goes down a completely different track. It talks about using cloud-based services for search, but doesn’t ground this into anything concrete that I can get my head around. There’s precious few reference points that I can use to relate this article to what I know about. Amazingly, it’s predicting that “more than 20 percent of revenue-facing external search installations will incorporate context gathered from cloud sources“, by the end of 2015. That’s nearly four years away! That’s unbelievable!

But then I think about it harder, and it becomes possible to think of examples that become my reference points. Cloud-based services for search, and context-aware services for search. Google does search. Google is a “cloud”. My website has its own specific context (widget sales, for example.) Link the search on my website with Google - say by integrating my widget suppliers website with Google Maps. The maps appear on my website, the widget suppliers come from my database, Google draws the maps, Google can use its location detecting to centre the map on the widget suppliers nearest the user. Cloud-based search services. Put it in that context, and now I can easily believe that 20% of external search installations will incorporate context gathered from cloud sources, within the next 4 years.

So here is my goal for this post: take the lofty and wordy analyst-speak on the subject of cloud computing and give you, the software engineer, the real world descriptions and examples to tell you that this is for real. “Cloud” is in danger of being overused to the point it is meaningless, with services that you’ve used for years suddenly being “rebranded” as being in the cloud! But when you break it down, there are real concepts there, and they can help you today - not four years into the future.

Firstly, “cloud” has a taxonomy, generally referred to as SaaS, PaaS and IaaS. Some folks will try and invent new -aaS (ahem) technologies, but you can normally treat these as you would a fashion magazine telling you that “- is the new black.” So this taxonomy is where we will start…

The acronym: SaaS

What it stands for: software as a service

In a nutshell: a web application. Instead of buying a boxed product and installing it on your machine, you buy a subscription (usually paying monthly) and the application is hosted on the internet.

Give me an example: Salesforce.com is the first major example of software as a service, and in fact coined the term. There’s now loads of them - GMail and Google Documents, Github…

This is pretty much the starting point of cloud computing. In fact, “software as a service” was a recognised term before “cloud computing.” Initially, Salesforce.com was purely what you would call a web application, specifically targeted at Customer Relationship Management (although later they started doing PaaS too.)

A similar thing happened with GMail: this was a webmail service,  but then at some point the terminology changed, and businesses who used corporate GMail weren’t using webmail: they had put their email in the cloud.

So SaaS essentially means “web application”.

The acronym: PaaS

What it stands for: platform as a service

In a nutshell: you write code for your application based on a framework (Java servlets, for example.) You load this on to the platform-as-a-service, and it will host your application and take care of scaling it out to meet demand.

Give me an example: Google AppEngine, Heroku…

This is probably the most interesting category of cloud for most software engineers, because this is all about having somewhere to run your code. On the surface of it there will be typically be a programming framework. For example, Google AppEngine supports the Java servlet standard, or Python. Heroku will run any Rack-compliant Ruby framework. Amazon’s Elastic Beanstalk has hosting based on Tomcat (and a silly name.) They may also be based on proprietory frameworks - for example, Salesforce’s PaaS Force.com uses a proprietory framework called Apex.

It means you don’t have to think about infrastructure issues, hardware or software - it’s somebody else’s responsibility to get the web server up and running for you, you just have to upload your application. A PaaS provider will usually have some extra features that take advantage of the cloud - for example, Amazon Elastic Beanstalk will automatically scale out and scale back VMs to run your application, depending on how heavily loaded they are.

The acronym: IaaS

What it stands for: infrastructure as a service

In a nutshell: renting hardware and network infrastructure, being able to provision and decommission hardware by the minute, if necessary

Give me an example: Amazon EC2 is probably the most well-known example.

Infrastructure is the physical part of the cloud - the actual servers, switches, routers and network connections to the outside world. You can view this pretty much as server hosting. Where it differs from classic server hosting is in the speed at which you can deploy or rollback hardware. With a classic ISP datacentre, you would typically have to sign a 12-month minimum contract, pay an up-front setup fee, and wait a day or two for the payment to be invoiced and processed, and then for an engineer to physically deploy the server. With IaaS, you would typically invoke a web service call, and a couple of minutes later you are given the IP address and SSH keys of your new server. When you’re finished with it, another web service call and a few minutes later your machine is gone and you are no longer paying for it.

The main advantage of this over classic server hosting is the speed at which you can respond to changes in demand. You no longer have to plan for the heaviest-load scenario and purchase hardware to manage that level, which is then left half idle at quiet times. At any time, you need only be paying for as much hardware as you actually need. You can scale out, and back, within minutes.

IaaS is typically implemented as virtualised machines (although technically it doesn’t have to be virtualised) so you don’t actually get a dedicated server. However this can also work to your advantage, in that you will typically get a choice of how much compute power, memory, etc. that you actually want (Amazon EC2 does this by offering “small”, “medium”, “large”, etc. instances) and gain from lower prices if you don’t need the higher powered instances at any particular time.

Coming up in the next article in this series: a quick-start guide to Amazon EC2