In my last post, I described the eureka moment I’d had whilst using Cloud Foundry. I’d suddenly realised the fantastic benefits of treating your Platform as an Application. I’d then decided this pattern needed it’s very own acronym “PaaA” to highlight the distinction from using a “Platform Application Delivered by someone else as a Service” (i.e. a what is traditionally called PaaS).
In hindsight it is really obvious that PaaA is a good idea – if it wasn’t, why would PaaS providers (who manage platforms commercially on industrialized scale for a living) bother doing it? In this post I’m going to define the features that I think any self-respecting Platform Application should have.
A quick aside: Should you build or buy/reuse a Platform Application? There are plenty of applications available to buy/reuse:
- the Cloud Foundry Platform Application that is also available as a PaaS from Pivotal,
- the Open Shift Platform Application that is also available as a PaaS from RedHat,
- the Stratos Platform Application that is also available as a PaaS from WSO2).
In my opinion, since we’re treating our Platform as an Application, the usual build vs buy logic should be applied! However (not to avoid the question entirely), my advice is that if you are in a greenfield scenario you should try buy/reuse, and if you already have a platform, start an initiative to move towards treating what you already have platform-wise more like an application.
So if we are treating our Platform like an Application (PaaA), what should it do?
Firstly we need a name for the part of the IT solution which is not the platform. It’s tempting to take a platform-centric position and call it the Guest Application (since it resides and functions on the platform). I fear some may consider this name derogatory, so for lack of a alternative, I’m calling it the Business Application. In terms of cardinality, I would expect any Platform Application to host one or more Business Applications.
The most basic requirement of a Platform Application is that it can provide the run-time operating system and middleware dependencies needed for the Business Application to run. For example if the Business Application is Java Web Application requiring a Servlet Container, the Platform Application must provide that. If an RDMS e.g. PostgreSQL is required, the platform must of course also provide that. To put it another way, we’re treating the whole environment minus the Business Application as being something the Platform Application must supply.
All applications should be build-able from version control and releasable with a unique build number. A Platform Application is no different and they also need a fully automated and repeatable installation (platform deployment) process, i.e. you should be able to fully destroy and recreate your whole platform (aka phoenix it) with great confidence. You should also be able to make confident statements like “We completed all our testing on version 22.214.171.124 of the platform”. (My use of version number resembling Semantic Versioning was deliberate as I believe it is very useful for Platform Applications.)
A Platform Application should abstract the Business Applications that run on top of it from the underlying infrastructure i.e. the servers, storage and network. Whilst doing this, the Platform Application must provide infrastructure features to level of sophistication required by the hosted Business Applications for example auto-scaling and high-availability / anti-fragility. A nice-to-have feature is some built-in independence of the underlying infrastructure solution. This provides a level of portability to deploy the Platform Application to different physical, virtual and cloud infrastructure providers.
A Platform Application should work coherently with your software delivery lifecycle. For example it must have a cost effective solution for supporting multiple isolated test environments. For example Cloud Foundry instances supports multi-tenancy through Spaces of which you can create multiple per Platform Application instance.
A Platform Application must make the process of performing fully automated deployments of the Business Applications onto it trivial. Of course the release packages of the Business Applications must conform to the required specifications. This includes both the binary artefacts format e.g. War files and any required configuration (aka manifest) files.
There are a number of main security concerns for a Platform Application. It needs an authentication and authorisation solution for controlling administration of the platform e.g. who can perform Business Application deployments or create new environments. The platform must have an appropriate solution for securely managing keys and certificates required by the Business Applications. Finally the Platform Application must support the access protocols required by the Business Application e.g. https.
There are a number of logging concerns for a Platform Application. Of course it should create adequate logs of its own so that it can be operated successfully. It also needs a solution for managing the logs of the Business Applications, for example an inbuilt aggregation service that could be based on LogStash, Kabana, ElasticSearch.
Finally there are monitoring concerns for a Platform Application. Of course it needs to monitor itself and the underlying infrastructure that it is managing. It also needs to provide a standardised solution for monitoring the Business Applications deployed onto it.
I’d love to hear if anyone thinks of other core features that I should add to the list.