Components of Cloud Computing

In this video, we'll examine the key components of cloud computing, beginning with the client infrastructure, which, of course, provides the consumer with the means to have some kind of graphical user interface to be able to access the services of the provider.

Now, from the perspective of the customer, that infrastructure itself is built, hosted by and maintained by the cloud services provider, in almost all cases in the form of a website that allows customers to log into their subscription to access the services they need.

One of the more commonly used terms is portal, but no matter which term you prefer, once signed in, clients have the means to access all available applications and services of the provider, while requiring nothing more on the client side than a browser.

Now, depending on what type of solution is ultimately configured by the customer, those who actually access and use that solution may need more than just a browser on their local devices, but in terms of simply accessing the services and resources of the provider, the client need only use a browser to sign into the provider's site and begin creating the resources necessary to support their needs.

Now, the services of the provider are generally divided up into three categories, although newer and more specific versions of these services are appearing regularly, but they're known as Software as a Service or SaaS, Platform as a Service or PaaS, and Infrastructure as a Service or IaaS.

Now, we'll take a brief look at all of these in just a moment and a more detailed look at each one in some upcoming presentations, but what I'd like to also point out here is the nature of the graphic, whereby we see infrastructure at the bottom, platform in the middle and software at the top. And this is accurate because, although as a client, you can subscribe to any one or all of these types of services, each of the upper layers is built entirely on those below.

Now, that will become a little more clear in just a moment but in short, even though you can subscribe to services at, let's say, only the SaaS level, software needs a platform on which to run and platforms are built on top of infrastructure. So to hopefully clarify that a bit more, let's start with the lowest level of infrastructure.

Here is where you can begin to build solutions using actual hardware, operating systems and networking components. Now, recall that as a customer, all I have access to is a browser, so clearly I'm not directly working with actual physical hardware. But I can access and configure the services of that hardware.

Now again, we'll take a more detailed look at each of these levels in some upcoming presentations, but let's go with a quick example of needing a virtual machine to act as a web server.

Once signed into my subscription, I can use the interface to configure the desired specifications of that virtual machine in terms of how much memory it should have, what kind of storage and what kind of processing capabilities, the operating system I prefer to use and the web server component that I prefer. Now, you may not be able to do all of that in a single configuration pass, but that will depend on the provider.

For example, you may have to install the web server component after the virtual machine is up and running. But what matters at this point is that the resulting system would be no different than if you sat down in your own physical office, grabbed a nearby physical computer, reconfigured the actual hardware as needed, installed a fresh operating system, and added the web server component.

In both cases, you end up with a system on which you can now host websites. In other words, you have constructed the infrastructure necessary for the higher level service of the websites. The only difference is where they're located.

That said, however, I should point out that the process of assembling that infrastructure is significantly faster in the cloud. Physically constructing that server in your own local environment could take hours, possibly even days to complete if it's a complex configuration.

But in a cloud environment, you literally just choose those configuration options from an interface, and the provider creates that system as a virtual machine running on one of their physical servers, using preconfigured images of the operating system with all software likely already installed.

So the system can literally be up and running within minutes. Now, I'm going to skip over Platform as a Service for just a moment and talk about Software as a Service, which is at the opposite end from infrastructure. And I'm doing this because it's easier to envision the role of Platform as a Service once you understand the other two levels.

So Software as a Service refers to an overall application which can refer to a service or a piece of software or both. Now, what does it mean to say a service? Well, in this context, it's simply something that can be used by any consumer, including hardware devices, without needing any particular type of software.

For example, our mobile phones have access to cellular services. As a consumer, I don't need any particular type of mobile phone nor any specific application on that mobile phone to be able to get service. It's just there. Sometimes there is some level of software required, but it doesn't have to be anything specific to the service itself.

And the most common example of this is a browser. We can all use browsers to access a tremendous number of services, such as audio and video streaming, online banking, retail shopping, making reservations and many other services. But all of them can be done through any general internet browser.

