The case for a platform design

Part 1: Explore and Define

Introduction

In this series of articles I want to explore the concept of platforms. To start off I want to set the direction with a quote I found online. For me the quote is inspiring but also shows how vague this world still is.

“Kubernetes is a platform for building other platforms. It’s a better place to start; not the endgame” – Kelsey Hightower

We know Kubernetes is the new hotness and that the market for it is growing rapidly, but how do we use it? Or even better how do we use it properly? What problems does it solve and what solutions does it offer. Why is it called a platform? But more important how does it add value to our business?
Let’s explore to give it more context. Discover where to place the platform and see what platforms are out there. Let’s look back at the quote and see if we can use that. As it stated it’s apparently a platform for building other platforms. It sounds interesting, but also confusing. Let’s try and define what a platform is to establish a ubiquitous language.

A definition.

Explore

This is a nice visual that I will borrow from our friends over at Pivotal that will show the layers of abstraction in a decent fashion. They call it a strategic goal for me it is a visual of the order that the tools fall into. Let’s start at the bottom and work our way up. At the bottom you can see the lowest abstraction and at the top the highest one.

1. Hardware
2. Virtual Machines (VMs)
3. Infrastructure as a Service (IAAS)
4. Containers as a Service (CAAS)
5. Platform as a Service (PAAS)
6. Functions as a Service (FAAS)
7. Software as a Service (SAAS)

The list above is sorted by abstraction layers. The lower the number in the list, the less abstracted it is. However this comes with more control. The lower the number the more control you have. The question you have to ask yourself is, is more control always better? As you can understand more control means more work for example it is possible to put an application on hardware, but if you want to scale it you will have to goto your data center and add more servers and install the application on it and then I haven’t even talked about serving traffic to it. Going up into the list will help. For example if you would be using a cloud (Infrastructure as a Service) to host vm’s it would be easier to scale.

As you can see with this list Kubernetes is not the highest abstraction level. In this case Kubernetes is at number four and the PAAS’s are at five. Which enables us to reason that Kubernetes is not a platform but a CAAS. Why is this important? Well it further explains the statement that Kubernetes is meant for building platforms. Having something lower in the abstraction layer build something more complex in abstraction makes sense.

Define

The case I want to make is actually pretty easy. The solution however is not. Take the list above. Try naming a product that is part of that group excluding the hardware. VM’s can be VMware with ESXi. IAAS can be any cloud provider like gcloud. CAAS is obviously kubernetes. FAAS can be Knative to stay in the kubernetes region. PAAS is where most people have difficulty naming one. Why is that? Well because there is no definition of what a platform is. Even if they can name one then people can debate if it really is a platform.

For me a true platform is something like Cloud Foundry, but based on what arguments? It deals very easily with workloads and the dead simple cf push gives the feeling of an abstraction. However this is very application specific. As a developer this is great but is a platform only for a developer? Remember the higher you go the higher the abstraction, but should an abstraction have a specific audience? In Cloud Foundry’s case it wants to serve workflows from developers and does that in a simple way.

If we look at the list not of abstractions, but more a list of interfaces in the Object Oriented Programming kind of way then it’s easy to reason that products like Kubernetes are instances (objects) of the CAAS layer. They offer a way to handle containers for you. Just like Mesos or even Fleet. They fit the bill. Cloud Foundry in my opinion fits the bill for being a PAAS. With this kind reasoning we could reverse engineer the concept of the interface called PAAS.

If you read this far, then you will have gained a bit more knowledge about platforms and hopefully left you wondering what a PAAS is or will be. To continue this line of blog posts I will dive deeper into the Interface that will define the PAAS and maybe the instances that might come from this.

Hopefully you have enjoyed this blog post and questions are always welcome in the Disquss below.