The Cloud Defined

Cloud computing is very similar to traditional on-premises computing. It's a lot of the same technologies just being used in a bit of a different way.

Some of the factors to think about when we compare cloud computing with on-premises computing is availability. For example, imagine that you depend solely on services running out in the Microsoft Azure cloud, yet you've only got a single Internet connection from your office. So if that link goes down, we lose access to everything. All the systems, all the data that we've provisioned in the cloud. If that was solely on-premises, we would still have access to it. So the solution is to have redundant network connections to the cloud provider environment.

When it comes to software and licensing and hardware, with an on-premises network, that is all the responsibility of the private organization. Acquiring hardware and software and licensing the software, configuring the hardware and software, and maintaining it over time. In the Microsoft Azure cloud computing environment, that is the responsibility of Microsoft.

Then we have to think about the IT systems that we run in the cloud. When it comes to the underlying infrastructure, that is the responsibility of Microsoft. But it would be the responsibility of us as a cloud customer to deploy things like virtual machines on that infrastructure. The data that results from the use of cloud services primarily falls under the responsibility of the cloud consumer, in terms of determining whether they want that data encrypted and where it is stored. Although, there is a service level agreement, or SLA, that stipulates, in the case of Microsoft Cloud Storage with Azure, that there was a certain amount of guaranteed uptime. But we'll talk about service level agreements or SLAs in more detail later.

You could define cloud computing as saying that it's computing services that are made available over a network such as the Internet. You might wonder, isn't cloud computing only available over the Internet? And the answer is no, because you could have a private cloud on-premises owned solely and used only by a single organization. So in that case, it wouldn't be accessible over the Internet.

Cloud Computing Characteristics

Cloud computing shares a number of characteristics.

Resource Pooling

The first characteristic is resource pooling. What this means is that the cloud provider pools together infrastructure like storage that is made available to cloud customers, physical servers that run hypervisors that allow virtual machines to run, and all of the networking that allows that to communicate with one another. All of that is pooled together on a large scale and made available to cloud customers.

Rapid Elasticity

Rapid elasticity takes advantage of that resource pooling to allow cloud customers to implement or provision resources on a moment's notice. This includes such things as requiring more storage or wanting to fire up a virtual machine in the cloud to test something at a moment's notice.

Metered Usage

Metered usage means that with cloud computing, the amount that you use something, how long a virtual machine is running, or how much cloud storage space you're consuming, all of this is tracked kind of like a utility, like power or electricity, and so you pay for what you use. So the more virtual machines you have running in Azure, the longer they're running the more you pay than if you had fewer running for a less amount of time.

Broad Access

Broad access means allowing access over a network. And in the case of Microsoft Azure, which is really a public cloud computing solution, the broad access applies to everybody over the Internet that wants to sign up with an account.

Self-Provisioning

Self-provisioning is another cloud computing characteristic, whereby cloud customers can provision and manage and also deprovision cloud resources, like storage. Like cloud-hosted websites or cloud hosted virtual machines. All of that should be provisionable by the end user. And it's often done through an easy to use graphical web interface, although it can also be done programmatically if that need is available.

Cloud Computing Considerations

Cloud Services Available that Meet Business Needs

The other thing to consider is whether or not we've got cloud services available that meet business needs. Choosing the appropriate infrastructure like virtual machine types that will support workloads that we need to run to support business processes.

On-Premise System/Data Cloud Migration

We also have to consider whether we're going to be migrating systems that we currently run on-premises such as a website, for example, or data that we want to migrate to the cloud. Either we want to run that in parallel while we adopt cloud computing or we just want to use the cloud as an alternate storage location to run these systems and to store data.

Technical Expertise of IT Staff

We also have to consider the technical expertise of our IT staff to make sure that they understand our chosen cloud platform, such as Microsoft Azure and the service offerings that are available. And bear in mind that this is a moving target because Microsoft is constantly changing how things work in Azure. The interface, new cmdlets available in PowerShell, and so on. So technical expertise is an ongoing type of task as it relates to Microsoft Azure.

Total Cost of Ownership (TCO)

We should also consider the total cost of ownership or the TCO overtime of using cloud computing. We can't necessarily say that cloud computing is always cheaper than just doing everything on-premises. Certainly there are no up-front costs with cloud computing as there would be if you did the equivalent on-premises where you had to acquire hardware and so on. So we have to bear in mind that this is an ongoing type of operating expense based on our usage. So it's important that we track our usage of cloud resources in Azure to make sure that we're only using what we need to minimize costs.

Data Privacy and Laws/Regulations

