Speaking of IaC, we have lot of terms something as something in cloud world. The main types of services in Microsoft Azure (and cloud in general) are:

• Infrastructure as a Service (IaaS)
• Platform as a Service (PaaS)
• Software as a Service (SaaS)

Each type represents a different kind of service level and our control over that resource. To explain each one and how they relate, it's best to compare them to services in our local data center. A service layer for all models is shown in the following diagram and we'll use this to explain the relationship between cloud models:

In a private data center, we are responsible to set up and maintain everything. We need to set up a networking stack, prepare and configure storage, buy and prepare hardware, install software, and configure the virtualization host. Then we need to configure images and servers, and deploy and manage databases. Security is also our concern in all aspects—physical security, network security, host and OS security, and finally application security for all application software running on our servers.

With IaaS, it gets easier. We don't have to prepare anything anymore; all we need to do is sign up for a subscription and create a virtual machine when needed and start using it. The part where we must buy, prepare, configure, and maintain is no longer our concern and the cloud service provider takes care of that, in our case Microsoft with Azure. Preparing images and deployments is also no longer our responsibility. Security is getting easier and physical, network, and host security are handled by Microsoft. We still have a responsibility in the security corner in order to keep our operating system up to date, patched, and secure. Application security is also our responsibility and we need to keep applying the best security practices in order to stay safe and secure. Many people forget that when migrating to the cloud we need to step up security. As the cloud service provider takes care of a big part of security, many get comfortable and relaxed and they neglect the part of security they need to take care of. When moving to the cloud, we need to remember that our resources and applications are publicly exposed and will experience significantly more "attacks" compared to when using on-premises infrastructure. Attacking resources on-premises usually means getting behind a firewall, then breaching the server and getting some data out. Now, many services are accessible over the internet and you need to take care of security better than ever before. The best examples of IaaS, when talking about Microsoft Azure, are Azure virtual machines. Both Windows Server and Linux virtual machines are available in Microsoft Azure. An interesting fact is that, according to information Microsoft released in October 2017, more than 40% of virtual machines in Azure are running Linux.

PaaS is getting even easier to use than IaaS. Everything that we said the cloud service provider is taking care of applies, plus some more. In this type of service, Microsoft is taking care of the operating system, additional software needed, and an additional layer of security. We still need to maintain everything we place there (depending on the PaaS service) and the part of security that remains our problem. Again, people forget that security part very quickly as even more responsibility is on Microsoft. However, IaaS is often used with VPN connections (either point-to-site or site-to-site) and endpoints are not publicly exposed in this case. This is not the case with PaaS, which is more often accessed over the internet. Because of this, we need to take security very seriously unless we want to lose our data or access to our services. The best examples of PaaS in Azure are Azure app service or Azure SQL databases.

Finally, we have SaaS. In SaaS, the cloud service provider is taking care of almost everything, from end to end. In this case, we have a complete solution prepared and all we have to do is create a subscription and assign users different kinds of access. Usually, SaaS has to have modules, an administrator, and a user. The administrator module is used to manage users and access levels; the user module is used to actually use the software feature we subscribed to. Security is also our responsibility, only on the user level, and we need to make sure users are aware that they need to keep their credentials safe and their password strong enough to prevent accounts being brute-forced into. The best example of SaaS in Microsoft Cloud is Office 365.

This diagram explaining Pizza as a Service is very often used to describe how cloud services relate to real-life situations and to better understand what cloud computing offers:

In this case, we can compare pizza to all four types we have in the previous diagram that explains IaaS, PaaS, and SaaS as well as on-premises computing.

When compared to on-premises computing, pizza would be the homemade option. We need to buy all ingredients, mix everything, bake it, buy sodas, and serve. Comparing pizza to IaaS, we would buy frozen pizzas and bake them, set up the table, and serve. Pizza, compared to PaaS, would be home delivery—we just order our pizza and need to buy sodas and serve. Lastly, the SaaS version of pizza would be dining in a restaurant: we go out and order and everything is done for us. We get our pizza, get our sodas, and everything is served.

