Where has the cloud computing model evolved from?
Cloud computing is the next phase in the evolution of the computing platform and the next significant shift of the IT industry; it is another model for delivering computing resources to an organization.
We have evolved from physical hardware to virtualization that is run from our facilities or somebody else's to another computing model shift of virtual machines to containers and now the leap to serverless, where the business logic layer is the new scale unit in the journey to the cloud:
The goal of hybrid computing is to provide computing resources anywhere, anytime, and give a business the power of choice as to the most suitable technology platform for any given workload, business initiative, or scenario that needs to be supported.
Cloud computing is not only a technical evolution but also a financial evolution; the expenditure model shifts from that of capital expenditure (CapEx) of hardware (buying upfront before you can use resources) to operating expense (OpEx) and paying as you use resources.
It should be noted, though, that the private cloud model can contain an element of CapEx and OpEx; typically (and for the exam objectives), the primary cost expenditure model is CapEx. However, leased hardware and software are financially also considered OpEx, but would mainly mean building an on-premises infrastructure.
As the computing platform environments have changed over time, so have the architectures; this next section will look at the evolution of the cloud computing architectures.
Evolution of cloud computing architectures
Serverless comes about from another architectural shift in the compute layer and is an extension and evolution of PaaS.
When you use PaaS resources to host a website or application or execute code, you are still using servers; you specify a set of underlying compute resources and pay for those. This would be the server farm in traditional hosting.
Whereas in serverless, it's exactly as it says in the name, you are not responsible for creating any compute resources; there are servers involved, but this compute layer is provided by the platform provider – it's abstracted from your control or responsibility. In essence, you provide your business logic layer, and they run it for you on their compute layer.
The term cloud-native also gets introduced here; this means moving from the monolith stacks of virtual machines to microservices such as containers or serverless architecture solutions as functions (Azure Functions) or workflows (Azure Logic Apps). This is a fundamental shift from compute stack-centric to business logic-centric, where we are only focusing on the outcomes and not the inputs; that is, we no longer care or have to concern ourselves with the lower layers such as the languages, runtimes, compute, and so on, as these are now provided as a service for us to consume by the provider. You give the code, and the provider will decide how they will handle the execution of it.
As I mentioned earlier, serverless is about abstracting the language runtime, PaaS is about abstracting the compute, and IaaS is about abstracting the hardware. When we say abstract, what we mean is to remove, that is, remove the requirement to provide that layer; we make that layer the cloud provider's responsibility to provide, scale, keep available, maintain, and so on. It is a layer that we no longer need to know or care about:
This section looked at the evolution of both the computing platform environments and the cloud computing architectures. The illustration outlines where the architectures differ in their characteristics and outlines decision criteria to consider so that each architecture can be positioned to make the most appropriate choice for any given scenario.
In the next section, we look at the Shared Responsibility Model, one of the most misunderstood cloud computing concepts but one of the most critical to understand. It underpins many decisions and their consequences of security and degrees of control measures.
In the Comparing the cloud computing service models section, we continue to look at the degrees of control offered by each model.