The other consideration with cloud computing is data privacy laws and regulations. We have to think about which ones apply to our specific industry and we have to determine whether or not data of certain types is allowed to be stored in the cloud in certain data centers in certain regions around the planet.

Cloud Computing Benefits

There are plenty of benefits when adopting cloud computing, one of which is there's no up-front capital expenditure. Can you imagine having to buy 20 or 30 physical servers at the same time to handle business workloads, versus simply deploying virtual machines in the cloud to do the same thing? Now that is under the assumption that we are compliant with laws and regulations and that it makes sense to run those business processes in the cloud.

We also have to consider the accreditations that various cloud providers acquire. The security accreditations of cloud providers need to be considered. And normally they will do this so that their customers have confidence in the security of their facilities and how things are managed and secured.

When you deploy something in the cloud, it often can be done very quickly. It really depends on the expertise of who's deploying it. Certainly more quickly than us acquiring hardware on-premises and then acquiring software and installing and configuring everything. So this can be done very quickly in the cloud, such as deploying a database or a cloud hosted website in moments.

Another great thing about the cloud is that the underlying technical complexities are hidden. There's usually some kind of a graphical frontend interface or programmatic access to cloud services that often hide the true underlying complexities of the hardware used to support that infrastructure.

When we use cloud computing services ends up meaning that we are using less on-premises space in our server rooms, in our data centers, in our offices. Less power draw and also less requirements for heating, ventilation, and air conditioning since there is less physical computing hardware present on-premises.

Virtualization and the Cloud

In the IT world, virtualization and cloud computing are not synonymous, they're not the same thing. So in other words, in order to have a cloud computing environment, you need to be using virtualization. So yes, cloud computing does depend on virtualization, but the opposite is not true. In other words, if you are using virtualization. Let's say you've got a hypervisor that supports running multiple virtual machine guests concurrently. That doesn't mean that you are using cloud computing, at least, not unto itself.

Hypervisors

So let's talk about hypervisors for a second because this is an important part of cloud computing. Think about in the cloud, where we can quickly deploy virtual machines on the Microsoft Azure platform. There needs to be underlying physical server hardware that allows those virtual machines to be deployed and to run. And so those are called hypervisors.

So we have physical hardware running a virtualization type of operating system, that's the hypervisor. And there are two main types, Type 1 and Type 2.

When the hypervisor hosts virtual machines, otherwise called guests, a Type 1 is a bare-metal hypervisor. And that means that it is the operating system that runs right on the physical hardware that supports operating system virtualization.

Now compare that with the Type 2 hypervisor. This type of hypervisor is an app. It's a piece of software that needs to be installed within an existing operating system like Linux, Windows or the Mac OS. So as you might have guessed, running a Type 1, or bare-metal hypervisor provides more options and better performance than a Type 2 hypervisor does. At least when it's used in the enterprise.

Virtualization Types

There are a number of different types of virtualization. We've just talked about operating system virtualization, where we could deploy a Linux or a virtual machine running Windows in the Azure cloud. And it only takes a few moments to do that, and it runs on physical Type 1 hypervisor hardware. Specifically, in Microsoft Azure, it's running on Microsoft Hyper-V.

But we've also got other types of virtualization like application virtualization. Application virtualization means that while we can run a specific app on a device, that app is not actually installed on that device. Instead, it's got a virtualized environment, where things like, if it's a Windows virtualized app, registry entries and file system files are not written to the real host. Instead, they're in this virtualized environment whereby the app appears to be running and is running in the operating system. But it's just not been installed in it. And so the benefit of this is portability. Now this is not a container. It sounds like container technology but application virtualization unto itself isn't. It actually predates or precedes things like Docker containers.

We've also got network virtualization seen here in the bottom right. And a term that comes to mind in line with that is software defined networking, or SDN, which is used extensively in cloud computing. Software defined networking really means that we provide cloud customers with an easy way to configure virtual network settings and routing tables, and so on. Rather than have them actually make a connection to the underlying hardware like routers that do that, we provide an easier interface.

And of course, there's also desktop virtualization, where an entire user desktop might run on a centralized server that actually runs multiple user desktops concurrently. The end user would need a thin client device with not a lot of processing and maybe not even any local storage. They would need network access to the server that hosts the virtual desktops. There's a lot of types virtualization that can be used, both on-premises and in the cloud.

Virutalization Benefits

So what's the benefit then of virtualization in Microsoft Azure?

Cloud Tenant Isolation