We already discussed some of the features and benefits that each cloud service model brings to us. IaaS needs more enrolment and more maintenance than PaaS. SaaS needs even less of a human touch than PaaS and almost no maintenance except for user administration.

But there is an other side of that as well. SaaS asks for minimum maintenance and administration, but gives you a minimum amount of customization too. If you need something changed in SaaS, you'll probably need to contact your cloud service provider who can make the changes.

In PaaS, you have more freedom in terms of administration, maintenance, and customization. However, these changes are usually a preconfigured set of options you can choose from, but there are still more options than in SaaS.

IaaS requires the most administration and maintenance but gives you the best customization options as well. As you are controlling everything from the operating system upwards (you can select different preconfigured images or even bring in your own OS image), you have the best control as well. You can select what features you are going to configure, what server roles you are going to have on that server, and even install any type of software on that virtual machine.

The bottom line is you need to decide what kind of feature is best suited for you in a given situation. In some cases, the simplest solution would be SaaS, as that product offers everything you need. If you need the latest settings and features, you'll probably use the PaaS model. If you have some legacy dependencies, IaaS would be the way to go. This way, you would be able to configure and install everything related to that dependency.

The first benefit of cloud computing is obvious from all things previously written: it's easier to maintain and manage.

With the cloud there are many areas of expertise you don't need to provide yourself; the cloud service provider manages these thing for you. But this can be kind of a trap—cloud resources are not self-managed and you still need IT professionals who will manage and maintain your resources and keep them in good health. These are different kinds of IT professionals than in a local data center, but we still need people who understand core IT. If you are using IaaS, you still need a Windows Server Administrator (or Linux Server Administrator, depending on your preferences). If you are using databases, you are still going to need a database administrator. IT professionals need to adjust their skills and roles to cloud computing and leave on-premises behind them, but we still need them very much.

The financial benefit is also one of the obvious pros. In an on-premises environment you needed to buy and pay for all resources upfront, before you started using them. There are many different hardware components that we need to prepare for a local data center such as a firewall, network switches, storage, servers, a power supply that cannot be interrupted, and so on. We need to prepare infrastructure that can handle this kind of hardware, such as a proper server room. Cooling that will keep our hardware at the optimum temperature or provide enough electrical power that we can keep this running without overloading our electrical grid. And when we have everything in place, we need to have proper licenses for the virtualization host, operating system licenses for each virtual machine you want to run, and licenses for any additional software you plan to use such as SQL Server, endpoint protection, or any other software needed. In a local data center, you need to buy and prepare everything in advance. This can be a significant financial hit for any organization.

And after this initial cost, we have to pay upkeep. We are paying for electricity, for a cooling system, the required spare parts, and someone to maintain all of this.

After a few years, our hardware and software becomes obsolete and we need to repeat everything again. It can be hard to keep up and stay relevant in these conditions.

In the cloud, we don't have to pay upfront for anything; we are using services in a pay-as-you-go model where you pay for resources you are using on a per-minute basis. We don't have to invest heavily in anything—you create resources when you need them, for the amount of time you need them for, and delete them once you're done.

If we need a new server, we can have that in a matter of minutes in the cloud. There is no need to contact different resellers, no filling in orders and waiting for deliveries. In Azure, you just spin up a virtual machine (or any other resource) whenever you need it. Once you don't need it anymore, you can delete it and from that moment on you don't need to pay for it anymore. This is also one of the differences between the cloud and on-premises: you are not stuck with what you buy. In a local data center, you need to buy resources in order to use them. Once you don't need them, they don't magically disappear from your server room. And even if it did somehow disappear, you still invested money.

