A first, well-known and much-used dimension to distinguish between the different types of cloud platforms is the IaaS – PaaS – SaaS axis and all its variants and commercially inspired XaaS derivatives. This dimension mainly differentiates between the responsibility the cloud provider takes in the computing stack: up to the virtual machines, the application middleware or the application itself. Yet by using this term, indubitably, a real cloud computing model is intended (i.e. a shared resources, pay-as-you-use computing model).
One particular style of cloud platform that is worth mentioning in this context is Application Platform as a Service or aPaaS. aPaas is, in fact, a form of PaaS. The term PaaS is typically used for a platform for (SaaS, IoT, …) developers and ISVs, and is optimized (e.g. DevOps, orchestration) to accommodate built-for-cloud applications. aPaaS, on the other hand, refers to a cloud platform specifically designed, tuned and managed to run an existing legacy (not cloud-aware) application (e.g. SAP ECC or Microsoft AX).
A second dimension that is used to classify the cloud solutions is public vs. private. However, be careful here! While private cloud in the strict sense (i.e. non-shared resources) is too narrow (and can hardly be called cloud at all), in effect, public cloud is a container concept.
In reality, many characteristics of cloud computing are projected on this one axis. So instead of using this fuzzy and hollow public-private division, we can better distinguish between cloud platforms and solutions on their real characteristics:
In a hybrid IT vision and architecture, where each workload is run on the most suitable and cost effective platform (i.e. on-premise, hosted, IaaS, aPaas, SaaS), the first thing to do is to determine the specific needs of a particular workload, business, and/or user community. Based on this, the different applicable solutions are to be compared. Now, how can we classify workloads based on their specific requirements?
We distinguish 4 axes to characterize a particular workload:
1. By destination
Enterprise grade applications are typically used by employees over private networks with a varying but predictable (and constrained) load, while commercial grade applications address unknown users, over public networks with less predictable and potentially very bursting load.
2. By pace
Changes and releases are as few as possible for core business applications, while, for innovating applications, one should be organized for frequent updates and changes.
3. By value
Differentiating applications need to be optimized to support the business processes and hence increase efficiency and reduce cost as much as possible. For typical commodity applications in many cases, it is the aim to minimize the Total-Cost-of-Ownership (TCO) of running the application itself.
4. By technology
Built-for-cloud applications are developed on a particular PaaS cloud platform (e.g. MS Azure, Amazon AWS), are ‘aware’ of running in the cloud and use platform built-in services and APIs to realize scalability, availability, etc. For legacy (typically client-server) applications, the platform should be designed to run that particular application and to realize the required conditions such as availability, performance and scalability (i.e. aPaaS).
The message here is:
There is no one cloud (provider) fits all applications. Cloud should be architected.
Last but not least, before deciding on and migrating a workload to a cloud solution, make sure following questions have a positive answer:
Reason enough to always involve the IT department when you considering cloud sourcing.
More questions? Do not hesitate to contact us!
Author: Guy Clarysse. You can connect with Guy on LinkedIn