Introduction
A bit less than a year ago I blogged my opinion on “Cloud Native”, where the objective of today is to provide a bit more nuance to this previous post. Let us categorize it as “progressive insights”, due to having these type of discussions on a virtually daily basis. Therefore I wanted to share this with a broader audience, as I expect this is valuable to all. Where I will also try to make it a bit more tangible to link it to “Serverless” options in Azure.
Cloud Service Models
We probably all know the “Pizza-as-a-Service” analogies? Where the difference is described between “On Premises (OnPrem)”, “Infastructure-as-a-Service (IaaS)”, “Platform-as-a-Service (PaaS)” & “Software-as-a-Service (SaaS)”. Though over the years the spectrum here has broadened even further!
Actually, between IaaS and PaaS, we also have CaaS (Containers-as-a-Service). Where between PaaS and Saas, we actually have FaaS (Functions-as-a-Service).
Now, in full transparency, and to make this fully complex… FaaS & Serverless are sometimes interchanged. But the same goes for the full spectrum beween IaaS & SaaS, which is also sometimes interchanged with Serverless. For today’s post, in terms of semantics, I used the term “Serverless” to describe anything between IaaS & SaaS. As basically, from my point-of-view, anything beyond IaaS abstracts away the “servers” (infrastructure) and makes you focus on the applications.
Application Hosting Continuum
When talking to customers, I always jokingly mention two sayings ;
- “Every disadvantage, has its advantage” –Johan Cruyff (Football Manager)
- “With great power, comes great responsibility” –Spiderman
Where both these sayings perfectly relate to the application hosting continuum in the cloud too! When moving between the hosting options, you will notice that you will need to sacrifice one thing to gain another. So let us go through that spectrum!
On the left side of the spectrum, you will have virtually full control of every aspect of the platform. Where this is awesome of course, this comes with the trade-off that this will also be your responsibility. And with responsibility comes the need to invest in this. It may not always be apparent, but aside from the resource costs, you also need to invest in the R&D to set things up and keep the lifecycle of the platform going! Which is actually more than the operational side of keeping the lights on… Upgrades, transitions, capabilities, etc. Hence the Spiderman quote. 😉
On the right side of the spectrum, it is depicted as “Agility”… Though see it more as an increase in terms of “Velocity”. The things that come with responsibility are being unburdened from your, which allows you to focus on delivering business value. The flip side of that coin however, is that you will need to be able to let go of control. Hence the Johan Cruyff quote… 😉
Though you cannot have the full pie. You will always need to make a conscious decision on where you want to position yourself on this spectrum. Saying you favor “SaaS before PaaS, and PaaS before IaaS” will not cut it! And surely not if you then say you need full control of every aspect of the deployment.
“Serverless” Comparison
So far, we have been looking at the theoretical aspect of things. Now let us make it a bit more tangible and look at the various “Serverless” (between IaaS and SaaS) options at hand ; 
- CaaS : In terms of container platforms, Azure provides AKS (Azure Kubernetes Service) and ARO (Azure Red Hat OpenShift). Though in addition, there is also even the possibility of leveraging ACI (Azure Container Instance). Where AKS and ARO provide the full fledged orchestration power (control), ACI is “just” a managed container. One container. No more, no less. 😉
- PaaS : Azure App Service & Azure Spring Cloud go a step further… A lot of capabilities come out of the box and abstract away operational burdens for you. For example, the following things come out of the box ; SSL offloading, CORS, auto scaling, CI/CD integration, virtual hosting, etc. Where if you would leverage CaaS, those are services you would need to introduce/manage yourself.
- FaaS : If we up it even further… Then we arrive at “Azure Functions”, with its focus on “You bring the code, we do the rest!”. Which is an awesome story as such, and great for event driven things. It comes with the downside that you need to step into an heavily opinionated framework to achieve this. Remember the quote from Johan Cruyff?
The best hosting option!
Is there a right or wrong choice here? No. There are no silver bullets! As mentioned before, you need to make a conscious choice on what advantages favors you the most over the disadvantages that come with it. That being said, I do see two patterns ;
- Portability ; Organizations that want to avoid a vendor lock-in by any cost will typically favor IaaS or CaaS. Where one can argue that trading in a vendor lock-in for a product lock-in is not much better… Though I can follow the reasoning that the community adoption of k8s is large enough to counter some objections that come with it. Though, that being said, a kubernetes certified conformance does provide a generic enough layer to build on top from. The advantage of having this portability comes with the cost of needed to foresee/maintain various supporting capabilities yourself.
- Velocity ; Other organizations want to avoid being slowed down at any cost. The need to be able to adapt quickly outweighs the possible need for more control or to avoid a possible lock-in to the platform. Though truth be told, organizations going this route need to be more agile by design too. They will link their cadence to the one of the technology provider. Where if you have full control, you can choose to run the same stack for 30 years. Of course you will need to foresee support for that stack yourself. Though it is possible. This level of “long term support” is typically not something you can expect from the right side of the spectrum. This is a “fast moving” (in the perception of larger enterprises) space and you will at times be pushed to follow the minimal support levels.
Microservices anyone?
Another popular topic are microservices, and what services are best suited for that. Architectures that really benefit from microservices typically have a need where the various services need to be able to scale independently. Not all services are capable of doing that…
Azure App Service for instance is not suited for microservices and follows the pattern of a typical application server / middleware. Where it is awesome at that, when it scales out, it will have one instance of each application deployed for each scale unit. Thus all services are given the same amount of resources, which is typically not the expectation with microservices.
Functions can be seen as microservices. As they can scale independently… Though they do not come with the typical discoverability / service registry capabilities that you would with a typical microservices architecture. Which then leaves the kubernetes stack (AKS & ARO) and Azure Spring Cloud (and the Azure Managed Service Fabric [preview]).
Closing Thoughts
So every advantage has its disadvantage… And with great power, comes great responsibility. Those are the important things to consider when taking a look at the broader application hosting continuum in the cloud. There is no one size fits all. Otherwise why would there be so many options? Though I do hope this posts helps you to better understand the options and the trade-offs / benefits that come with it!
Karim Vaes 