In this blog I’m going to propose a design for modelling a Platform Application as a series of generic layers.
I hope this model will be useful for anyone developing and operating a platform, in particular if they share my aspirations to treat the Platform as an Application and to:
Hold your Platform to the same engineering standards as a you would (should?!) your other applications
This is my fourth blog in a series where I’ve been exploring treating our Platforms as an Application (PaaA). My idea is simple, whether you are re-using a third Platform Application (e.g. Cloud Foundry) or rolling your own, you should:
- Make sure it is reproducible from version control
- Make sure you test it before releasing changes
- Make sure you release only known and tested and reproducible versions
- Industrialise and build a Continuous Delivery pipeline for you platform application
- Industrialise and build a Continuous Delivery pipeline within your platform.
As I’ve suggested, if we are treating Business Applications as Products, we should also treat our Platform Application as a Product. With 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.
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.
So here is it is:
Starting from the bottom:
- Hardware management
- 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 two 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
- Basic Infrastructure orchestration
- Consists of: Cloud console and API equivalent. See this layer as described in Open Stack here
- 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. 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
- Platform Infrastructure orchestration (auto-scaling, resource usage optimisation)
- Consists of: effectively a software application built to manage creation of the required infrastructure resources required. Holds the logic required for auto-scaling, auto-recovery and resource usage optimisation
- 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
- Execution architecture
- 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
- Logical environment separation
- Consists of: logically separate and isolated instances of environments that can use 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 (aka Spaces) where code can be deployed
- Deployment architecture
- Consists of: the orchestration and automation tools required 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
- Security model
- Consists of: a user directory, an authentication mechanism, an authorisation mechanism
- The owner of this later can make the call: “These authorised people can do the 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 authorised users to be able to use my platform application”
I’d love to hear some feedback on this. In the meantime, I’m planning to map some of the recent projects I’ve been involved with into this architecture to see how well they fit and what the challenges are..