One is cloud tenant isolation. By allowing customers to provision their own separate virtual machines and Active Directory instances, those serve sort of as security boundaries. So that one tenant can't access virtual machines and Active Directory instances that are deployed by other tenants.

Rapid Provisioning of VMs

Virtualization allows for the rapid provisioning of virtual machines. So users can simply make a selection in the Azure portal to deploy a Linux or a Windows virtual machine that perhaps has additional software like SQL Server installed. It happens after just a few clicks or it can also be managed and deployed programmatically at the command line.

Easy Provisioning of VMs

So rapid and easy provisioning of virtual machines is one of the great things about using cloud computing in Azure. And a lot of the other services that are available in Azure, whether it comes to big data processing and analytics, or whether we're talking about running databases of any type. Or whether we're talking about hosting websites, all of that depends on virtual machines.

In some cases, some of these are called managed services, which means that we don't actually specify the virtual machine deployment details, such as when we deploy a SQL Server database in the cloud. Instead, we just focus on the database side and Azure takes care of the virtualization for us.

Cloud Computing and Economies of Scale

The economies of scale work great wonders in the Cloud. Have you ever wondered how can they get so much storage available through Microsoft Azure for such a cheap cost?

One of the reasons is because all of these pooled resources like storage arrays, physical hypervisors that run virtual machines, network equipment like routers and switches, and even inter-data center network links for Azure, all of these are done on a very large scale. And this is the responsibility of Microsoft in the Azure data centers.

One of the great things about economies of scale is that things are cheaper in bulk. And you can look at this from a couple of different perspectives, one being from Microsoft's. So purchasing a large amount of physical rack mount servers is going to end up being cheaper than buying one or two, especially over time. And if you are a repeat customer, buy equipment from that hardware vendor.

At the same time because we've got numerous cloud tenants, in other words Microsoft Azure customers, and this is on a very large scale, it means that Microsoft can afford to charge what they are charging for usage fees, subscription costs in Azure, because of the large volumes that they're dealing with with customers. So cloud tenants or customers for Microsoft Azure will pay a monthly subscription cost. And depending on the cloud service, there might be additional usage fees on top of that, such as charging for the amount of time that virtual machines are running.

The other consideration is that with an on-premises IT environment, the organization is responsible for all of the upfront costs of setting up the network infrastructure, buying storage arrays and backup systems and servers, and so on. So this is a capital expenditure, otherwise called Capex. When we look at cloud computing, all of that stuff that we've just described at the hardware level is not the responsibility of the cloud customer, but rather, the responsibility of the cloud provider, in this case, Microsoft Azure. So that means as a cloud customer that is using Microsoft Azure services, we have an ongoing operating expenditure on a monthly basis to pay for our usage of Cloud services. And that's called Opex.

So with cloud economies of scale, providers are able to allow cloud customers to pay small fees for using services that otherwise might not even be possible for smaller organizations on premises.

Public Clouds

Public clouds share a lot of the same characteristics that other cloud types do. We'll talk about other cloud types later. So with the public cloud, one characteristic is broad access. In this context, we're talking about having access to cloud services over a network, in this case, the Internet.

Resource pooling means that the underlying hardware infrastructure, so the network configuration, rough routers and switches, and also things like storage arrays, physical storage, hypervisor service that run virtual machines. All of this is pooled together and made available to be provisioned by Microsoft Azure customers.

The rapid elasticity side really reflects how quickly and easy it is to provision these cloud resources such as virtual machines or a new storage account. It can be done in moments, using a variety of different methods.

Self-provisioning refers to the fact that the cloud customer is the one that provisions resources. So for instance, if we want to deploy a new Linux virtual machine in Microsoft Azure, we don't need to contact a Microsoft Azure data center IT technician to do that for us. We do it ourselves, and we're going to learn about all the different ways that that can be done.

Metered usage reflects the fact that we are charged based on what we are using in Microsoft Azure. So the more data that you have stored and the more often it's accessed, the more it will cost. The more virtual machines you have deployed in Azure and the longer they're kept running, the more you will be charged.

Public clouds are available to anybody that has access to the Internet. In order to work with Microsoft Azure, you are going to need to create an account. But bear in mind that with the public cloud computing environment, the cloud provider owns the underlying IT infrastructure.

When it comes to cloud resource management, so working with things like Azure Virtual Machines, or web applications running in Azure or databases, those are resources, they can be managed using a web browser interface. That would be the Azure Portal, we're going spend a lot of time there.

We can also use other GUI tools, such as those that are available from Microsoft, like the Storage Explorer tool. It's just another way to reach out to your cloud subscription and work with things like storage accounts. We can use command line tools to manage Azure resources.

