The truth is that the world was never as simple as we would have liked to believe. While Java vs .NET made for nice copy, and a simple message, the reality was hardly so black and white. Even as the enterprises focused on the likes of J2EE, Perl, PHP and others were flowing like water around the “standard” platforms when they weren’t diverting to Spring, servicing workloads where development speed and low barriers to entry were at a premium. Much as Java and C# did to the platforms (C, C++, etc) that preceded them.
So fragmentation in the language and platform space is nothing new: different tools for different jobs has always been the workers’ mantra, if not the buyers supplying them. But it’s seems clear that the pace of this fragmentation is accelerating, with the impacts downstream significantly less clear.
Though it might not be entirely accurate to point to the rise of popular web development frameworks such as Django and Rails as the first signs of an impending diversity, they’ll do as examples. Like J2EE before them, they gave developers a new target to write to, one that was highly prescriptive. Rails, in particular, trumpeted the counterintuitive benefits of design constraints, and anyone that’s erected the Rails scaffolding in thirty seconds or so can appreciate the point. Less obvious, at least to the newly arrived, are the longer term implications of writing to a highly opinionated framework, namely that it can be tough to leave.
Given the monetary incentives alone behind being a platform, it’s not terribly surprising that everyone wants to be The Platform. The Platform, after all spells volume: the kind of volume that gets you in trouble with the DOJ and cash reserves of 50 billion for your trouble. Hence the efforts of folks like Cisco, who in an effort to expand the footprint and traction of some of their branch routers are…you guessed it, turning them into a platform that developers can target. One that while building on Linux technologies, is yet Cisco specific. Just as IBM’s SmartCube is Linux based, but IBM specific.
But it was Microsoft, of course, who was among the first to show the world the value of controlling the underlying platform; in their case the core pieces of the Windows operating system, from library to APIs. And if Azure is anything to judge by, Microsoft hasn’t forgotten any of those lessons, and will seek to actively seek to replicate them in the cloud (with their trademark focus on the tooling).
As will many of Azure’s cloud competitors, who have not missed the point any more than Microsoft has: abstract some development complexity and do a little of the heavy lifting, and in return you can ask to be The Platform. In many respects, the cloud is Visual Basic all over again, except with hardware and scaling crammed in as well. For all the success of the Infrastructure-as-a-Service (what I’ve called instance clouds) play that is Amazon, more of the emerging platforms are Platform-as-a-Service (what I’ve called fabric clouds) offerings than not.
The cloud then, more so even than dynamic languages, is poised to become a significant factor in the development platform and tooling space, which poses interesting questions for manufacturers and providers of same. If the market continues to fragment, and we have more language and platform options moving forward as seems probable, the developers will come at ever greater premiums. Which is why you see PaaS players happy to trade the unhappy taks of scaling for the opportunity to serve as the platform of choice for developers. Besides the learned helplessness argument – if developers never learn to scale, they’ll be forever dependent on the platform for that ability – there are the pains of migration.
If you can persuade developers and the businesses they work for to choose your platform, it may not be necessary to technically lock them in at all. What happens when you wake up one morning with a petabyte of data hosted in the cloud? How do you move that workload to a competing provider efficiently and without risking the data itself? The likely answer, unless you’re exceedingly unhappy with your cloud provider, is that you don’t. Like an Oracle database customer, you pay whatever they want simply because it’s less painful to.
It used to be that enterprises didn’t feel that they had many choices to make with the development target, but were overwhelmed with the foundational pieces. Workloads ran, officially, anyway, on Java or .NET, but questions abounded about hardware platforms, application server and tooling software, databases and more. Going forward, with language proliferation, framework popularity, and most particularly, cloud adoption, the decision of where and what to write to is likely to become significantly more complicated.
Which is why questions of lock-in are so important, and why the infighting, politics and discord in cloud interop discussions are so discouraging.
But more on that mess later.