Software, however, as compared to a service, tends to be a little more specific in that is usually designed for a specific purpose. For example, word processors are designed for creating and working with documents. E-mail clients are designed to send and receive messages and book appointments in meetings.

So again, either or both can be accessed and used in a Software as a Service subscription. But the distinguishing factor here is that there is no infrastructure, at least none that you have to deal with as a customer. So let's go back to the previous example where I was wanting to build a virtual machine to act as a web server.

Using Infrastructure as a Service I can absolutely do all of that and have a perfectly good web server on which to host my sites. But what if you don't want to deal with the server at all? That's where SaaS comes into play. I can create just the website if I want and leave it to the provider to manage the underlying infrastructure entirely.

So it really comes down to what you want or need. By configuring the virtual server yourself, you have as much control as you like and you can manage the server however you see fit, but you have to manage it. If you aren't concerned with any of that, then creating only the website in an SaaS configuration might be a better option.

But then you have almost no control over the server itself. So again, it's what's important to you and your needs. Platform as a Service, then, falls somewhere in between the other two layers, meaning that there is a little bit of both. Now, in short, PaaS is most commonly used as a development solution to ultimately provide a runtime environment for whatever application or service will be developed.

But again, there would be a need for some level of infrastructure and some level of software. Let's go back to my website that I want to host, but now let's also include a database so that the website is being used to accept retail orders from customers, and those orders are being placed into the database.

So let's imagine that if I'm a developer, and as the developer of this solution I already know that I need at least one database server and at least one web server.

But the key statement here is: as a developer, meaning that I know that I need those servers, but I really don't want to have to deal with configuring every aspect of those servers in terms of hardware, operating systems, security configuration, updates and everything else that goes along with managing those servers after the fact.

In other words, I'm not an administrator. I'm a developer. Every aspect of what I just listed out is what you might do if your subscription was entirely IaaS-based. So what I can do is to define the specifications of what is needed for the servers as part of the overall code being constructed.

And virtual machines will be assembled as per those specifications. But once assembled and running, again, it falls to the provider to maintain those servers. As the developer, I only need them for what they can do for my solution. But it's not up to me to manage those servers day in and day out.

With the infrastructure defined, I can then begin working on the website component to accept customer orders. So I've used the infrastructure to create a platform upon which I can build the service I'm providing to the customers. In other words, I've used some infrastructure to create some software or services, but the management of that infrastructure is left to the provider.

So with PaaS, the focus tends to be more on the end result of the software or services being created, but with the realization that there needs to be more control over the required infrastructure than what might be available through just an SaaS solution, which, again, is why I say that PaaS falls somewhere in between, and hopefully why understanding the two opposite ends first makes it easier to understand the middle ground.

Finally, the last component is, of course, the Internet, which facilitates all communication between the front-end client interfaces and the back-end components of the provider. Now, this might seem like a rather obvious component, but it is worth mentioning because it's important for all decision makers to realize that cloud solutions are 100% dependent on having Internet access.

Now, that's true of a lot of services these days, but before making any commitments to a cloud-based solution, an organization needs to understand what kind of an effect a disruption of Internet service could have on that solution. Now, that doesn't really refer to localized outages, such as power failures or issues at any given local Internet service provider.

For example, if your services are up and running, but a client can't reach you because their own Internet is failing, that certainly isn't your fault. But consider a disruption of service at the cloud provider. That would affect all customers. Or if you also consider a disruption of your service with your ISP, that would prevent you from getting to your own solutions.

In short, it needs to be determined how those types of disruptions would affect you and whether there are any means to address them such as using redundant connections or implementing service-level agreements with the cloud services provider, that will define what happens in the event that Internet connectivity is lost.

Ultimately, any given cloud solution will require at least the client infrastructure in the form of the front-end interface that you as a subscriber will need, a subscription that implements at least one of IaaS, PaaS or SaaS, or any combination thereof, and, of course, an Internet connection that is as reliable as possible.