Some thoughts on the benefits of Platform as a Service, to support operational and development environments. In particular, an open source PaaS. Would welcome comment and feedback.
Introduction
For further reading on PaaS benefits see the list below. Be wary of some claimed benefits or disadvantages as many of these are specific to a domain or commercial providers business model.
The PaaS platform covers development, test and production, providing significant benefit for development through automation of integration and deployment tasks, speeding up the velocity of development.
Based on conversations with customers, the main drivers for a DevOps projects (and the PaaS needed to support it) are:
- Velocity in production, ie shorter time to market
- Getting greater efficiencies from the development and the operational processes.
- Be able to deliver future projects and meet the challenges they will provide.
Further reading on PaaS benefits:
http://www.theresearchpedia.com/research-articles/top-10-benefits-of-paas
Application isolation / platform isolation
Most existing applications are dependant on other applications, interfaces or data. Whilst an application platform that might be designed and developed to be ‘loosely coupled’ to other systems, in practice this might be difficult to achieve. This might be for a number of reasons:
- Common platform
- Shared libraries and sub-applications
- Interfaces to data and other applications
PaaS architecture, such as provided by Red Hat’s OpenShift are based around software containers which in turn allows for logical separation between application platforms. However to make this happen, any existing application destined for a PaaS architecture needs to be designed in a ‘cloud native’ way and as such needs a rewrite rather than just a replatform.
PaaS supports DevOps
Though a strong statement, getting any architecture for DevOps to work without some form of PaaS is highly unlikely. This is for a number of reasons:
- Providing environments for projects
- Providing the automating functions needed, such as Behaviour Driven Development, automated testing, continuous delivery etc
- Metrics and monitoring on the development lifecycle and production performance
Push button infrastructure (PBI)
PaaS deployments can be fully automated and therefore happen both quickly and on demand. It would be envisaged that a PaaS platform would be constructed either from a fixed list of components or from a predefined menu of options.
As well as reducing time spent requesting (and waiting for) environments, PBI will ensure consistency in reproduction for different environments. As well as including the operating system, the PBI will include development tools, monitoring and other infrastructure tools as standard, already built and configured for the environment.
Having a PBI deployed via the PaaS will require the PBI itself to be developed (rather than operated) and will have its own Continuous Delivery pipeline. It will in effect be software (Infrastructure as Code) and similar teams and processes as a application development project.
Red Hat uses a PBI approach for it’s Open Innovation Lab, which allows time and effort to spent on development rather than set-up, see https://www.redhat.com/en/explore/open-innovation-labs
Figure : Push-button infrastructure tech stack used as part of Red Hat Open Innovation Lab. It includes development platforms and tooling as well as links to commonly used services.
Platform choice, based on cost, performance, functional and non-functional requirements
A PaaS would provide a limited menu to projects to select an appropriate platform based on performance, likely cost and the stack required. This would have restrictions on the applications and tools available to developers, as well as versions, though it would ensure the use of enterprise ready software.
What would be included in the stack would be reviewed from time to time with recommendations from development teams and also from Enterprise Architects based on what will strategic best practice. Limiting the choice of software and tools has other benefits:
- Improving consistency in operation of software
- Ensuring skills and knowledge between stacks is good and that staff can be transferred between projects.
Predictable Cost
Using a PaaS platform, with the characteristics it provides does provide some level of predictable cost, which can be charge based on platform sizing and function. Alternatively some form of chargeback or cost indication could be based on utilisation.
Any costings, real or relative, will be using when comparing on premise hosting versus public cloud service provision to make a real estimate of development and operation costs for a platform.
Running as Projects with Policy and Advisory Input
In a typical development world, there are a number of projects being developed at any one time, within a framework of Discover, Design, Deliver, Operate, Retire. At the same time taking advice from organisational functions (such as Enterprise Architecture, Security, Change Management etc).
Through automation, checkpoints and best practices can be automatically applied or check pointed if a development process is using a viable PaaS platform. It provides the ‘junction’ that link these two different groups within the organisation together.
Support for Coding Standards and Design / Architecture Best Practice.
As with many organisations, there are no standings for architecture, design or coding that are implemented organisation wide. . These could be included images deployed on the PaaS, as mandatory policies for testing for example. Coding templates and standards could be included in the IDE or Dev environments and therefore be in place to encourage usage and adoption.