We'll be learning about how to use PowerShell cmdlets to do that as well as how to use the Azure CLI. And of course, developers will be interested in hooking into exposed APIs, Application Programming Interfaces, which really just allow developers to work with cloud services at a programmatic level. Even for example, if we've got a component of an application running on premises, you can reach out to the cloud and talk to cloud services programmatically.

With public clouds, the responsibility for the IT configuration and ongoing management could be split between the cloud provider and the cloud customer depending on the specific service being used. So for example, if we deploy a Linux virtual machine manually in the Azure cloud, then we are the ones that are responsible for applying updates to that virtualized Linux operating system. And it's up to us to determine how that virtual machine is configured and what software is installed within it. But at the same time, if we look at the underlying physical hypervisor server that runs virtual machines, that would be the responsibility of Microsoft in Azure data centers to make sure that hardware's kept up and running and kept patched at the firmware level, and so on.

The other thing to bear in mind in Azure is some cloud service offerings. An example of this might be a certain type of virtual machine size that determines the horsepower of that virtual machine. Some of those, as well as other services, might only be available in some Azure geographical regions and not others.

Private Clouds

Another type of cloud is a private cloud. It shares the same characteristics as other types of clouds such as public clouds, however, from a different perspective.

One of the cloud characteristics we have to consider is broad access. In the case of a private cloud, we're talking about access to cloud services over a network. But in this case, the network is limited in scope. It's not accessible by all users over the Internet that want to sign up with an account. That's a public cloud. A private cloud instead, uses equipment that is owned by and used by only a private organization.

So the resource pooling really boils down to being the underlying hardware infrastructure owned by the organization. Whether it's on a small scale, such as a very tiny private cloud defined on perhaps a couple of rack mount servers in a small server closet to a larger enterprise that has offices in different countries that has its own data centers. And again with its own private cloud services available.

Another characteristic of a cloud is rapid elasticity, which would allow, in this case, only people within the organization to use private cloud services.

Self-provisioning means that the users of cloud services can provision or de-provision cloud resources at will. So for example, if you're a department manager within an organization using a private cloud and you decide you need another virtual machine to support business processes used by your department, then you might access some kind of a web portal. Or perhaps there's an automated template that's been prepared to be used in this context to quickly deploy that type of virtual machine.

And finally, metered usage means that all of the usage of private cloud resources are being tracked. They might wonder why is that within a single organization. Well, within a single organization, we might charge how many cloud resources in our private cloud are being consumed by various departments within the company. And then we might track that and on a monthly or quarterly basis, we might charge back the cost of those resources that were consumed back to that department within the organization.

So if I have a cloud then, we'll use virtualization, because that is one of the aspects of cloud computing. But remember that just because virtualization is used on-premises, it doesn't mean that we have a private cloud. So let's say you've got a Microsoft Hyper-V hypervisor on-premises running on a server. And from it you're running a bunch of virtual machines. Or maybe you're using VMware ESXi hosts, and you've got a couple of virtual machines running. Does that mean we have a cloud? No, it does not because if we go back here, we can see that these are the characteristics that must be met in order to say that we have a cloud. It's not just virtualization, which really falls under resource pooling, but also these other characteristics.

So with a private cloud we know now that the organization owns the IT infrastructure and whatever cloud services that the organization has deemed should be available, are available only to that organization. And not to anyone over the Internet that wants to subscribe.

From a responsibility standpoint, this means that all of the IT responsibility, starting with determining what kind of hardware we need and acquiring it, and then applying firmware updates and installing operating systems, installing software, getting licenses, configuring software, troubleshooting and updating software. All of that falls under the responsibility of the organization that owns the private cloud. And we talked about departmental chargeback, which falls under the cloud characteristic of metered usage.

Hybrid Clouds

Like public and private cloud computing, a hybrid cloud shares the same types of cloud characteristics, one of which is broad access. In the context of a hybrid cloud, we're really talking about using IT systems or services on-premises and in the cloud or combining cloud types like public and private. So the broad access will vary depending on what type of a hybrid cloud we're talking about. But generally speaking, broad access means allowing access IT services that are available in the cloud, over a network.

The resource pooling aspect means having all of the underlying hardware infrastructure that makes these cloud services available to cloud consumers. Whether that's in the public cloud or the private cloud, whether it's public cloud and on-premises systems, and so on.

The rapid elasticity cloud characteristic means that we can quickly deploy or provision and deprovision cloud resources as we need them and alternatively as we don't need them.

