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 an 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 such as 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. In other words, 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 18.104.22.168 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.) While doing this, the Platform Application must provide infrastructure features to the level of sophistication required by the hosted Business Applications, for instance, 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.
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 such as War files and any required configuration (aka manifest) files.
There are a number of major security concerns for a Platform Application. It needs an authentication and authorization solution for controlling administration of the platform, such as 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, such as https.
There are a number of logging concerns for a Platform Application. It should obviously 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 standardized solution for monitoring the Business Applications deployed onto it.
What have I missed? I’d love to hear from you if there are other core features that I should add to the list.