The main objective of Platform-as-a-Service (PaaS) is to relieve the developer’s pain points, consisting mostly of daunting maintenance tasks that are outside of their workflow.
The goal of developers should be to create differentiating value for the business, not to drill into the complex and low-level issues of IT infrastructure - those carry no value and are just time sinks. PaaS exists to ‘industrialise’ IT’s best practices that can be executed seamlessly using highly optimised and fully automated software stacks that ultimately map transparently to the infrastructure layer.
By using a PaaS, developers can now fully focus on creating business value as they let the PaaS automatically instantiate, orchestrate, secure and monitor IT infrastructure.
In considering the following points you should be aware of the pros and cons for your own organisation and consider your IT organisation’s specific needs.
PaaS scope
Some PaaS solutions solely focus on the deployment stage, helping developers push applications to production and scale them, with no specific consideration on how the application being deployed was created in the first place. Other PaaS solutions have a wider scope, helping developers along the entire application lifecycle from development to testing, pre-production, staging and, finally, into production.
It is up to the user to define the scope of the problems that need to be solved. Also, a number of PaaS solutions provide easy access to an ecosystem of third-party providers that extend the core features of the PaaS with added-value services, nicely integrated with the PaaS solution’s core platform.
There is an obvious analogy that can be made with yesterday’s independent software vendor (ISV) ecosystems in the operating system and middleware era, except that in the cloud era, the integration between ISV’s solution and the main middleware offering is made available ‘out-of-the-box’, based on best practices, and fully supported with ‘one-throat-to-choke’.
Service or software?
While the ‘S’ in PaaS means ‘service’, a number of PaaS offerings would be better called ‘PaaSaaS’ or ‘Platform as a Service as a Software’. While such platforms are indeed still consumed ‘as a service’ by developers, these PaaS vendors distribute a traditionally packaged software that needs to be set up, configured and maintained on premise by the company’s internal IT team.
The difference between the two is significant, as maintaining a complete PaaS environment (including the underlying data center infrastructure) can be an arduous task that requires sophisticated IT skills, using such a platform is trivial, maintaining it is not.
If a company cannot afford such an investment or is purposely looking to externalise it for a certain type of application in order to get much faster time-to-market, they’re better off relying on a PaaS that is truly offered as a service. This means looking for a third-party provider that will not only service your company, but also thousands of other companies, hence having a real critical mass - and the necessary expertise for managing such a complex environment.
This externalised service component is often marginalised in discussions about the cloud: this is unfortunate, as ongoing maintenance is probably one of the most important value vectors of the cloud revolution. For example, if you are going to take on self-servicing your PaaS, you will be completely responsible for the operating system, application servers, virtual machine set-up, maintenance, security patching, monitoring, backup as well as any version upgrades, all while preserving the existing applications.
With a full-service PaaS, you won’t even see those activities; they’ll be performed for you, in the background, in a continuous fashion - you can focus on creating business value. Another way to look at this is to ask yourself whether you would be better off hiring a new application developer or an engineer responsible for installing and configuring Linux and your middleware stack.
Private, public or hybrid cloud:
Some PaaS offerings make you choose between operating on a public or private cloud, while others can support both. Depending on the requirements at hand, this might become an important selection criterion. It’s important to note that private-only PaaS solutions are typically offered as traditional packaged software that you or your IT team will have to operate and maintain (see previous point).
Hybrid PaaS can exist in two variations. The first one is very much a private PaaS, operated by your central IT, that offers a way to push some of your applications to one of the third party, public IaaS providers; as such they can be defined as ‘hybrid-from-private’.
The second variant are public PaaS solutions (hence operated and supported by the PaaS provider, not your central IT) that offer you a way to securely leverage your on-premise resources as part of your public cloud deployment.
This can either happen by offering a downloadable software appliance that will run on your servers and be remotely managed and maintained by the PaaS provider or offer à la carte virtual private cloud (VPC) or virtual private network (VPN) services to make it possible to access core IT resources (ERPs, databases, CRMs and so on.) from public cloud deployments. These two scenarios can be defined as ‘hybrid-from-public’.
One of the most logical reasons for running a workload on-premise (whatever the hybrid PaaS variation is) instead of on the public cloud is related to being able to access legacy resources - such as databases, mainframes, ERPs and so on - with low-latency connectivity, which a WAN connection would not provide.
While security concerns are frequently raised as a way to justify on-premise deployments, this justification is too rarely grounded in reality. Such restrictions are mostly based on off-the-shelf (and aging) security policies rather than on an objective risk assessment. One typically tries to compare what the ideal security processes are (by the book) versus what the cloud offers.
However, it would actually be more appropriate to compare the level of security offered by cloud providers (PaaS or IaaS) versus the actual security implemented within most IT organisations. In such a comparison, the cloud provider is likely to come out on top, because the provider’s practices have been formed to address the stringent requirements of many organisations.
Furthermore, a number of existing security policies do not take in account the growing need for mobile applications and the changes they force. The good old use of ‘firewalls’ defining where corporate data was allowed to reside based on what was ‘in’ versus ‘out’ of the firewall demarcation line do not really apply anymore. For example, to be of any value, mobile applications have to leverage corporate data.
IaaS-like or SaaS-like:
Some PaaS solutions - which can be defined as IaaS-like - tend to offer more focus on the underlying infrastructure used to operate the PaaS (operating system, JVM, application servers, drivers and so on). Other PaaS solutions are more SaaS-like - these offerings tend to focus more on use cases that the developers will need to do their job, and fully abstract the underlying infrastructure required to implement those use cases.
Initially, having more control over the underlying infrastructure can be perceived as a good thing, especially as existing developers are used to caring about those issues, and releasing control over them is a mental shift. Yet keeping that infrastructure flexibility typically leads to complications and increased costs down the road, since this customised infrastructure will have to be managed for the foreseeable future by the organisation itself (hence, the development team), as this will be outside of the normal scope that the PaaS provider offers: PaaS providers cannot support customised stacks; they are all about standardised best-of-breed stacks, at scale.
The main goal in using a PaaS offering is to free development teams from IT infrastructure maintenance and allow them to focus on accelerating software delivery thus returning value to the business. However, all PaaSs are not created equal, so choose carefully and evaluate them thoroughly against your specific PaaS goals. The four areas discussed in this article are a good starting point in helping you to do that.
