Logically nestled just above Infrastructure-as-a-Service and just beneath the Software-as-a-Service applications it seeks to support, we find Platform-as-a-Service (PaaS).
As you would hope from any notion of a platform, PaaS comes with all the operating system, middleware, storage and networking intelligence we would want — but all done for the cloud.
However, as good as it sounds, critics say PaaS has failed to deliver in the practical terms. PaaS offers a route to higher level programming with built-in functions spanning everything from application instrumentation to a degree of versioning awareness. So what’s not to like?
Does PaaS offer to reduce complexity via abstraction so much that it fails through lack of fine-grain controls? Is PaaS so inherently focused on trying to emulate virtualised hardware it comes off too heavy on resource usage? Is PaaS just too passé in the face of Docker?
Proponents of Docker say this highly popularised (let’s not deny it) containerisation technology is not just a passing fad and that its lighter-weight approach to handling still-emerging microservices will ensure its longer-term dominance over PaaS.
Dockerites (we’ll call them that) advocate Docker’s additional level of abstraction that allows it to share cloud-based operating systems, or more accurately, system singular.
This light resource requirement means the Docker engine can sit on top of a single instance of Linux, rather than a whole guest operating system for each virtual machine, as seen in PaaS.
There’s great efficiency here if we do things “right” – in other words, a well-tuned Docker container shipload can, in theory, run more application instances on the same amount of base cloud data centre hardware.
Ah, but is it all good news? Docker has management tool issues according to naysayers. Plus, Docker is capable of practically breaking monitoring systems, so say the IT monitoring tools companies. But then they would say that wouldn’t they?
Let’s remember, Docker is only one container technology (Google has one too) and containers have been around for almost a decade now, but there’s still a heated and often slightly confused debate going on around this topic.
Things get more complex. We know that deploying and running Docker containers in live production requires the ability to view container performance data. But we need to be able to see that data right next to performance data from the rest of the infrastructure (i.e. the compute, network and storage components) or we can’t optimise for application scale out.
Suddenly, Docker ain’t quite so perfectly suited to some kind of Taylor Swift level of ubiquity then? Maybe yes, maybe no.
The big question is: does Docker isolation granularity and resource consolidation utilisation come at the expense of management tool-ability? “Yes it might do, in some deployment scenarios,” is probably the most sensible answer here.
PaaS proponents argue Docker’s initial promise of a brave new container world has become distended with additional complexity through controls that it needs to stay afloat. Further, anti-Dockerites say from this complexity comes security vulnerability.
But, equally, PaaS inherently presents itself as an abstracted simpler interface that effectively hides much of the intelligence beneath. So could this also sometimes be a bad thing? Nobody likes an over-engineered, modern BMW or Mercedes that’s impossible to fix when it breaks down due to all the embedded technology inside, right?
“In the case of PaaS you don’t have much control over many of the operational aspects associated with managing your application, for example the way it handles scaling, high availability, performance, monitoring, logging, updates. There is also a much stronger dependency on the platform provider in the choice of language and stack,” said Nati Shalom, CTO and founder of cloud middleware company GigaSpace.
So does Docker effectively replace PaaS or does Docker just drive the development of a new kind of PaaS with more container empathy and greater application agnosticism?
PaaS has been criticised for forcing an “opinionated architecture” down on the way cloud applications are packaged, deployed and managed. Surely we should just use Docker, but with an appropriate level of orchestration control too right? It’s not going to be that simple is it?
“Yes, it can be that simple,” argues Brent Smithurst, vice president of product at cross-platform development tools company ActiveState.
“Containers, including Docker, are an essential building block of PaaS. Also, PaaS offers additional benefits beyond application packaging and deployment, including service provisioning and binding, application monitoring and logging, automatic scaling, versioning and rollbacks, and provisioning across cloud availability zones," he added.
"A good PaaS goes far beyond what Docker alone offers. However, if a PaaS uses Docker, then it can take full advantage of the burgeoning Docker ecosystem," he said.
The confusion is starting to clear then: we should consider PaaS with Docker rather than PaaS instead of Docker.
Clive Longbottom, service director at analyst house Quocirca, says: “In a world where flexibility, performance and management will be all important, PaaS probably ties the user in to too much in the way of engineered constraints."
"However, containers will have to go through the pain virtualisation did: a container will have to be seen and managed in exactly the same way as the physical assets and base level operating system for it all to work. Some management tool and cloud orchestration vendors offer some of this now — the trick is to understand when there is enough of a solution in place to meet your real needs,” he added.
Could Docker eventually kill off PaaS?
It seems clear that it would be unfair and unwise to rank the usage of Docker over PaaS (or vice versa) per se; the two are closely related but not mutually exclusive. In very basic terms, if you use Docker, you should be using PaaS too.
We now need the maturity to realise that we have become more comfortable with the cloud computing model and therefore happier to tinker with its internal combustion engine.
We want to be able to take an infinite variety of software application types and architectural constructs to the cloud without having to just ship them out to some preconfigured notion of what the whole platform part of the stack should represent. Doing this simply results in some apps that don’t really work anyway.
Just as in cars as in cloud. Sometimes you need a surprisingly spacious family saloon and sometimes you want something for F1 — short on space but precision engineered, that’s streamlined for speed and takes different tiers according to the weather.
Obviously this analogy puts PaaS in the sensible car category for simpler application deployments and Docker in the Formula 1 category for more complex manoeuvres.
However, both require mechanics at some point — it’s just that we will call it orchestration controls. ®