At MongoLab we’re obsessed with software tools to get stuff done. DBaaS and PaaS represent new tools in a developer’s toolbox. To borrow a 1997 Steve Jobs metaphor below, writing an app is like constructing a building. And a good building tool (in the then newly acquired NeXT case, OpenStep) “lets you start developing your app on the 20th floor [instead of the 7th].” Likewise a good PaaS lets you develop your online service by starting with a pre-assembled deployment, provisioning, and scaling infrastructure.
Reformatted from Macworld Expo Jan 1997 video frame at about 14:00 http://www.youtube.com/watch?v=QhhFQ-3w5tE
A PaaS also comes with a pre-hired, trained, and conditioned team to keep it updated and running. “Conditioned” means a team that will likely have resolved an issue prior to you running into it. It also means that operational maneuvers that are rare for any one user are practiced nearly daily across a large population. For example, we are constantly restoring databases, upgrading servers, finding helpful indexes, and have it down to a science.
Finally, in a developed PaaS, add-ons provide components that raise the base functionality even higher. We’re in several PaaS add-on marketplaces, and to end users add-ons represent a menu of capabilities from internet telephony to new databases to analytics. To add-on providers, PaaS represents a route to a market that is comfortable with as-a-Service offerings.
Off the rack or artisanal?
In the early days of UI application APIs, ignoring the API and writing directly to bare metal was a way to eke out every last bit of performance and control. That hack-around code was fragile, needing to be maintained across API revisions, and more likely to exhibit inter-application conflicts that made for user headaches. (PC Interrupt hell anyone?)
Will there always be performance and control advantages to building out your own server or rack? Yes, and if your business demands it for raw competitive or cash flow reasons (performance ~= money), then it makes sense. But for a growing fraction of businesses, focusing precious developer energy into infrastructure is less important than building a killer feature.
PaaS is a disruptive change: replacing existing processes, enabling new businesses, and needing market education. New tools are always challenging practitioners to learn and adapt. To an expert lathe operator, the language of CNC milling: 3D solid models and computerized tool paths can be unwieldy and foreign. But to an industrial designer versed in modern manufacturing, CNC milling becomes a new way to express oneself, maybe even for an aluminum chassis previously unattainable at scale. That designer can still create objects with chisel and wood, and he can refine manufactured models with hand files and drills.
At the end of the day, any new tool must prove its worth and find its place in the toolkit. As practitioners of software, we are always comparing the “known good” tools in our kit with the “new potentials”. PaaS and DBaaS are tools that should evaluate for their capabilities and understand how they fit into your toolbelt.
Join fellow PaaS and DBaaS providers Nodejitsu, Xeround, Cloudant, and us for a discussion on PaaS and DBaaS hosted by Joyent. Starts at August 22, 2012 at 11am US Pacific. Register here.