Self-provisioning means that we have the ability to deploy services like virtual machines and databases, whether it's in a private cloud, a public cloud, and in this context with a hybrid, it really could be a combination of both.

The metered usage would apply certainly to public cloud computing, where as a cloud customer, we are charged based on our consumption of public cloud services. In the case of a hybrid cloud which could also involve a private cloud, we might also be charged by the IT department in our organization for the amount of resources that were used by a specific department within the company. Or maybe not even a department, perhaps a specific project team. We want to build costs for our private cloud based on what was used for a particular project.

With a hybrid cloud, we're talking about the use of more than one type of IT computing environment, hence the word hybrid or combination thereof. So the use of public cloud services through Microsoft Azure. The use of private cloud services if we've got an on-premises dedicated cloud. And even perhaps the use of on-premises services that aren't even in a cloud environment. An example of that might be replicating an on-premises SQL database into the Azure cloud to increase availability.

Hybrid clouds are also often used when companies are adopting cloud computing. So where we've got the on-premises migration of either IT systems like websites or servers that we want to move into the cloud, as well as the migration of data that currently might reside on-premises and moving that into the cloud. Often during the migration, we have what we call a hybrid cloud computing environment because some of our IT systems or services and data are on-premises, some are in the public cloud. And you could run that for an extended period of time, maybe that's your design. Maybe you're using the cloud as an alternative site in case something happens to your on-premises location. Or you might only do with this during migration to the cloud.

So we could have parallel systems running in both locations on-premises and in the cloud, or we might over the long term keep this as a permanent solution. And commonly, this is done with things like on-premises data that gets replicated to the public cloud. That could be in the form of as we discussed a SQL database or we might simply be using Microsoft Azure as an off site backup storage location.

So we could look at things like database replicas that might exist in different parts of our networks, such as on-premises, in the public cloud, even in the public cloud in different geographical regions. However, that unto itself would still be public cloud, and therefore not considered a hybrid type of cloud solution.

We've discussed how cloud storage could be considered a hybrid type of solution if we've got cloud data stored on-premises and in the cloud. And as we mentioned, it might be replicated or just periodically backed up for safe keeping.

Community Clouds

Community clouds are an interesting cloud type. Like public clouds, private clouds, and hybrid clouds, community clouds adhere to the standard cloud computing characteristics such as broad access. In this context, we're talking about accessing community cloud services over a network such as the Internet, but it's limited. For example, we might only have certain specific cloud IT services that are geared towards the finance industry, or specific governments in countries, or maybe to the medicinal and hospitalization type of industries.

Resource pooling means putting all of the underlying infrastructure resources together that allow cloud computing services to be available to customers. In this context, if we, for example, need to adhere to certain US government standards, there might be certain hardware security modules that deal with the cryptographic key storage that are used in terms of underlying resources that are required for compliance in order for specific government agencies to even use cloud computing in the first place.

Rapid elasticity means the same thing in the community cloud as it would, for instance, with the public cloud. It means that we have the ability as a cloud customer to quickly provision or deprovision cloud services as we need them. And the self-provisioning would be the same, whereby we might have a web interface through which we provision these community cloud services. And it might also be available at the command-line level and programmatically through exposed APIs from the cloud provider.

Metered usage would apply the same in that we are charged for our use of community cloud service offerings based on a certain fee. And that fee might be, for example, virtual machines that are running on an hourly basis. Or it could be the amount of storage that we're using and how often we put data into storage in the cloud and read data from that storage in the cloud.

Community clouds have limited access. For example, Microsoft Azure has specific government cloud options that are supported for the US government, and also, for example, for specific countries like Germany. It can also be used for specific industries that need certain regulatory compliance in place, such as the medical industry.

Community clouds are really for groups that have the same IT computing requirements and often that deals with laws and regulations related to data privacy. It can also deal with things like the physical location of data. In other words, where are the Azure data centers that will be housing this information and running these cloud-based systems?

We could also require specific security controls be put in place, as we mentioned earlier. HSM or hardware security module types of devices are used to store cryptographic keys for safekeeping. And that might be required by laws or regulations to be used in conjunction with IT services in the cloud.

There might also be industry-specific cloud software that needs to be used. For example, maybe only certain approved software can be used by US government agencies in the cloud.

Azure IaaS

Infrastructure as a Service is a type of cloud service model. It's a term that's often simply referred to as IaaS and it really applies to IT administrators that want to deploy some kind of infrastructure components in a cloud computing environment. And that is certainly something that we can do with Microsoft Azure.

