The first time I heard someone differentiate between East Coast and West Coast Platform as a Service (PaaS), something clicked. Over the past year or so, I’ve had more than one “polite discussion” about what organizations should be looking for in a platform. It usually seems like we are talking past each other rather than to each other.
James Urquhart of EnStratus, Master of Ceremonies at DeployCon, was the first thought leader I’ve heard suggest the theory that distinct cultural viewpoints might be the cause of so much controversy in the PaaS ecosystem. While external manifestations of different approaches were argued in great detail that day, the underlying divide wasn’t.
On the heels of that talk, Rodrigo Flores of Cisco explored a similar divide between “Silicon Valley” PaaS and “Enterprise” PaaS. To Flores, Silicon Valley PaaS consists of a “black-box” application hosting platform. Enterprise PaaS, he theorizes, is more a managed set of composable application stack components that consumers can select to assemble whatever application hosting stack needed.
I definitely appreciate the attempt to identify two different approaches to PaaS, I still suspect that this dichotomy misses the mark slightly.The biggest issue with Flores’ split is that his Enterprise PaaS, while being valuable in many circumstances, doesn’t provide the core values to look for in a platform as a service.
The two biggest requirements – which is the essential essence of a PaaS – are to treat the application as the unit of abstraction, and to hide the underlying infrastructure from the consumer.
Making the application THE first-class citizen acknowledges that the business value delivered by the application is the true goal of IT, and puts the developer in control of ensuring that value is realized.
The second requirement follows from the first. If all consumer interaction with the platform occurs within the scope of the application, then there really is no need to understand what’s beneath the application. The conversation is raised to capabilities and capacity, rather than servers and setup.
This is why you’ll see the same set of basic functionality in just about every platform as a service you look at. Nearly all of them provide developers self-service application management and deployment and the ability to leverage value-adding services offered by the platform or by third parties. None of them require the developer to access the underlying virtual machine or operating system to perform her task. And most offer some level of health monitoring and application resiliency simply by running on the platform.
Once these basic needs are met, you start to see the West/East divide form; the most apparent manifestation being public PaaS versus private PaaS.
The West Coast mindset (to use Urquhart’s term and expand out of just Silicon Valley to Seattle and Portland) predicts a much more rapid transition to a fully public cloud where IT operations are essentially outsourced to cloud providers.
The East Coast mentality recognizes there are some use cases where running in the public cloud makes sense, but is hesitant to give up the control of their IT; whether for regulatory/security concerns (be they real or imagined), or because of large existing investments in infrastructure and staff, or due to large amounts of business critical data.
I’m not going to explore the underlying psychology behind the split beyond suggesting it has something to do with where technology supports the business versus where technology IS the business.
If your goal in life as a PaaS vendor is to become a service provider and take over IT operations for companies, gaining economies of scale is probably the most important thing you can do. And to get economies of scales, you need to draw as many developers as you possibly can. Make the barriers of entry low, and offer support for a wide variety of languages and frameworks. But, because you need to support so many different flavors of technology to gain the mass audience you need, you can only offer fairly limited support for each of them. It might not be truly the lowest common denominator, but it’s not far off. Trying to do much more will likely lead to product fragmentation.
That means that most, if not all, the West Coast PaaS flavors, provide the definitional capabilities of self-service deployment and location transparency, but can’t go much deeper than that. And there can be lots of value in that, especially for start ups and individual developers. But there’s also a limit to that value.
East Coast PaaS, on the other hand, tries to support the entire organization – of which developers are the most important piece. It’s often delivered in a private or hybrid form factor, and relies on the existing organizational capabilities of the IT staff to manage and maintain a robust delivery infrastructure. There’s no need to build up economies of scale just for the PaaS – because they’re already built into the traditional enterprise offerings.
What East Coast PaaS offers is a renewed focus on developers, giving the same self-service application management and location transparency that West Coast PaaS provides. But, almost paradoxically, because East Coast PaaS providers recognize and support the IT operations for enterprises, they can provide deeper value to the developer. Enterprises generally have standardized a few stacks (Java and .NET for the most part), which means the PaaS providers can remain intensely focused on those technologies and leverage their advanced capabilities to enhance the developer experience. For example, by augmenting capabilities in the .NET stack, Apprenda can dynamically transform an application into a SaaS application at deployment time, saving upwards of a year of effort. It’s unlikely you’ll ever see those sorts of capabilities evolve in a polyglot world.
I expect I’ll hear objections here about “we live in a polyglot world,” and “you can’t just limit yourself to C# and Java anymore.” But, to be honest, those are West Coast objections. Enterprises have built up major competencies around their core languages and stacks, and there are a few reasons that’s likely not going to change anytime soon.
- First, being a polyglot developer is difficult. There’s really no way around it. Individuals are definitely capable of understanding when to use each technology and building different applications or components in different languages. Translating that ability to a department of developers of differing skill sets and interest levels increases the difficulty exponentially.
- Second, development groups in most large enterprises are extremely fluid. Programmers come and go, teams are formed and torn down on a project by project basis. It’s unlikely that the developer who originally wrote the code is the one who’s going to maintain it. Using more exotic technologies, even those that may have made it easier to develop initially, may actually increase the long-term cost of maintenance.
- Another objection I’m sure I’ll hear is “I don’t want to have to operate two distinct platforms.” And while I totally understand the theoretical appeal of that stance, I think the reality is somewhat different. In many enterprises there’s already a hard divide between the Linux stack and the Microsoft stack. That separation persists across the entire stack. Java applications run on JEE servers (or Tomcat), .NET applications on IIS. Java applications are developed in Eclipse or IntelliJ, .NET applications in Visual Studio. Companies have chosen these tools because they are the best ones for the job and provide the most value to the people consuming them. Why would the PaaS world be any different?
While the West Coast conception of PaaS is an appealing vision, (and may well be the answer for many smaller companies and start ups) it doesn’t really mesh with today’s enterprise reality. Companies are looking to take advantage of their in-house infrastructure, processes and skill sets, but still enhance the experience of their developers.
Even if moving whole hog into the brave new world of public PaaS were the right answer, it’s infeasible to expect such a transition to happen rapidly. Any company that chooses to wait for that is forgoing value that’s available to them today. And if they’re committed to offering that value internally, they’ll likely choose the approach that’s purpose-built to their needs, rather than one that tries to be overly inclusive and relatively shallow.