Amazon Raises the Cloud Platform Bar Again With DevPay

Wow, what an exciting time to be watching the Amazon Cloud Platform evolve. We’re just beginning to think through the recent SimpleDB announcement when Amazon launches DevPay. Lucid Era CEO Ken Rudin says land grabs are all about a race to the top of the mountain to plant your flag there first. It seems like Amazon has hired a helicopter in the quest to get there first. Google, Yahoo, and others are barely talking about their cloud platforms and here is Amazon with new developments piling up on each other. And unlike some of the developments announced by companies like Google, this stuff is ready to go. They’re not just talking about it.

What’s DevPay all about, anyway? Simply put, Amazon are providing a service to automate your billing. If you use their web services to offer a service of your own, it gives you the ability to let Amazon deal with billing for you. It’s based off the pricing model for the rest of the Amazon Web Services like EC2 and S3, but you can use any combination of one-time charges, recurring monthly charges, and metered Amazon Web Service usage. You have total flexibility to price your applications either higher or lower than your AWS usage. In addition, they’re promising to put everything they know about how to do e-commerce (and who knows more than Amazon?) behind making the user experience great for your customers and you.

It’s not a tremendous big step forward, but it’s useful. It’s another brick in the wall. There are companies out there providing SaaS infrastructure for whom billing is a big piece of their offering, so obviously it is a problem that people care about having solved. What are the pros and cons of this particular approach?

Let’s start with the pros. If you are going to use Amazon Web Services anyway, DevPay makes the process dead simple for you to get paid for your service. It’s ideal for microISV’s as a way to monetize their creations. The potential is there for interesting revenue that’s tied to usage in the classic SaaS way.

What about the cons? Here there are many, depending on what sort of business you are in and how you want to be percieved by customers. I break it down into two major concerns: flexibility and branding. Let’s start with branding, which I think is the more important concern. It’s not clear to me from the announcement how you would go about disassociating your offering from Amazon so that it becomes your stand alone brand. You and your customers are going to have to acknowledge and accept that the offering you provide is part of the Amazon collective. Resistance is futile. This is the moral equivalent of not being able to accept a credit card directly, and instead having to refer customers to PayPal. It works, but it detracts a from your “big time” image. If having a big time stand-alone image is important for you, DevPay is a non-starter at this stage. It’s not clear to me that Amazon would have to keep it that way for all time, but perhaps they need to protect their own image as well, and would insist on it.

Second major problem is flexibility. Yes, Amazon says you can “use any combination of one-time charges, recurring monthly charges, and metered Amazon Web Service usage”. That sounds flexible, but it casts your business in light of what resources it consumes on Amazon. Suppose you want a completely different metric? Perhaps you have another expense that is not well correlated with Amazon of some kind that has to be built in, for example. Perhaps you need to do something completely arbitrary. It doesn’t look to me like Amazon can facilitate that at the present.

Both of these limitations are things Amazon could choose to clean up. So far, the impression one gets is that Amazon is just putting a pretty face on the considerable internal resources they’ve developed for their primary business and making them available. What will be interesting is to see what happens when (and if) Amazon is prepared to add value in ways that never mattered to their core business. Meanwhile, they’re doing a great job stealing a march on potential competition. As a SaaS business, they should be quite sticky. Anyone that writes for their platform will have a fair amount of work to back out and try another platform. DevPay is another example. It will create network lock-in by tying your customer’s business relationship in terms of billing and payment to Amazon, and in turn tying that to your use of Amazon Web Services. For example, that same lack of flexibility might prevent you from migrating your S3 or EC2 usages to, say, Google. There doesn’t look to be a way for you to build the Google costs into your billing in a flexible way.

We’ll see the next 5 to 10 years be a rich period of innovation and transition to Cloud Computing Platforms. Just as many of the original PC OS platforms disappeared (CP/M anyone?) after an initial flurry of activity, and others have changed radically in importance (it no longers matters whether you run PC or Mac does it?), so too will there be dramatic changes here. The beneficiaries will be users as well as the platform vendors, but it’s going to take nimbleness and prescient thinking to place all your bets exactly right. The good news is the cost of making a mistake is far less than it had been in the era of building your own datacenters!

5 Responses to “Amazon Raises the Cloud Platform Bar Again With DevPay”

Excellent post Bob – I’ll point it out to the microISVs that read my blog. Other than PayPal (which has several significant limitations), there are very few good choices for microISVs wanting to do Saas.

Also, I really have to say that jumping through wordpress.com’s series of hoops to comment here was a major pain in the butt. I’d suggest making it easier – if you can.

Clear, not sure what hoops WordPress presented, you’re the first one to mention a problem, but I will be on the lookout.

I read with interest that PayPal subscription use has actually declined in 2007. It may be an indication that problems they’ve had are not acceptible for folks who have to try to run a business with billing.

makeit1said

For a brief time in the mid-90s, there was an initiative between Lotus, Novell, and AT&T to try to create a similar cloud for connected business apps. AT&T was to provide the connectivity through worldwide 1-800-CallAtt dialup, Novell was to provide an alternative to TCP/IP called Routable SPX, and Lotus would be the platform by contributing Notes. ISVs and businesses would develop Notes apps that anyone else on this “Business Internetwork” could use. I was briefly the marketing guy for this, but that job ended when I argued too strongly that any payment based on connect time was foolish and bound to fail. The bosses insisted that pricing mechanisms didn’t matter, and I was relieved of this role.

My point is that figuring out pricing mechanisms, (i.e.’where to hang the price tag’), is going to be critical to the success of this Amazon initiative, and based only on your description, it would appear to be an unresolved issue. We need to pay special attention to this…

Pricing and business model are always interesting unknowns. We’ve taken a lot of new soundings with the advent of SaaS and now Platforms as a Service, but we’re far from understanding the full dynamics. With that said, I have been amazed at the amount of traffic around this article. Clearly there is a lot of attention focused on Amazon’s Web Services.