Types of Cloud Services

Published: by

In the previous article, we discussed what the (terribly overhyped) word "cloud" means. Before we start to delve into the difference between "true cloud" and "we just call it cloud", let's look at the different major categories of "cloud" services available.

As we discussed previously, cloud services replace:

  1. Expertise with consumption
  2. Capex with opex
  3. Fixed costs with metered prices

Unsurprisingly, you can use that model with any technology you consume. The key element here is consumption-as-a-service. Everything that is cloud gets consumed as a service, just like electricity.

Here are the major technology use cases and their cloud equivalents.


Situation: You have your own software you want to run on a bunch of servers. You developed this software in-house to run your trading platform, or you purchased it, perhaps a clinical management system like Sunrise for your hospital, customer relationship management (CRM) software like Dynamics from Microsoft or SugarCRM, or Enterprise Resource Planning (ERP) like PeopleSoft or SAP. It might even be a straightforward Oracle or MySQL database you need to run for your own purposes.

Option A

You could buy servers from Dell or IBM, put them in your data centre, install an operating system, monitor and operate them, and then install and run your own software. You will incur the CapEx of purchasing 3x $10,000 servers from Dell, acquiring the floor space, paying your team to wire up the patch panels, buying network ports on your switch from Cisco, as well as backup disk or tape space, additional cooling capacity, etc. All of this time you need to have your staff available, and they need sufficient expertise to do this work.

To be clear, this is not a bad model; it works extraordinarily well for many business situations.

Option B

You go to a cloud provider of infrastructure, purchase virtual server instances, and pay for what you use. As an example, a moderate m3.medium from Amazon Web Services in US East Region (Northern Virginia) costs $0.070 per hour, or $613.20 per year. For the 3 servers, it will cost you $1,839.60 per year or $5,518.80 for 3 years.

These prices can be even cheaper if you know you will use it for the whole year and pay an upfront fee to discount the price. Additionally, Amazon is continually lowering prices as their costs go down.

In this model, there is no wiring or cabling, no hardware, no network ports, no firewalls, almost no, well, anything. Your cloud provider, like Amazon, takes care of it for you. Your responsibility begins at the operating system level, and Amazon has plenty of prepared images ready for you as well.


You are looking for infrastructure, you can buy it on your own, or buy it as infrastructure-as-a-service, or IaaS, from Amazon, Rackspace, DigitalOcean or HP.


If infrastructure is at one end of the spectrum, software is at the other end. The only reason you have infrastructure in the first place is to run software. After all, a server does not provide any business value; CRM software running on the server provides business value.

So you need a great customer relationship management (CRM) package to keep track of all of the complex accounts and relationships in your fast-growing business. Where are you going to get and run that software?

Option A

As with the infrastructure, you could buy the software, like Microsoft Dynamics CRM or SugarCRM, and install and run it on a server. Whether you use your own server or an IaaS instance is irrelevant to the software part of the discussion. But once you decide where you will run it, you need to:

  • Install the software
  • Maintain the software
  • Manage the database
  • Ensure access for your people
  • Integrate with email and other systems
  • Manage security, both system and account
  • Run backups
  • Debug issues

In other words, you have a lot of ongoing activities to perform around the software itself, and need the manpower and expertise to do so.

In addition, while some software is free, others are quite expensive. Whether opex or capex (depending on your software purchase accounting rules), it can add up.

As before, there is nothing wrong with this model; it makes sense in many cases, as long as you are aware of the commitment upfront.

Option B

Conversely, you could wash your hands of the whole thing and ask someone else to manage it. Salesforce.com is the most well-known and one of the largest, with a market cap of $36BN as of this writing.

With salesforce, you have nothing to do but use the software. You pay per user per month, and access it from anywhere in the world using your Web browser.

This model provides 2 special advantages beyond the infrastructure benefits:

  1. You do not need to know or manage the software itself.
  2. You do not need to handle application deployment and scaling.

Is this simpler? Absolutely. There is a reason salesforce has a $36BN market cap! Is it cheaper? That depends on how big your installation is, how much expertise you have in-house, and probably how much of a deal you can negotiate with salesforce.


You can buy, install and maintain software, or you can purchase software-as-a-service, or SaaS.

Custom Applications

What about the middle ground? What if you want all of the benefits of SaaS - application management, database management, scaling, perimeter security, backups, etc. - but for your own software? You wrote a great application, want to roll it out to your thousands of customers as a service for them (your SaaS for them) - whether internal IT customers or external business customers.

Option A

You buy some servers and run your software on your own infrastructure, or you rent IaaS instances, just like with our CRM example.

Option B

Is there an option B? If you look at the previous SaaS model, there actually are two unique benefits: application knowledge and application management. While there is no way you could get the application expertise benefits of SaaS - after all, this is your own software that no one else knows - you would at least like to get the benefits of application deployment and scaling that SaaS provides.

Along comes the platform-as-a-service, or PaaS. These providers take all of the common management functionality of a SaaS, and allow you to run your own software on them.

Would you have more control running it yourself, either on your own hardware or on AWS server instances? Absolutely. AWS provides far more granularity of control and power, as well as significantly lower costs, than any PaaS provider. But to do so you would need to invest significantly in managing the application management and deployment process.

In many cases - and most smaller or early-stage deployments - PaaS providers provide a deployment solution that is several orders of magnitude easier and quicker than using IaaS.

Some PaaS providers include: heroku (bought by Salesforce in late 2010), EngineYard, nodejitsu, and Amazon's own AWS version Elastic Beanstalk (no, I do not know who comes up with these names).

Through this past summer, I designed, set up and ran solutions for a customer using AWS IaaS and Heroku PaaS. While the PaaS had shortcomings in its flexibility and control, its simplicity and ease of use was more than sufficient to compensate for those in an early stage product.

Other Categories

There are other categories of products that have been made available "as a service". If you can think anything that you can run on your own but could also have someone run for you, someone has made it available as a service.

One notable example is Database-as-a-service (DBaaS), which is exactly what it sounds like, using a database provided as a service, with all the usual management, administration, scaling and backups provided as a service. A notable example is Cloudant (bought by IBM) and Amazon's own offerings, such as RDS, DynamoDB, SimpleDB and Redshift.


There are several different categories of "cloud" or "as-a-service" offerings. All, however, share the same basic characteristics, no matter the level of the technology stack at which they work and offer: infrastructure, software, platform, or anything in between.

  • Opex instead of capex
  • Metered pricing
  • Complete and total customer obliviousness to the underlying design


I have helped clients design for and migrate from/to all of the above:

  • Private to cloud infrastructure
  • Cloud to private infrastructure
  • Cloud infrastructure to platform-as-a-service
  • Platform-as-a-service to cloud infrastructure
  • Local software to software-as-a-service
  • Software-as-a-service to local software

But the most interesting, and most complex, challenge has always been getting a company that already has a software product make it into a cloud service offering, or become a SaaS provider. This type of transition into "true cloud" is far more complex than just running it on a bunch of servers! It affects architecture, sales, engineering, organization, product management, marketing, finance and corporate culture  itself.

In our next article, we will look at the difference between "true cloud" and "labeled cloud" and why it matters so very much to your bottom line.

In the meantime, if you want to know how to become a cloud provider, ask us.