As we continue to explore treating our Platform as an Application (PaaA), I would like to share my proposed design for modelling a Platform Application as a series of generic layers.
If we are treating Business Applications as Product, we should also treat our Platform Application as a Product. With this approach in mind, clearly a Product Owner of a Business Application (e.g. a website) is not going be particularly interested in detail about how something like high-availability works.
A Platform Application should abstract the applications using it from many concerns which are important but not interesting to them.
You could have a Product owner for the whole Platform Application, but that’s a lot to think about so I believe this reference architecture is a useful way to divide and conquer. To further simply things, I’ve defined this anatomy in layers each of which abstracts next layer from the underlying implementation.
From the bottom up:
Consists of: hypervisor, logical storage managers, software defined network
The owner of this layer can makes the call: “I’ll use this hardware.”
Abstracts you from: the hardware and allows you to work logically with compute, storage and network resources
Meaning you can: within the limits of this layer (e.g. physical capacity or performance) consider hardware to be fully logical
Presents to the next layer: the ability to work with logical infrastructure
Consists of: cloud console and API equivalent.
The owner of this layer can make the call: “I will use these APIs to interact with the Hardware Management layer.”
Abstracts you from: having to manually track usage levels of compute and storage as well as monitor the hardware
Meaning you can: perform operations on compute and storage in bulk using an API
Presents to the next layer: a convenient way to programmatically make bulk updates to what logical infrastructure has been provisioned
Consists of: effectively a software application built to manage creation of the required infrastructure resources. Holds the logic required for auto-scaling, auto-recovery and resource usage optimization
The owner of this later can make the call: “I need this many servers of that size, and this storage, and this network.”
Abstracts you from: manually creating the scaling required infrastructure and from changing this over time in response to demand levels
Meaning you can: expect that enough logical infrastructure will always be available for use
Presents to the next layer: the required amount of logical infrastructure resources to meet the requirements of the platform
Consists of: operating systems, containers, and middleware (e.g. Web Application Server, RDBMS)
The owner of this later can make the call: “This is how I will provide the runtime dependences that the Business Application needs to operate.”
Abstracts you from: the software and configuration required your application to run
Meaning you can: know you have a resource that could receive release packages of code and run them
Presents to the next layer: the ability to create the software resources required to run the Business Applications
Consists of: logically separate and isolated instances of environments that can used to host a whole application by providing the required infrastructure resources and runtime dependencies
The owner of this layer can make the call: “This is what an environment consists of in terms of different execution architecture components and this is the required logical infrastructure scale.”
Abstracts you from: working out what you need to create fully separate environments
Meaning you can: create environments
Presents to the next layer: logical environments (a.k.a Spaces) where code can be deployed
Consists of: the orchestration and automation tools required to release new Business Application releases to the Platform Application
The owner of this layer can make the call: “These are the tools I will use to deploy the application and configure it to work in the target logical environment.”
Abstracts you from: the details about how to promote new versions of your application, static content, database and data
Meaning you can: release code to environments
Presents to the next layer: a user interface and API for releasing code
Consists of: a user directory, an authentication mechanism, and an authorization mechanism
The owner of this later can make the call: “These authorized people can make the following changes to all layers down to Platform Infrastructure Automation.”
Abstracts you from: having to implement controls over platform use
Meaning you can: empower the right people and be protected from the wrong people
Makes the call: “I want only authenticated and authorized users to be able to use my platform application.”