Over the past year, I have written about the various primal layers of Cloud Computing. Typically, my role is to “over simplify” in order to make the Cloud a bit more palpable by “the masses.” My colleague, Randy Bias, is the resident über-tech, so I usually leave the more complicated developer and sys-admin posts to him. As we all know, the Cloud is hot and becoming increasingly complicated as new products, services and vendors throw their hats into the ring. But is this over-complication confusing and saturating the market? I think not, in terms of the latter, but it is truly becoming more confusing.
First, we at GoGrid, broadly define Cloud Computing as such (latest definition):
On-demand self-service Internet infrastructure where you pay-as-you-go and use-only what you need, all managed by a browser, application or API.
Even that definition I feel is a bit skewed toward Infrastructure. Probably more aptly defined, it would be:
On-demand, self-service Applications, Platforms, Services or Infrastructure dynamically consumed on a pay-as-you-go basis using a browser, application or API.
Definitions evolve and morph over time. This is probably the 30th iteration of our definition over the past year.
So I will circle back to the Cloud Pyramid (as seen below):
To briefly recap the different layers:
- Cloud Applications – many view this layer as containing SaaS (Software as a Service). It’s important to remember that not all SaaS offerings fall into this category. SaaS existed well before the term “Cloud” came into play. Essentially, the idea is that Application functionality is served via the internet and this application typically does one thing. This could be email (e.g., Gmail) or CRM (e.g., SalesForce).
- Advantages – available via a web browser, rich interfaces, frequently free or paid either by monthly usage or seat licenses
- Disadvantages – little or no customization available, limited to the feature-set provided
- Cloud Platforms – otherwise known as PaaS (Platform as a Service). Typically a development language or framework (e.g., Ruby on Rails, Python, .NET, Java) is contained within this environment. What this means is that users consume the hosted framework. Examples are EngineYard (a RoR stack hosting environment), Google App Engine (supporting the Python framework), Microsoft Azure (running .NET framework) and Force.com (proprietary SalesForce.com framework) for example.
- Advantages – the frameworks are hosted by vendors. This means that the underlying infrastructure is controlled, updated and managed by Cloud Platform vendors.
- Disadvantages – while offering significant more control over the development environment, because the underlying infrastructure is not available to the end-developer, these developers are “at the mercy” of the hosting provider to ensure updates and management of the various framework stacks are fully functional, updated and accurate.
- Cloud Infrastructure – this is called IaaS (Infrastructure as a Service). At the lowest layer of the Cloud Pyramid, infrastructure is delivered and consumed on-demand utilizing some sort of paravirtualization and/or hardware integration. This layer includes servers, networks and other hardware appliances (e.g., load balancers) delivered as either Infrastructure Web Services (e.g., Amazon Web Services) or as “cloudcenters” (e.g., GoGrid). More information about the differentiation we make between Infrastructure Web Services and Cloudcenters is discussed in the posts here.
- Advantages – full control over the various components of infrastructure means that you can work with the infrastructure in just about any way you desire. It also lays a fundamental groundwork for building other Clouds on top of it (especially Cloud Applications)
- Disadvantages – sometimes more expensive compared to the other layers; if you aren’t familiar with full access to infrastructure, controlling and managing could be daunting.
- Other Cloud Services – there are many types of ancillary Clouds that are showing up including: Cloud Services, Cloud Storage, Cloud DB, Cloud Aggregators, Cloud Extenders, Cloud Management, etc.
Obviously, this just scraped the surface of the Cloud. But let’s take a quick look at one particular “application” which can span all layers of the Cloud.
Microsoft Exchange is probably something that many of you are familiar with. For the uninitiated, Microsoft Exchange is a messaging and collaboration application developed by Microsoft and is contained within its line of server products. Functionality includes email, calendaring, contact management and tasks. Why have I chosen Exchange as a good example to use for traversing the various layers of the Cloud? Simply because some form of Exchange can conceivably exist at each layer. Let’s explore Exchange on the…
- Cloud Application layer – you want all of the functionality of an Exchange account but don’t want to worry about the management thereof. At this level, you get just that, the ability to have a hosted Exchange mailbox with many of the bells and whistles of a standard corporate Exchange account but without the fuss. Billing for this is typically by user by month, typical of many SaaS or Cloud Applications.
- Cloud Platform layer – suppose your corporation outgrows a simply leasing of individual Exchange mailboxes as present within the Application layer, you can then opt for a solution of a dedicated Exchange server, hosted by a provider. While more of a dedicated play, conceptually, the idea is the same. You choose a hosting provider who manages the infrastructure (the experts) and “frameworks” and you simply administer the usage and functionality therein. Providers integrate other functionality (e.g., web access) into the product offering while still protecting the underlying infrastructure. Companies have more control at this layer.
- Cloud Infrastructure layer – assuming that your company has grown to the point where you need a more robust corporate infrastructure, you probably are looking at setting up a clustered Exchange environment. At this layer, you would need to have full access and control over your infrastructure in order to set up Active Directory and other protocols. Hosting with dedicated, the cloud or a hybrid solution (e.g., using Cloud Connect) is the best implementation here.
With the Cloud, you can grow your infrastructure based on the demand and needs of your company. The Microsoft Exchange example can just as easily be applied to moving your Web Application through the different layers of the cloud as well, for example a CRM application.
While this is not exactly a true “Cloud play,” I hope that it helps to explain how the layers of the Cloud Pyramid are differentiated in terms of control, scalability and functionality. You could also use an example of Ruby on Rails or Python (at least for the bottom two layers). With Google App Engine or EngineYard, you work within the languages and frameworks available. If you move down to the Infrastructure layer, you can do that as well, but you also have the ability to control the underlying infrastructure and customize the framework environments to your liking. Unfortunately, I’m a bit hard pressed to explain how frameworks can be utilized at the Cloud Application level, but I’m open to other comparisons or examples.
What other applications or environments can traverse the Cloud Pyramid? I’m sure there are many!
Latest posts by Michael Sheehan (see all)
- James Gosling to Speak on Innovation at GoGrid Cloud Meetup on 5/22 - May 16, 2013
- Advertising in the Cloud - May 2, 2013
- How To Enable & Manage the New, Free GoGrid Firewall Service - May 1, 2013