Examples of Microsoft Azure Infrastructure as a Service items include things like storage, so building a storage account in Azure. Deploying Linux or Windows Virtual machines in the Azure cloud. Or configuring virtual network items like, VNets and subnets into which we can then deploy things like virtual machines and Azure. Load balancers so that we can take incoming client requests for an application and distribute it among a number of backend hosts that support that application.

We can configure IP addresses. For instance, we might want to make sure that we have a public IP address assigned to an Azure IaaS virtual machine, so that we can reach into it from outside of the cloud, over the Internet. So maybe we want to be able to manage a Linux virtual machine from our on-premises environment through an SSH connection. We can also configure route tables to control traffic flow in the cloud. All of these are examples of Infrastructure as a Service type of items available in Azure.

With Azure Infrastructure as a Service, we have to think about who is responsible for these components. Whether it be Microsoft at the Azure data center side or whether it's us as a cloud customer. So Microsoft Azure, the cloud provider is going to be responsible for things like the physical hypervisor servers on which our virtual machine guests run. Microsoft is also responsible for the underlying network hardware, the routers, and the switches, and the network connections, as well as physical storage being made available.

As cloud customers, what are we responsible for? Well, it's up to us to deploy Linux or Windows virtual machines, to configure virtual networks in the Azure cloud appropriately, with the correct IP address ranges for subnets in the VNets, into which we would deploy things like virtual machines. It's also up to us to determine how we want to provision our cloud storage. So how many cloud storage accounts we want to build in Azure? How their properties are configured? And also whether data is encrypted, whether it's replicated across regions, and so on. That becomes our responsibility as customers.

We can manage Azure Infrastructure as a Service items that we've discussed, like virtual machines and storage accounts, using the Azure portal. That's something we're going to take a look at, it's essentially the web graphical user interface to manage Azure resources. We can use the Azure CLI, we can use Azure PowerShell cmdlets. And for developers, the Azure REST API can be used to communicate with APIs that are exposed for all Azure services.

Azure PaaS

Azure Platform as a Service, otherwise called PaaS, applies to IT administrators and developers. These are the types of IT people that would be interested in Platform as a Service offerings.

Now let's find out why that is because there are many examples of Platform as a Service in Azure, the first of which is Azure Active Directory, otherwise called AAD. Normally, we might have an on-premises Active Directory domain controller that has a replica of the Active Directory domain database. That would contain things like user accounts, computers, for those computers joined to the domain, groups, and so on. Instead of provisioning a virtual machine and installing the Active Directory services role and all of that manual work, we can simply deploy a new instance of Azure Active Directory very quickly in the Azure Cloud. We don't have to worry about the underlying virtual machines, because if we were manually deploying virtual machines, it wouldn't be Platform as a Service. It would be Infrastructure as a Service.

Other examples of Platform as a Service include deploying Azure SQL databases in the Azure Cloud. Deploying the Azure Search solution or the Azure Content Delivery Network or CDN, which is used to place content geographically nearest users that will be requesting it to speed up the experience. So these are all examples of things that we could deploy very quickly without having to manually deploy the underlying virtual machines that would support these services. So in other words, these are examples also of managed services.

With Platform as a Service in Azure, there is shared responsibility where the cloud provider, Microsoft, is responsible for the underlying servers that will run things like Active Directory and Microsoft SQL Server. But we as the cloud customers have a different type of responsibility. We would be responsible, for instance, for the contents that would be stored within Azure Active Directory, such as user accounts that we might create for authentication and groups and the privileges they have through role-based access control. We would be responsible for that. Also, if we were deploying Azure SQL databases, we would be responsible for the specific configuration of how that works and whether we've got replicas. And also, of course, the data that's stored within those Azure SQL databases.

Like pretty much everything in Azure, Platform as a Service offerings can be accessed in a number of ways when it comes to deploying, configuring, and just ongoing management. We can use the Azure Portal, the web GUI. We can use Azure CLI commands. We can use Azure PowerShell cmdlets to talk to Platform as a Service offerings. And of course, at the development level, developers can talk to Platform as a Service items such as Azure SQL databases through exposed APIs, and they can do that using the REST API.

Azure SaaS

Software as a Service, otherwise called SaaS, is one of those cloud service models that applies primarily to end users. What does that mean using the word primarily? What it really means, is that end users benefit from the use of Software as a Service, such as office productivity tools that are cloud based. However, IT technicians are still responsible for making configuration changes or applying security settings that will influence how end users use those solutions.

So examples of Software as a Service would include cloud-based solutions related to things like email, or calendaring, office productivity tool such as Office 365, which can also include things like SharePoint Online.

