Here are the cons
1. business lock-in: Having one's whole web business(code/website&data) be hosted by a small startup out of russia(ssor) will be a non-starter for most.
2. code lock-in: Having "code lock-in" for developers, meaning writing to a proprietary code-stack for an ssor will also be a non-starter.
3. scaleability: akshell does not currently provide a clear path to scaleability for any one app let alone the potential of hosting 1000's of apps. This very rapidly becomes a cloud-scaling issue that the ec2, gae's are attempting to solve and will be a non-starter for an ssor .
4. dynamic code sharing - use'ing other libraries within askell might reduce development time, but unless there is a static version of that library associated with each instance, with any change the possibility of breaking the web services makes this a non-starter and everyone would revert to a github like "static code sharing" model.
Here are the pros
1. A custom webhook pipe builder: Say I wanted to build a "dynamic form" get user input, save state (in a db) and run it through a series of dynamically created "webhooks" and process the final output. If akshell provided "an app development api" I could dynamically create an app, generate the code have it hosted and throw the url up for user input and have the user walk-thru various webhook/needed steps to process & generate a final response.
- this is not now possible w/ appengine or ec2
- propietary code/data lock-in is a non-issue since I am not "storing" as much as I am processing.
- leveraging "dynamic community code" would be a pro/ not a con in this case.
- a freemium model would be possible as i'd need free to wade in/ test etc and with load expect to pay a per use fee.
- see some of Jeff Lindsay's webhook related work i.e. webhooks, mailhooks, scriptlets.org etc at http://github.com/progrium for related work
2. A mashup test/use-bed: Web sites with apis could create "canned akshell apps" that not only allowed developers to use("foo-api") to test but also provided examples of use and each web-service could possibly subsidise the hosting / bandwith costs of using their api-apps so developers could just plug-n-play.
3. There are a few more use cases i can think of, you could shoot me an email if interested.