Skip to main content Skip to Footer


October 20, 2015
Proposed Reference Architecture of a Platform Application (PaaA)
By: Mark Rendell

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.

Proposed Architecture:


From the bottom up:

  • 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 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

  • Basic infrastructure orchestration
    • 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

  • Platform infrastructure orchestration (auto-scaling, resource usage optimization)
    • 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

  • 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 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

  • Deployment architecture
    • 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

  • Security model
    • 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.”

Industry & topics highlighted


Popular Tags

    More blogs on this topic



        COMMENTS (0)




        Your Data Privacy

        By providing your e-mail address, you agree to the terms
        outlined in our privacy statement associated with
        commenting on the site. Your e-mail address will not be
        used for promotional marketing purposes.

        Change the CAPTCHA codeSpeak the CAPTCHA code