With Software as a Service, the shared responsibility is split between the cloud provider and the cloud consumer. So the cloud provider is responsible for all of the underlying hardware to make those services available. So the underlying servers that might run Microsoft Exchange Mail Server software, so it's available for cloud-based mail, and office productivity software.

But we as the cloud customer, we're SaaS end users, Software as a Service, we're responsible for configuring the behavior of those solutions, including some security settings, whatever is available with the specific solution we're talking about, and also the data that results from it. So we would be responsible, for example, for how data is treated or backed up, archived, or replicated that we might be working with, in SharePoint Online, for example.

So we can manage Software as a Service settings using a web browser, for example, using the Office 365 web portal to provision users or control what they can access. We can also use command line tools to do the same things. For instance, we might use PowerShell cmdlets to authenticate to Azure Active Directory which is used by Office 365. We might also use separate PowerShell cmdlets to make a connection to SharePoint Online, so we begin managing that aspect of the Office 365.

On-Premises vs. Cloud

Years ago, when cloud computing was a newer thing, there were a lot of comparisons made as to how we could use cloud computing or on-premises IT solutions, one or the other, not both together. But the reality is we can use a hybrid of both. It doesn't necessarily have to be just black and white. So let's talk about on-premises IT computing versus cloud computing. And we'll start from the context of hardware.

With on-premises IT systems, we as the private organization are entirely responsible for selecting, then acquiring and waiting for hardware to be shipped. Including things like racks for server rooms or data centers, rack-mount servers, UPS battery systems, storage appliances, firewall appliances, routers, switches, the list goes on and on. In the cloud, that's the provider's problem, not us as a cloud consumer.

The same goes for the configuration of that hardware, the ongoing management, firmware updates that need to be applied perhaps over time, and the eventual decommissioning of it and finding replacement hardware. On-premises that would fall entirely on the organization, but in the cloud, that responsibility falls on the cloud provider.

If we look at the same type of thing but from a software perspective, on-premises, private organization is responsible. The selection, the acquisition and the licensing of whatever software solutions are needed to meet business needs. Now in the cloud, the acquisition part isn't a big deal because the cloud provider will have something available such as Office 365 and its variety of options. However, licensing is an interesting topic, because if we've already purchased licenses, let's say for the Windows Server operating system or maybe for Microsoft SQL Server and we're running all that on-premises, when we migrate to the cloud some Azure Cloud offerings will allow us to bring our own license, BYOL. So we can reuse our investment in licenses and not have to pay for it all over again, just because we're migrating to the cloud.

The configuration of software, the ongoing management, the application of updates, and the eventual decommissioning of software, all of this is our responsibility if we are doing all of this on-premises. However, in the cloud, depending on the specific cloud service model you're talking about, most or all of this could be the cloud provider's responsibility. The reason I say it may or may not be the cloud provider's responsibility is, imagine that you're deploying software in the form of a Linux virtual machine in Azure. So you're manually deploying that. That's Infrastructure as a Service. You as the cloud customer, then, are responsible for updating that operating system and installing software in that virtual machine and updating it as well. So it really depends on the specific cloud service model that you're talking about when it comes to software and who is responsible for what.

The next thing to consider is that if we've got a physical disaster, when we have an on-premises environment, it might be beneficial to use the cloud as an alternate site. Now that means that we could have IT systems that run on-premises. So web applications, database servers and so on, that could be duplicated and left running in the cloud. And depending on our requirements, we might even have continuous data replication to the cloud, so in the event of a physical disaster, everything is ready to go in the cloud.

The other thing to consider is the responsibilities, as we mentioned. On-premises really means that the private organization is pretty much responsible for everything. In the cloud, generally speaking, the cloud provider is responsible for a lot of the infrastructure, certainly when it comes to hardware.

We also have to think about the cost. We want to make sure that we dispel the myth that cloud computing is always cheaper than the alternative, which would be to host everything yourself on-premises. That's not always the case necessarily. It's not as simple as that. We have to consider the fact, though, that we've got capital expenditures when it comes to purchasing and paying upfront for all of this hardware that we're running on-premises. We don't have that Capex or that capital expenditure, when it comes to exclusively using cloud computing. In that case, we've got an operating expense over time with a monthly subscription and usage payment. So that's Opex, or operating expenditures.

And in the cloud, we can also configure billing alert so that we can be notified when a certain cost threshold is exceeded. So that we can go take a look and perhaps realize that we left databases running in the cloud for a test environment when we're actually finished with them. And remember, when you leave things running in the cloud, you're still paying for them, so very important to watch that. And we'll focus on that in more detail later when we talk about cost management.

