According to NIST, a PaaS is “The capability provided to the consumer is to deploy onto the cloud infrastructure consumer-created or acquired applications created using programming languages, libraries, services, and tools supported by the provider. The consumer does not manage or control the underlying cloud infrastructure including network, servers, operating systems, or storage, but has control over the deployed applications and possibly configuration settings for the application-hosting environment.”
But when do you deploy such a platform? This article describes six different reasons to implement a PaaS. The first three are more strategic in nature, whereas the last three present solutions to more tactical challenges.
Reason 1: Rationalising the application landscape
Many IT departments struggle in keeping up with the changes that digitisation brings – at least, so we are told by several large consulting firms. Whether or not this struggle is the large disruption that we are led to believe remains to be seen. It is not difficult, however, to notice a disconnect between requirements and expectations coming out of the business and the speed at which the IT department can answer to these. Requirements are not in sync with release cycles, which in turn are not facilitated by long-running contracts such as commonly found within (but not limited to) government organisations. Also, the average user has increasingly high expectations of business software and wonders why it is so difficult for the office environment to mimic the bring-your-own-device phone with its modern, snappy and often-updated apps.
To answer these questions, it is necessary to first perform a thorough examination of the corporate IT landscape, determine what its function should be in light of (robotic) automation and digitisation of processes, followed by a strategy formulation which proposes rationalisation of specific parts of that landscape. The actual process of rationalisation selects (keep, decommission, re-platform) and isolates promising Cloud migration candidates, with PaaS as the intended landing place.
But why rationalise in the first place? To increase cost effectiveness, for sure. But also as an important step towards the implementation of a more-speed-IT strategy, which I present as reason number two.
Reason 2: Implementing a more-speed-IT strategy
With the introduction of modern applications and modern software production processes, another disconnect becomes apparent: the one between fast-moving front-end applications and a relatively stable and static backend. The strategy of purposefully separating and (up to a certain extent) disconnecting the two is called Two-Speed (McKinsey, Gartner) or Multi-Speed (Accenture) IT. Others (for example Bain & Company and Forrester) argue that two-speed IT is not a solution, but a problem which for example manifests itself in choke points between the slower and faster moving IT. They argue that a paradigm shift for the entire IT department, moving towards a DevOps way of working, is a better way forward.
Regardless of who is right, IT departments are struggling with the question on which gear to shift to and when. The resulting more-speed strategy could result in a many vendor landscape – with new strategies come new platforms. Even though this is not necessarily a good thing per se (it involves managing multiple parties, for one), in reason 3 I argue that managing vendor dependencies and multiple tools might be easier with a PaaS.
Reason 3: Managing vendor dependencies and multiple tools
Many IT departments coming from a traditional one-to-few vendor landscape are confronted with many different tools that exist in more modern software development, such as Agile and DevOps. A DevOps pipeline typically contains a lot of (separate) tools for testing, monitoring, continuous integration and deployment. Traditional hardware-based infrastructure services are up to an increasing extent defined in software, such as firewalls, proxies, routers and load balancers.
The promise PaaS hold is to be the connecting element between these various tools, even though the platforms have not yet matured enough to fulfill the promise. There are different visions and ideas on how to approach this issue between for example “traditional” PaaS (OpenShift or Cloud Foundry) and Docker, particularly focused on the definition of the platform.
Of course, the implementation of the various tools that form the PaaS should never be treated as just a technical installation. As with many new IT concept these days, the organisational impact of a new tool cannot be underestimated. One could even argue about whether the change necessitates a tool or the other way around – and one of these changes is the introduction of DevOps, which I present as reason 4.
Reason 4: Supporting DevOps
DevOps, a combination of Development and Operations, aims to facilitate the integration between the two by automating – and not just technically – as much steps and tasks of the traditional engineering practice as possible. Its purpose is not to remove operations from the equation altogether but to simply break down the walls – operations are still necessary, albeit in a different form. A key assumption is that to operate something reliably, you must be able to automate, reproduce and repeat. With DevOps in place, shorter release cycles, greater stability and uptime become possible.
Where DevOps as a methodology shows its full potential is with the software architecture design paradigm that has been coming of age recently: micro- (or even nano-) services. With reasons 5 and 6, I argue that a PaaS is an excellent platform to build those microservices upon.
Reason 5: Implementing microservices
Microservices are often seen as an evolution of the service oriented architecture. In essence, a microservice is an abstraction of a software application to its smallest possible, reusable business functions. Think of it in light of Ken Thompson’s original Unix philosophy: “Do one thing and do it well”. The combination of functions in microservices then make up the application. In order to work together properly, microservices use a well-defined interface.
A caveat: producing microservices can be difficult and is not a definitive answer to software design challenges. For example, microservices by nature often involve distributed transactions (as application functionality is broken up and responsibility is delegated), which can become difficult to monitor and manage when the architecture grows.
Microservices can be implemented in various ways, but their stripped-down and bare essence nature requires a stripped-down and bare essence delivery vehicle. Therefore, it makes perfect sense to deploy microservices in containers instead of, for example, virtual machines. This I present as reason 6.
Reason 6: Moving from virtual machines to containers
A PaaS employs containers to deliver applications and application functionality. Management of the delivery process is done by the PaaS – which is also the primary distinction between a PaaS and a container platform or orchestrator such as Docker and Kubernetes. Containers are used because by design they allow running applications or application functionality in isolation on a single host, without the need for an additional virtualisation layer. This being said, it does not automatically make sense to port the contents of a virtual machine to a container. In other words: not all applications lend itself to porting to containers.
Will PaaS survive?
The original distinction made by NIST in IaaS, PaaS and SaaS has in the past few years slowly disintegrated. The number of Cloud service models has increased rapidly and most aim for the PaaS space, which begs the question what PaaS will evolve into in the future.
When comparing IaaS and PaaS, it is striking that both a PaaS and IaaS are sometimes deployed on raw infrastructure, whereas the distinction between what Pete Johnson of Cisco in his article on an OSI model for the Cloud calls the Software Defined Datacenter (SDDC) within IaaS and PaaS is not always clear. It looks like IaaS is moving closer to PaaS – and vice versa.
Container platforms and orchestrators such as Docker and Kubernetes are also philosophizing about the future. For example, Brendan Burns of Kubernetes sees a future where PaaS is built on top of container platforms, whereas current PaaS providers probably see this the other way around.
Finally, serverless computing (also mentioned as Function-as-a-Service, FaaS) is slowly gaining a foothold as well. It is possible to deploy functions directly in Docker containers, as I already explained in a different article.
The main difference between PaaS and its challengers is the focus PaaS has on the full developer experience. With a PaaS, it is possible to go from source to production in as few steps as a DevOps team can configure, all controlled and monitored by one single platform with a tightly integrated toolset. I am convinced that there is still room for a lot of improvements in this area. It will be interesting to see how PaaS continues to grow.
Epilogue: I do realise I never mentioned aPaaS, Application Platform-as-a-Service – a term coined by Gartner, if I am correct. This basically is an all-in-one, integrated rapid application development toolkit with which you can create a SaaS. Examples include Mendix and OutSystems. I personally think aPaaS and PaaS do not have much in common, other than they deal with applications – albeit in a totally different way.