This post will be the first in a series of posts that will outline a generic Platform as a Service (PaaS) reference architecture. This is an extremely important topic because it allows everyone to calibrate their thoughts and lexicons in an implementation-independent way.
As you read further, consider this an open topic and feel free to post any questions or comments you might have. I view this as a collaborative, community effort, so input is welcome.
Like any complex, distributed system, the architecture of PaaS software can have a significant impact on how:
The following framework overview proposes an architecture that maximizes the benefits and minimizes the risks of the above impact points. Before delving into the architecture itself, it’s important to define the people and process context that a technology operates in and intends to improve. To do this, we’ll define the actors that participate as constituents in a PaaS environment.
It’s important to note that we are only concerning ourselves with PaaS within the enterprise scenario: that is, a PaaS operated by an enterprise for the benefit of that enterprise. Many enterprises are organized with a central IT function and multiple Lines of Business (LOBs) drawing IT needs from that central IT resource and/or Lines of Business with their own self-contained IT functions.
A private PaaS ecosystem of this sort requires a few key actors:
1. Platform Operators – Platform Operators (POs) are responsible for the implementation and operation of the PaaS, including, but not limited to, the health of the PaaS and, in some cases, the entire supply chain of resources that the PaaS depends on. Platform operators tend to be individuals within IT who have typically been responsible for shared services such as web hosting, or are part of newly formed “innovation groups” that arise out of the CIO’s office or enterprise architecture teams.
2. Developers – Developers (Devs) are the primary consumer of the PaaS, who use it to build, deploy and execute apps. Developers generally report to LOBs (although there are instances where many, or even all, developers report to IT).
3. End Users – End users consume the applications built by developers that are running on the PO-run PaaS environment. End users may be employees of that specific company or may be external to the company (e.g., customers, partners).
Many will argue that the traditional organizational structure is antiquated and needs to be dismissed in order to properly support PaaS. While ideologically this is true, a PaaS reference architecture should be designed in consideration of the current state if it is to be adopted in practice. As a supply chain, the relationship is as follows:
Note that the “Current IT Actors” box is colored differently. Current IT Actors are part of the IT supply chain that leads to a PaaS, but for the purposes of this framework, are not considered formal actors of the PaaS scope. Primarily, this supply chain flow serves as a foundation for capturing the relationships between people, which will inform the descriptions of the interactions between these people. Additionally, the supply chain helps one understand what sort of control scopes are necessary and how control and rights are delegated down the chain.
Using the supply chain model and the simple notion that “Platform operators run the PaaS for developers who build apps for end users,” it becomes much easier to define a list of coarse verbs that a PaaS should equip each actor to do. These verbs are critical to understand because they define the end state that PaaS is designed to support. Building a reference architecture is an exercise in ensuring that a system can achieve that minimum outcome, and at a maximum, support critical optimizations.
Install the PaaS – Sufficient tooling should exist to allow a platform operator to install the platform on whatever infrastructure she chooses; ideally using the enterprise’s standard OS images.
Manage PaaS capacity – A platform operator can expand or contract capacity by adding or removing new OS nodes.
Manage developers – A platform owner can control which developers and development teams have privileged access to the PaaS.
Manage applications – Although developers will control their own applications, a platform operator needs the ability to manage applications across the entire PaaS. Application management includes the deployment and tear-down of application instances, migration of applications to other parts of the infrastructure, and inspection of application details at runtime.
Manage deployment rules – A platform operator needs to be able to express placement rules that shape application deployment. Because of regulation, infrastructure expectations, and developer expectations, workload placement decisions are non-trivial and extend beyond placement related to resource needs (for example, apps matching X regulatory need MUST be deployed to this pool of servers and not that pool of servers).
Manage security – Platform operators need to broadly enforce security across the PaaS and its guest applications (for example, a platform operator can require that all guest apps expose only SSL-protected endpoints, so the PaaS should equip the platform operator with the ability to do so).
Manage maintenance – A platform operator can deploy and manage updates to the PaaS platform.
Manage resource policies – A platform operation can use policies to divide resources, including CPU, memory, and storage, into profiles that developers associate with their applications.
Curate off-platform services – Platform operators can add, remove, and manage external services (e.g. MongoDB, a CICS mainframe, etc.) that the guest applications can bind to.
Define deployment enhancements – The PaaS operator can intercept the deployment pipeline and modify deployed assets to enhance those deployments with additional, implicit capabilities (for example, a platform operator may want to attach performance monitoring to any application deployed).
Monitor and manage errors – A PaaS should monitor all applications for error states and should provide platform operators with tools to inspect errors and influence what happens when errors occur.
Optimize workload placement – A platform operator can modify policies that help improve application density on the PaaS. This includes workload packing strategies as well as workload rebalancing.
Access utilization information – A platform operator should have API and/or UI access to all utilization info associated with guest applications.
View and control auditing – A platform operator should have access to audit logs and be able to shape auditing expectations.
Define an application project – A developer should define an application to the platform. This includes creating a “project” and uploading application assets such as scripts and binaries for a composite, multi-tier application. If a PaaS does not acknowledge internally modular, composite applications as part of its “push” verbs, developers will likely discover that managing large, composite applications is near to impossible using just the PaaS.
Configure an application – A developer can configure an application via either a configuration manifest file or by directly manipulating static configuration associated with an application project.
Specify resource needs – A developer associates resource policies created by the platform operator with the various components of their application, based on their respective compute and/or storage needs
Deploy/Undeploy applications – A developer can deploy and undeploy applications that they have configured on the PaaS. The developer has control over “activating” the application on the infrastructure.
Define authentication schemes for applications – A PaaS should allow a developer to control authentication and entitlement schemes for access to applications they’ve deployed on the PaaS.
Scale an application component out/in – A developer can horizontally scale specific application components. Minimally, the platform should allow manual invocation. Ideally, the PaaS exposes automatic scaling mechanisms based on component health or time schedules.
Create a new application version – A developer can define an application version lineage, ensuring that the PaaS has the necessary information to properly manage an application’s lifecycle as it evolves.
Control application entry into various lifecycle phases – A developer with the correct privileges can manage an application’s transition from one lifecycle phase to another.
Manage application meta-characteristics – A developer communicates metadata to the PaaS for use as input in certain automated or autonomous decisions, such as application scheduling.
Monitor application performance and state – The PaaS should expose information to the developer regarding runtime health and performance characteristics of an application so the developer can make informed decisions related to key actions, including scaling.
Control end-user access – A developer can control which end users have access to deployed applications.
Bind application to external services – The PaaS must expose controls to the developer that allow the developer to express an application’s external dependencies. The PaaS must broker configuration and/or access to those services.
Interact via API and CLI – A developer can interact with the PaaS via an API and CLI. (A natural consequence is that developers can use UI or IDE integrations based on the API or CLI primitives.)
This isn’t an exhaustive list, but it sets a foundation for the most important actions. As a reference architecture, this is likely close to a list defining a minimally viable PaaS. A logical component model for a PaaS that can execute these verbs is as follows:
In a later post, I’ll explore details of various core components. For this post, the focus will be on two macro layers in the reference architecture. The verbs require that a PaaS execute actions at various levels of trust and security. As such, a proper PaaS architectures should be broken up into at least two primary “Spaces:”
These two spaces are surrounded by peripheral APIs and tooling, which include spanning components such as a coordinated policy manager. These core spaces and peripheral components work in unison to aggregate infrastructure into a shared hosting platform for composite, n-tier applications.
Additionally, a PaaS should not explicitly provide infrastructure automation capabilities below the application configuration layer. There are many tools in existence that work very well for automating the provisioning of OS images (whether virtualized or bare metal). Having the PaaS take on tasks related to infrastructure automation creates unnecessary coupling and risk (both architectural and economic) and removes the prospect of leveraging best of breed tooling at the automation tier.
A PaaS should have first-class awareness of composite applications defined as loosely coupled components. Any PaaS lacking this awareness will have an inherently difficult time providing practical support for more sophisticated enterprise applications. In this context, “support” means that the PaaS provides a Composite Application Modeler (CAM) that either:
A PaaS architecture should be able to recognize application components in a type-specific way, and map those types to infrastructure and service needs.
My next set of posts related to PaaS reference architecture will dig deeper into control scopes, the logical components that make up a PaaS, and will discuss guest application and policy architecture more comprehensively. In the meantime, feel free to leave any comments or thoughts, but beware that those comments might force me to write more follow-up posts.