Cloud Migration

Cloud migration deals with migrating on-premises IT environments into the Azure cloud. Things like specific IT systems, such as servers, or even specific IT workloads running on a server. So imagine that you've got an on-premises file server, that's also doubling as a database server. And so you might choose the database workload as something you might migrate into the Azure cloud, while leaving the file server on-premises.

We can also migrate data that's currently housed on-premises into the cloud as long as it meets specific security requirements that might be applicable based on the industry we're in or the government agency that we might doing this for.

We have to also consider the suitability of on-premises IT solutions for migration into the Azure cloud. We need to make sure that we can map existing on-premises services to an equivalent solution in the cloud. Now in some cases you might simply be able to take what you're running on-premises and move it essentially into the cloud. Or, in other cases you might have to find a functional equivalent that is already made available through Azure service offerings. Then you need to consider security standards, such as whether or not you need to encrypt data at rest, such as data stored in a storage account in the Azure cloud.

With cloud migration, an important term to be aware of is lift and shift migration. What this means is we're taking an existing IT solution, and we're migrating it to the cloud without changing it. So an example of this might be migrating a physical or a virtual server that we currently have running on-premises and migrating it to Azure. So really, we're changing the hosting environment in which that virtual machine or maybe we're converting a physical to a virtual. We're changing the hosting environment, but the operating system and its configuration remains exactly as it was on-premises, unchanged.

The Azure Migrate Service is an offering that can help with such types of migrations. It allows us to evaluate the migration suitability for things like virtual machines that we currently have running on-premises, and the workloads that they support.

It can also take a look at IT system dependencies. For instance, you might have a front end web application that depends on a back end data base running in a different virtual machine. So that kind of system dependency would be caught by the Azure Migrate Service, because you don't want to be in a situation where you're only migrating one part of the solution to the cloud, only to realize it then doesn't work in the cloud.

The Azure Migrate Service can also provide cost estimations as to what you might be looking at for monthly charges on a recurrent basis after you've migrated specific workloads to the cloud.

So the Azure Migration Service Process begins with creating what's called a project. It then requires running an on-premises collector virtual machine. And this is designed to run in a VMware vCenter type of environment. Now that collector virtual machine will then gather data from on-premises and that gets sent to the Azure project.

Next, that discovered data is organized into specific groups. And this discovered data really comes from on-premises virtual machines that we're considering migrating to the Azure cloud.

Finally, the last step of working with the Azure Migration Service Process is to assess the results, to determine in fact if it is a migration that will take place.

Review

Cloud computing encompasses a number of defining characteristics including broad access. This means that cloud computing IT services are made available over a network, such as the Internet as in the case of a public cloud, or even an intranet, an internal network in the case of a private cloud. Resource pooling means the cloud provider is pooling together all of the underlying hardware infrastructure that makes all of these cloud computing services available. Things like hypervisor servers, things like physical storage arrays, routers, and switches.

Rapid elasticity is another cloud characteristic which really means that using, more often than not, a self-provisioning portal or commands that cloud consumers can rapidly deploy or provision cloud resources as needed. In the same way, they can rapidly deprovision them when they're no longer needed to save on costs. In the cloud, another characteristic is metered usage, which means that our usage of cloud services is tracked and we pay for what we use.

A private cloud means that the organization owns the IT infrastructure and that those cloud services running on that IT infrastructure are available to that organization. It's a private cloud. However, a public cloud means that the cloud provider owns the IT infrastructure and the public cloud provider services are available to anybody over the Internet that wants to sign up. With either type of cloud, the same cloud characteristics such as broad access, resource pooling, rapid elasticity, and so on would apply.

There is definitely a relationship between virtualization and cloud computing. And that relationship is such that cloud computing depends on virtualization. However, if you're using virtualization, such as running a hypervisor on-premises, that itself does not mean that you've got a cloud. You have to really meet the cloud characteristics, which would include the items that we discussed, like broad access over a network, resource pooling, metered usage, self-provisioning, and so on.

With hybrid cloud computing, we are combining a couple of cloud computing and IT system models, such as combining a public and a private cloud, or public cloud computing along with on-premises systems that talk to the public cloud.

Common uses for this would be when we are migrating on-premises systems and data to the cloud. So therefore, the hybrid solution could be only temporary in that type of a case. Or it could be more permanent where we are depending on the cloud as an alternate location to run our IT systems and perhaps replicate data to. So we would do it perhaps for reasons of high availability, which would be perhaps for the longer term.