Image Credit: Bellperformance.com
If you feel that PaaS is a new-age devops/application management tool, like any management tool user or vendor, you’ll want maximum breadth of coverage. Nobody wants multiple monitoring, backup, deployment or configuration management solutions for each platform or application in their environment. Heterogeneous breadth coverage with the ever elusive “single pane of glass” is the end goal.
While at Microsoft, our top mission in the datacenter management team was “to make Windows the most manageable platform in the datacenter”. We felt we were positioned to do Windows management better than anyone else and given the sheer number of Windows Servers in the enterprise, we felt that we could build a valuable asset for the company and our customers. In effect, we wanted to be “best of breed” for Windows.
Ultimately however, we realized that we needed to add non-Windows support. Customers who were 90%+ Windows were hesitant to deploy our solution because they would need to purchase a separate tool for the other 10% of their environment. In effect, we were locked out of large Windows Server environments due to a lack of even basic heterogeneous coverage. We proceeded to add this expertise to our team and the capability to our solution. So…if you think that PaaS is mainly about taking the friction out of application lifecycle management, this example highlights a credible argument against “best of breed”.
If you think PaaS is the next generation cloud application server however, you probably have a different perspective.
It’s very hard to provide deep and meaningful value to the ‘guts’ of an application in a generic fashion the way you can with a management tool. Management tools typically have a generic framework for eventing, pushing bits around etc. while application specific aspects are embedded in an agent which interfaces with a specific application API. This is how most backup and monitoring products work even today.
Application severs on the other hand are typically constructed with the single minded purpose of making it easier to write and run sophisticated applications with the side-effect of simplifying application management in the process. Think about it: People didn’t balk at BEA WebLogic or WebSphere because they didn’t run .NET apps.
To counter that management tool example I outlined earlier, Microsoft SQL Server shows how a best of breed application platform can be massively successful. SQL Server has been a fantastic growth business for Microsoft and is wildly popular with Windows developers. If you want to be a “database management, deployment and scaling tool”, you’d need to support lots of different databases. If you want to be a database platform, having a laser-focus on your use cases, customers and deep value proposition becomes more important to success.
In a more recent and well publicized example, Heroku modified how it handles application routing and load balancing causing at least one customer some grief:
“So the only solution is for Heroku to return to routing requests intelligently. They claim that this is hard for them to scale, and that it complicates things for more “modern” concurrent apps like those built with Node.js and Tornado. But Rails is and always has been Heroku’s bread and butter, and Rails isn’t multi-threaded.”
I’m not trying to knock Heroku. They have plenty of great customers who love the service. I simply want to highlight the challenge of trying to optimize across too many dimensions.
It’s easy for folks on either side of the argument to talk past one another one debating polyglot vs “best of breed” (myself included) but this is largely a function of your outlook on PaaS and its role in modern cloud application development.
