Application Platform 101
When building or evolving application services it can be considered best practice to offer your consumers the highest level of technical abstraction. It helps maintain focus on the business problem being addressed in the most suitable and expedient manner. However, there needs to be recognition that some compromises will need to be made along the way. This is because elements of control will often be lost and replaced with opinions that must be observed.
A SaaS service is the most common ‘highest-level’ abstraction based on consumption and subsequent configuration and integration (where required) of SaaS services. At the other end of the spectrum, the lowest level of consumption in this model involves the birthing and constant nurturing of unique and often hand-crafted services, frequently now referred to as a ‘snowflake’.
Application Hosting Stack Tetris
In my recent articles concerning containers, I discussed the basic principles and current state of their evolution. They have evolved to a point where the container management functionality can become autonomous, with most of the basic infrastructure concerns abstracted (or hidden) from the consumer through the delivery of a container platform.
The UX exposed from a container platform is quite familiar to infrastructure operations teams in particular due to their industrialisation efforts of automation and autonomics replacing manual processes.
However, in contrast this often means that the UX exposed is a sub-optimal one for developers to consume. To serve developers and application operators alike, containers should be considered a start but not the goal. This is down to the fact that the container UX is still technical and quite complex, whereas the developer / operator requires a UX that abstracts this further, exposing only the elements required to perform their task at speed and with ease. In effect, this elevates the abstraction further introducing additional opinionated ‘guard rails’ from the platform.
Enter the Application Platform
To address this shortfall, enter the emergence of the application platform. In the early days of its evolution it was referred to as PaaS (Platform as a Service). However, with the proliferation in the use of the platform term, this has now commonly evolved to “application platform” thus more accurately reflecting its purpose.
It is worth noting at this point that all application platforms rely on containers within their technical fabric, some predate the emergence of popular container platforms as some simply ‘wrap around’ them.
Whichever the application platform type, the primary focus of them is to simplify their use to a developer by minimising the touch points and concern surface area. Their intent is to allow the developer to focus on building business value and not be bothered about the undifferentiated heavy lifting required to operationalise the run of the services they build.
From a developer UX perspective, the application platform exposes an easy to use interface, from here the developer presents their code and information regarding the desired state. The application platform takes the code, builds it, deploys it and runs it based on the desired state specification.
The desired state specification can include but is not limited to:
- Application exposure attributes
- External / internal, URL, HTTP/TCP, etc
- Backing service requirements
- Application resource requirements
- RAM, CPU, Disk
- Application instance count
- Application scaling policy
With many of these having platform default values which will automatically be applied, should they not be directly specified in the desired state specification.
The application platform exposes these executable tasks via an API, this enables the whole process of application deployment and run to be automated in a pipeline process.
The application platform makes available as a service aggregate (all the application instances) the associated logs which can either be ‘tailed’ in real-time or posted into long-term storage for future analysis and trending. These logs are also made available via the application platform API, making it a straightforward task to integrate into log management solutions.
The application platform provides standard integration points for application monitoring solutions, automating the ability to present real-time and historic performance and issue information.
The application platform also includes mechanisms to execute non-disruptive updates and remediation tasks, ensuring that the application services it hosts have zero outages due to underlying maintenance.
By providing these features to a developer, whilst at the same time further abstracting the complexity to them, the application platform offers a UX which is much more conducive and also minimises adoption friction.
In the next post, we will take a high-level look at two popular application platforms, one that predates the emergence of container platforms, Cloud Foundry and one that has embraced the emergence of container platforms by wrapping around one, OpenShift.