Assessment in terms of how many resources we need for a specific service can also be a big issue. Let's say we are creating a new web application that we are going to offer to end users. The application is completed and we need to host it somewhere in order for users to start signing up and using that application. The application is probably going to need servers, a web server and a database server. We need to buy new hardware and licenses for these servers. The problem here is that we need to buy hardware that is going to be able to handle our workload. The workload needs to be estimated for an initial number of users and growth over time but this can be very hard to estimate. If we guess the initial workload, it's very easy to make mistakes with growth numbers. If we overestimate, we are stuck with something we don't actually need but have paid for. If we underestimate, we need to upgrade very quickly. Upgrading can bring us to two problems: time and money.

It can take some time to order upgrades and resolve issues with workload. And in this time, while we're waiting on upgrade components, users experiencing bad performance caused by high workload may leave. Losing users due to the bad performance of our application is something we definitely want to avoid but may be out of our hands because it takes time to get permission (especially in large companies) to order upgrade components, to have them delivered, and to upgrade our servers. Upgrading servers will also cause some downtime because we need to shut down servers in order to add new components. Again, we have something that we want to avoid.

The second thing about upgrades is that they cost money. It can take a significant amount of money in order to increase server workload. In some cases, if we need to upgrade memory, we are not able to do that unless we upgrade the CPU. Sometimes, upgrading a CPU requires the upgrading of the motherboard first in order to continue. But that is if servers can be upgraded, because sometimes we are limited with what we get and are not able to upgrade at all. In such cases, we need to buy brand-new hardware and we have an old server that we don't need but already paid for.

The cloud keeps these issues much more simple and easier to resolve. We will create either two servers (in case we decide to use IaaS) or two other services (in case we decide on PaaS; we have multiple options there). Managing workloads and the amount of resources is simple, fast, and easy.

If time shows that we overestimated ourselves, we can simply scale down resources and the issue is resolved. We are not stuck with something we don't need and we are not paying for it. We simply scale down the server/resources and from that moment forward, we are paying for a smaller server that we actually do need.

In case we underestimated ourselves, we can scale up and increase the amount of resources just as easily and quickly. We don't have to wait for parts and don't need to lose time until upgrade components are finally delivered. We just increase the amount of resources and the issue is resolved.

Another benefit of the cloud is also tied to resource amounts. In some cases, we have spikes in our applications. Spikes are sudden increases in workload and can be predictable or unpredictable. For example, if we are hosting a web shop application, we can predict spikes in workload if we have offer discounts on popular items or increased workloads during holidays. If we have some kind of news portal, we can experience unpredicted spikes in workload caused by some breaking news or something similar.

In both cases—unpredicted or predicted spikes—we need to account for them when setting up resources we are going to use. Even if our resources are sitting idle and underused most of the time, we need to buy hardware that is going to handle these kinds of workloads. So, if we are having 10,000 users on a normal day and 1,000,000 during spikes, we need to buy resources that can handle a workload for 1,000,000. Otherwise, during spikes, users are going to experience high workload and an unresponsive application. As a result, we will lose users once again. But, buying a server that will be underused 90% of the time is something we would like to avoid as it is expensive. We have a choice: either pay or lose customers.

The cloud lets us handle this issue very quickly as well. We can scale up and down very easily, simply, and quickly. Two approaches can be taken, depending on if we have unpredicted or predicted spikes.

In case of predictable spikes, we can increase and decrease the amount of resources on demand. By doing so, we are no longer paying for a large amount of resources outside of the period we actually need them. In a normal period, we are paying only for a normal workload and in the case of increases we are paying for a high workload but only for the period we have a higher workload before we scale down back to normal.

In the case of unpredictable spikes, we can set performance counters and alerts that will trigger a scale-up (or scale-down) as needed. For example, we can set up a trigger that will monitor the CPU. Once the CPU hits 90%, we can schedule automatic scaling out and increase the amount of resources assigned to that service. This way, users don't experience any issues caused by high workload and increased usage of our application. We need to be careful of automatic scaling out as this will create an increase in pricing and unless we scale back down, we will pay the increased price. Scaling down can be done manually but it can be done automatically as well. We can create another trigger that will perform scaling down in case the CPU drops below 50%. This way, we can always use only the resources that we actually need and use.