ISVs and the Cloud
If you’ve been following JNBridge in the news, it’s no secret that we’ve been preparing a cloud offering. Over the last few months, we’ve learned a lot about what’s easy and not so easy to do on the various cloud platforms. But one thing that stands out is that cloud providers don’t seem to have devoted too much thought to how independent software vendors (ISVs) play in the cloud.
If you ask most people how software vendors can move into the cloud, they will say that the vendor should take their traditional products, put them in the cloud, and offer them as services. And that’s often fine. But what about software vendors like JNBridge who create components that other developers incorporate in their programs? In most cases, offering the component as a service doesn’t make sense.
The main challenge to running components like JNBridgePro in cloud-based programs has to do with prosaic but essential issues like licensing and billing. Windows Azure has absolutely no provision for third-party licensing (determining whether a user is entitled to use the product) and billing (charging for the use of the product). I would imagine that Microsoft feels that this should be the purview of some other third-party vendor, but I also imagine that potential vendors in this space are reluctant to invest in offerings until the demand materializes. It’s a chicken-and-egg problem. If Microsoft is serious about their software partners producing for Azure (and not just end-user customers creating custom applications), they will have to jump-start the market themselves, by offering their own billing mechanism. Since they are already billing Azure users, this shouldn’t be a stretch.
Unlike Microsoft, Amazon does have a licensing and billing service, called DevPay, that allows third-party developers running on Amazon’s EC2 (Elastic Compute Cloud) service to determine whether a user is authorized to run their products, and to charge for that use in a variety of ways. This service almost has it right, but it not quite there. It seems to be centered around Amazon’s S3 (Simple Storage Service), but will not run with their more modern EC2 images that are backed by EBS (Elastic Block Storage), which is the mechanism that most current EC2 users employ. In addition, the DevPay documents do not seem to have been updated in several years, and many questions on the DevPay support forum have gone unanswered, which leads to questions about Amazon’s commitment to this service.
Don’t worry, we’ve gotten around this problem, and it’s not preventing us from coming out with our cloud-based offering. But it surprises me that this new frontier of the cloud does not seem to have been designed to accommodate software vendors who want their products to work in the cloud. One would think that barriers to entry wouldn’t be there, and that the cloud providers would do all they could to encourage software vendors to help settle this new frontier, but they haven’t. I’m particularly surprised that Microsoft, which, in almost all other areas goes out of its way to cultivate a thriving partner ecosystem, has not done that with Azure, and doesn’t seem to have thought through the issues that would encourage such an ecosystem. And without that robust partner community, cloud adoption will be that much slower for everyone.