Kubernetes, VMware Cloud Foundation, Amazon EC2, CloudFoundry, FaaS… All those terms have something in common: it’s all infrastructure platforms.
Get back to basics then – what is a platform? what are the differences between all those? is there a “super-platform” or one which is better than others?
In this article I will describe platform types, what they abstract, differences and a sort of classification.
As the content of this wiki page suggest, there are many different types, from hardware to web browsers, which can be described as platforms.
This article focuses on Infrastructure Platforms.
Disclaimer- in this article I am dealing with the functional point of view, not the technical one. I do know products and technologies are technically different, but from a functional and outcome standpoint it’s a different perspective.
Types of Platforms
In the “world” of infrastructure, there are various types of platforms, and you already know this lingo: Physical Infrastructure, Virtual Infrastructure, Cloud, IaaS, PaaS, XaaS, NoCode, COTS App, SaaS, Service Mesh.
What makes different products / solutions of one type rather than another? it is simply the service level, hosting type, runtime provided, the level of abstraction provided and the functionalities or capabilities.
But let’s take it more simply: Align to the Enterprise architect view from TOGAF well-know acronym BDAT (Business, Data, Application, Technology)
“T“: Physical, Virtual and Cloud
First type of platform – physical Infrastructure. This includes any server installed manually “old school”: on this type, you have installed the operating system (will be abbreviated OS in the next chapters) directly on the “bare metal” (understand directly without any hypervisor or segmentation system).
Reminder, operating system is somewhere applications, runtimes, libraries can run low-level and execute cpu orders, consume memory and reach other systems through network connectivity. From high-level point of view, it’s not limited to the full OSes but also to partition/segmentation of these systems.
This is the (late) ’90s way to do IT – back then you had few physical hosts, each different due to different purchase time, with OS like Slackware 2.1, Windows NT 3.51, Netware 4.11, … “The good old times”, when you were crossing your fingers while inserting the 60th floppy.
This type is manually installed, difficult to maintain, not industrializable, does not provide any abstraction – it’s hardware bound and should not have a standardized hardware fabric. However it’s highly customizable, not specialized and known since 30+ years.
Years after this good old Netware and its NDS, server virtualization appears, allowing you to create virtual machines (vms) hosted on a set of physical infrastructure, with properties inherited from the hardware – it has vCPU, memory, storage virtual disks and network connectivity.
Virtual Infrastructure still needs to be manually installed up to the OS, but it’s now installed on vms and not physical hardware – you win several capabilities like hardware abstraction, easier maintenance, better availability (of the OS), capacity optimization and much more (I’m not going to detail virtualization here, tons of blogs / books have already done so)
Cloud (public, private, hybrid – whatever) differs from Physical / Virtual Infrastructure by its additional services. Where the previous two were stuck to provide only CPU, memory, storage and an IP address, the Cloud brings new items that are part of an application : Load Balancers, subnets, additional disks, security…
When a company have Cloud capabilities, that usually means they’re able to provide compute like in Physical and Virtual (cpu, memory, disk, network connectivity), but also network objects (coming from SDN – software defined network), storage objects (coming from SDS – software defined storage) and any needed integration.
Last but not least, a Cloud platform allows automat-able consumption via API for the provisioning of resources.
These three types of platforms constitute the technological foundations. Companies will need to have at least one of these platforms to be able to run their IT. These platforms provide compute, network
This is why this group of platform is the “T” from BDAT: it’s the Technology, I mean you can implement any technologies on top of those platforms: any OS, any hardware device, any middleware / software.
“A”: IaaS, PaaS and XaaS
IaaS (means Infrastructure as a Service) is built on the “T” layer from previous paragraph. It’s not something providing physical resources to use such cpu, memory or network – instead, IaaS is the automation, integration and governance layer, that includes also several features to help the IT business like chargeback, service catalog or extensibility.
The objective of IaaS is to provide automated, on-demand workloads at the stage where OS is ready, installed and integrated into the information system of customer, e.g. the cmdb, antivirus or any other rule from the corp’s processes.
IaaS provides end-users access to a self-service to create their set of resources, where users can deploy their software and runtime to run their applications.
With this portal for self-service capability, even though it’s still technical, it’s accessible to more people than the physical/virtual/cloud infrastructure, which is purely technical – and it’s where the governance and organization model becomes unmissable.
PaaS (means Platform as a Service) goes deeper in the abstraction model as this is intended to provide a platform where you run the code. It’s still only automation and not a direct resource provider.
Output of a PaaS differs from IaaS in that end-users will obtain a runtime where they can directly execute the application code. OS is no longer important but only the runtime.
Reminder, from high level view a runtime is something where you put the “code” – it can be application code, database tables, internationalization content…
XaaS (acronym for Everything as a Service) is special because it can be really anything. It consists of automating something that may be IT-related (e.g. cmdb records) or completely outside the infrastructure (e.g. a notification service, or light intensity control of a bulb).
As for IaaS and PaaS, it is through a portal and governance that XaaS is controlled. The output of an XaaS request is a custom object.
There are sometimes other “platforms” such as CaaS, KaaS, IaaS ++, FaaS, MaaS… but in fact it is more about services of one of the types previously described than real different platforms. For example, CaaS and Kubernetes are IaaS- it automates the deployment of virtualized resources (containers). FaaS runs code directly on pre-designed runtime environments, so it’s a PaaS.
Myth: IaaS, PaaS and XaaS are not reserved for virtual machines (vms) – it’s possible to have IaaS automating Physical, as well as XaaS automating Cloud.
As said at the beginning of this section these services are deployed on the technical base “T” and are used to host the “A” (as Applications in BDAT)
“D”: NoCode, Service Mesh, COTS App, SaaS
These platforms take us far from conventional infrastructure. It’s still related to IT infrastructure, but it doesn’t take care of the lower layers.
NoCode allows to abstract the code: developers don’t use a specific language to code but a UI and algorithmic logic. This abstracts the code, the language used, and the runtime needed. It generates applications.
On another perspective, Service Mesh have several features but the most interesting are those to abstract configurations, service discovery and communications security. Those abstractions help to get rid of the complexity of the application architecture.
Communication between the services will be managed by the Service Mesh, developers will not have to worry about it anymore. Discovery will help on that space too, and can act on configurations to manage the scale operations on the application.
COTS App (Commercial Off The Shelf) and SaaS apps are quite similar – you buy the application, chosen because it meets the business need.
Difference is the SaaS app runs externally on an resource platform that you don’t own – some are hosted in the Public Clouds, other in the vendor’s datacenters – anyway, you don’t need to know.
COTS App will run on a “T“ech platform you own, its type will depend of the vendor’s prerequisites – you can’t choose (physical, vms, container, cloud…). More and more often, vendors provides automation to be integrated in an IaaS or PaaS platforms.
This group will host the “D” (for Data) of the BDAT, it can use the “T”ech platform or IaaS/PaaS, or none. In all cases, these platforms abstract the application and its architecture, you will have to care only of data with these platforms.
“B”: Business Layer
“B” stands for Business in BDAT acronym, there aren’t that many “platforms” that exist to host business – it depends heavily of the business vertical, and very often it’s more SaaS/COTS platforms rather than a business platform.
Telco have some platforms in that space, e.g. IPTV, SMS, CAS, CMS/CDN, BoxAPI…
AI and IoT platforms are also valuable B2B/B2C platforms, but they are still at the dawn of technology, and most commercial offers are more COTS / SaaS.
Put it all together
A picture is worth a thousand words, so there you go:
Bottom layer is the Technology. Layers Application and Data sits on top of the Technology layer, as it uses all or part of those tech to run, store or connect. Business cap the whole because it uses apps or data but not directly technology.
This representation is the same you might find in TOGAF architecture designs, in addition you have the mapping of the platforms and their abstraction/outcome levels: the higher is the box, the more it abstracts (in its space, not cumulative with other layers).
Paths are simple, it follows the stack of layered top-down, with the option “D” could use “A” as an accelerator, but it is not required.
To run a “B” (ex: SMS platform), you must have applications, either commercial (COTS) or your own from automated system *aaS, which is executed on one or more technical platform (physical-bare metal, vms, containers, cloud instances, private cloud objects for routing…).
Of course, depending of the platform chosen in a layer, you might not have all the benefits (height of the box) that the Tech/App/Data can bring to you.
For example, if you choose to run PaaS on Physical Infrastructure, you are loosing security, network agility, storage agility, easy operations, easy maintenance that Cloud (public or private) could bring instead.
This vertical dimension also shows other properties:
Go up means abstraction, more people concerned but also complexity, specialization and multiplicity of solutions to implement (restricts the area of possibilities).
Go down means technicality, less people concerned (only IT crew) but also simplicity, broader range of possibilities, number of solutions available on the market.
Sample Products Mapping
Below is a subset of existing products/solution for each of the platforms (boxes).
Physical: this is operating systems like Ubuntu, Windows, AIX. […] running on servers like Dell, HPe, Lenovo, Supermicro […] with processors architectures x86, ARM, MIPS […]
Virtual: VMware vSphere, Microsoft Hyper-V, Linux KVM, Docker containers, LXC containers
Cloud: AWS EC2, AWS RDS, VMware Cloud Foundation, DigitalOcean Droplets
IaaS: VMware vRealize Suite, Kubernetes, OpenStack, AWS CloudFormation. to a lesser extent, Hashicorp Terraform (still lacks several features of a IaaS, but continues to evolve)
PaaS: VMware vRealize Suite, OpenFaaS, AWS Elastic Beanstalk, VMware Tanzu Application Services, Heroku
XaaS: VMware vRealize Suite (still), Amazon SNS, Google Home
NoCode: SalesForce, Quixy, SurveyMonkey, Adobe Dreamweaver.
Service Mesh: Istio, Envoy, VMware NSX Service Mesh, Kuma, Hashicorp Consul
COTS App: Microsoft Office, VMware Carbon Black EDR
I didn’t represented the Business layer as applications are really specific to business case and company’s vertical.
To name a few from Telco, AI and IoT, there is: Azure IoT, VMware Pulse IoT, IBM Watson, Ericsson or Nokia telco solutions, Technicolor…
From a functional point of view, there is not so much difference between platform. Each has its strengths and differences of course, but from the outcome delivered this is close.
As the lower technologies are simpler and easier to maintain, there’s no shame to mix those technologies- running containers on vms themselves sitting on physical servers is not an problem, but a cumulative set of outcomes.
On the contrary, avoid technical sprawl when there is no clear need or on functionally equivalent products (e.g. have 3 hypervisors technologies to “avoid putting all your eggs in the same basket”), that multiply the people and process parts for close to zero gains.
There is no one platform that is the best, but a combination of those. Kubernetes (IaaS) orchestrates Containers (Virtual) and LoadBalancers (Cloud/Physical) to run workloads, but you can run also OpenStack (IaaS) with vSphere vms (Virtual) and network Segments (Cloud) for the same functional outcome: self-service, API-described workload runtime and its network objects where you then can deploy the application code.
Being aligned with one of the most famous architecture frameworks, TOGAF, at the design cycle (ADM) allows architects to match the platform needs for end-to-end architectures
Never assume that because you already have a platform it will be suitable for all uses. Depending on the App or Data, all Technical platforms could show value. It’s the same for App or Data, don’t assume reaching PaaS state brings you all capabilities you would require, or a commercial software (COTS) may not be sufficient for you Business case.