One of my favourite blog posts about PaaS is James Urquhart’s ‘Is your PaaS composable or contextual? (Hint: the answer matters)’. In the post, James distinguishes two different types of PaaS: Contextual and Composable. He additionally implied a third type of PaaS (though he categorized it as “Composable”):
“Perhaps most importantly, however, there are open source “build” tool chains being deployed directly to infrastructure services that exhibit a purely composable approach toward delivering and operating applications. Combining GitHub with Jenkins with Gradle with AWS CloudFormation and Autoscaling and so on gives a fully automated, flexible “platform” for application development and operations — everything you want from a PaaS. The catch, of course, is that you’ll need to assemble and maintain that tool chain over time (rather than letting the PaaS vendor do it for you).”
The Whitebox PaaS:
When we started VisualOps, at first we didn’t realize that we were building a new type of PaaS or rather a customizable PaaS, this was partly due to our DevOps background. As James pointed out, the value of a classic “Contextual” PaaS can be achieved by using the DevOps tool chain. There is more transparency and control implied by ‘customizable’ over ‘composable’ as all aspects of the environment are within your control. Each building block’s entire make-up is determined by you rather than merely arranged. The Blackbox PaaS removes this ability to define your own rules.
Though currently this category of tool chain is mostly homegrown, the key point here is that PaaS does not have to be a Blackbox. A Whitebox PaaS exposes 100% native interface of the underlying infrastructure, giving ultimate control and transparency. Combining Infrastructure-as-Code and Configuration Management capability as a quick and easy way to build, automate and orchestrate applications. Compare the Whitebox PaaS with the Contextual PaaS and the advantage is clearly that the Whitebox PaaS poses no pre-determined constraints on the application, and as such your apps will be general-purpose and lock-in free.
Benefits:
A key benefit of this approach is that the Whitebox PaaS is capable of both deploying and managing itself. With aWhitebox PaaS service it is possible that the customer can click to deploy a private clone, and no management effort is required since the clone is supervised by the “origin”. This removes the “operation immaturity” stated by John E Vincent in his blog:
“To be clear while I feel that most organizations aren’t ready for the operational challenges of maintaining a PaaS, the job is made harder by the PaaS software. In both cases, the operational maturity of the products themselves simply isn’t there.”
A further value is that in the WhiteboxPaaS is not th eapplication runtime. Instead,your code will run in standalone infrastructures (VMs), and PaaS only needs to help automate and orchestrate the application. Thus, even if the PaaS is down, your application will still run un-impacted. This entirely side-steps the issue of ” their downtime [being] your downtime”, as well as the security concerns raised by the multi-tenancy of the public PaaS.
Objections:
There may be some concerns regarding the learning curve necessary and intrinsic complexity of the WhiteboxPaaS as it requires your involvement with the application setup and the system architecture. It is true that it is by no means the easiest option. However if you are looking from a business minded perspective, having this knowledge will give you a great competitive advantage. If you don’t know how to do this you may lose the opportunity to build a better, faster and more robust application. Moreover, if people use PaaS to achieve “NoOps”, then it would appear that the real meaning of ‘undifferentiated heavy lifting’ is the day-to-day operations necessary to keep your application running, rather than the knowledge it was built upon. In this context using a WhiteboxPaaS absolves you of all heavy lifting, yet still leaves you with the opportunity and ability to make improvements, it is ‘customizable’.
This is not to say that PaaS must always be Whitebox. James put it well: “it’s not an either/or choice, much like stability and resiliency”. Different types of PaaS serve different markets and different purposes. From our experience, we have seen some customers begin using a Blackbox PaaS such as Heroku and grow rapidly with it until they reach a point where they want or even need something more flexible and powerful, they then choose to migrate to AWS+Whitebox PaaS such as VisualOps. This progression allows you to concentrate your time and efforts wholly into your business itself at the beginning, then upgrade to a more proficient and flexible platform as your business grows.
About the Author
Peng Zhao is the Founder and CEO of VisualOps. Previously, he initiated and led the IaaS projects for China Mobile as well as being both a manager and developer in a various companies, including Reuters and Platform Computing. He holds a MsC. from Univerisity College Dublin. His twitter handle is @gnepzhao
