Given that Alexa skills are web services, and will require ongoing support and cost in order to function, what options is Amazon going to give us in the App Store with regards to pricing? At this point, subscription models are the only ones that would seem to make sense. A fixed upfront price that covers all future support costs would be very difficult to get right.
Well, you first free 100,000 hits on Lambda will get you a long way. I'm thinking a mobile model. The potential for up-front purchase price, and then in-app purchasing. That's what I'm basing the serious stuff I'm doing on. You could do a sort of in-app advertizing. But since there's no links on cards it's hard to drive revenue like that. If I was going that direction I'd do something like survey questions. Slowly start to build up user demographics, then offer them coupons on the cards. I rather suspect, in reality, that (not unlike mobile) Alexa skills are going to be loss-leaders to get people to buy the associated hardware you are attaching and controlling on your internet of things.
It is actually the first 1 million requests per month that you get free, along with 400,000 GB-seconds of compute time:
http://aws.amazon.com/lambda/pricing/ This should be enough for the vast majority of apps, and each million requests beyond that is only $0.20, or $0.0000002 per request. As to actual monetization of your app, I don't have any additional information to share at this time. Thanks, Nick
AWS Lambda should have very good uptime numbers. From their FAQ (
http://aws.amazon.com/lambda/faqs/): Q: How available are AWS Lambda functions? AWS Lambda is designed to use replication and redundancy to provide high availability for both the service itself and for the Lambda functions it operates. There are no maintenance windows or scheduled downtimes for either. -Nick
By "it" I mean my app, not Lambda. When you're building against a native device API, and the software is running on the device, the user has control if something goes wrong. When you're running in the cloud, all the users are dependent on one system. It it fails, every user is affected. Put another way, when a native app crashes, that one user can just restart it and move on. When a web application crashes, someone has to be there to restart it, or else ALL of the users are prevented from accessing the app. Who's going to pay for the long term costs to staff that support? Or do I just have to write perfect software that never breaks?
I'm not trying to be negative here (although re-reading my posts, I'm sure it seems that way). I'm just trying to point out that a fixed-price-only model for the app store is going to limit the kind of applications built with Alexa. Greatly limit, in my humble opinion, because they are fundamentally different than the kinds of native apps that usually use those pricing models.
Lambda is a great option, but there is no way to gather data from the user. If I host my own web server, I can have the user login to set their zip code, preferences, etc. There's no way to do that with lambda, is there? That REALLY limits its potential. Is it against the terms to insert advertisements into cards? I imagine that would be one way to earn revenue, but it would be really annoying. Every time you use my app, I spam your echo app with advertising? That would suck. If it's not against the terms now, I assume it will be.
Using Lambda does not preclude having your own companion website. You just need to get data back and forth to it via Lambda. The only downside I've seen is that my Lambda skills seem to have more latency than my AWS skills. I don't know if that's a "you get what you pay for". I haven't done a formal benchmark, but the blue lights sure do seem to flash longer for a Lambda skill.
Agreed on the latency. I also noticed that I can't spawn an async request and reply immediately with a response back to Alexa. Once I send a response, the whole function stops executing and kills the spawned async request. For example, I want to call a remote web service that takes 5 seconds to start. I can't give an immediate response like "Okay, I'm checking". Instead, I have to wait until the async request finishes, then say something back. I assume that's because the entire lambda environment goes away once the request is completed. That's a bummer.