"Github for live APIs" is a sensational idea! (BTW: Github adoption needed only git - already popular - and a browser.)
(1). I think it's significant that your motivating problems weren't to do with containers.
(2). I think "scale" is problematic, because although true and cool, only Amazon etc need it. But everyone loves simple, cheap and easy.
> We've moved to the cloud but our tools haven't.
(I know you meant tools in general, but) Although your StackHut tools are in the cloud, their local installation makes them seem local to users. And is a barrier to adoption. "Effortless to try" helps adoption.
Why not have webpage access, like github? If you have an API, wouldn't a (simple) webpage driver be easy? Start with a super-simple demo, with only entering the code (like the code for your python eg), automating the rest (derive IDL and fixed dependencies). Give it a hash URL so users can actually use it from their app. Don't require email/password til the user's hooked, and want more customization.
Of course, local dev is important for debugging and iterating (with familiar tools, not some textarea/ace editor). But if your containers spin up so quickly... is it actually crazy to develop and debug in the cloud? At least, for a demo?
BTW: did you see AWS Lambda's demo for code snippets:
http://squirrelbin.com/
(it's so slow because they cloud each save, load and run - instead of save+run in the background, and leave you in the editor. Actually, they use JS not py, so they could do the whole thing "locally" in the browser, not needing the cloud until you've finished iterating/debugging, to save. NB: you can't run their code snippets as a service, so they totally missed the cool opportunity "save to deploy!". Their article:
https://aws.amazon.com/blogs/compute/the-squirrelbin-archite... )
(3). If you do focus on JS, it can run in the browser... making it fast to iterate/debug, then "save to deploy".
---
For 10 years, I've thought components over multi-core (now "microservices") will be a revolution - so complete, that even entirely local software will use the architecture. This is because components are modular; and services are a way to distribute computing over multiple cores.
But the arguments I see for microservices are not compelling. Scale isn't needed by most people. Multiple languages are not a key issue for most (and solved by RDB, XML, middleware etc anyway). And it creates new problems.
Yet, I still feel it's revolutionary. And I think your approach (and AWS Lambda) may be the answer: it's not because it's clever and cool, but because it will be cheap. I think it will be "Cheap" for the same reasons the services in the cloud are cheap, but finer grained.
For devs, the finer grains enable components to be loaded only when needed, and only with the dependencies and RAM and infrastructure etc needed. Sort of, iOS's app thinning, or Go's tree shaking, but for resources, at the component level. Needn't be done meticulously to get real benefit - often as easy as "our business logic is simple, but the image processing part needs 8GB RAM".
Similarly, cloud vendors can sell more capacity if it is finer grained (because, geometrically, there are less gaps between the grains). They can therefore sell it cheaper.
It is simply more efficient for boths devs and vendors.
Is that how it looks from the inside, too? Is it significantly more efficient, and therefore cheaper?
Because cheaper, simpler, easier is the history of computing (and all technology).
PS: I'm taking a break before replying to the other one - glad you like "json by eg" schema.
[cont] On second thoughts, "scale" is important, because multi-core: (1). spinning up an instance per request is far slower than local, but the second, third, thousandth is the same speed. At some point, the cloud is faster, because it's multicore. (2). the threshold of "fast enough", which means we needn't actually beat local; (3). and the cloud is cheaper.
"Github for live APIs" is a sensational idea! (BTW: Github adoption needed only git - already popular - and a browser.)
(1). I think it's significant that your motivating problems weren't to do with containers.
(2). I think "scale" is problematic, because although true and cool, only Amazon etc need it. But everyone loves simple, cheap and easy.
> We've moved to the cloud but our tools haven't.
(I know you meant tools in general, but) Although your StackHut tools are in the cloud, their local installation makes them seem local to users. And is a barrier to adoption. "Effortless to try" helps adoption.
Why not have webpage access, like github? If you have an API, wouldn't a (simple) webpage driver be easy? Start with a super-simple demo, with only entering the code (like the code for your python eg), automating the rest (derive IDL and fixed dependencies). Give it a hash URL so users can actually use it from their app. Don't require email/password til the user's hooked, and want more customization.
Of course, local dev is important for debugging and iterating (with familiar tools, not some textarea/ace editor). But if your containers spin up so quickly... is it actually crazy to develop and debug in the cloud? At least, for a demo?
BTW: did you see AWS Lambda's demo for code snippets: http://squirrelbin.com/ (it's so slow because they cloud each save, load and run - instead of save+run in the background, and leave you in the editor. Actually, they use JS not py, so they could do the whole thing "locally" in the browser, not needing the cloud until you've finished iterating/debugging, to save. NB: you can't run their code snippets as a service, so they totally missed the cool opportunity "save to deploy!". Their article: https://aws.amazon.com/blogs/compute/the-squirrelbin-archite... )
(3). If you do focus on JS, it can run in the browser... making it fast to iterate/debug, then "save to deploy".
---
For 10 years, I've thought components over multi-core (now "microservices") will be a revolution - so complete, that even entirely local software will use the architecture. This is because components are modular; and services are a way to distribute computing over multiple cores.
But the arguments I see for microservices are not compelling. Scale isn't needed by most people. Multiple languages are not a key issue for most (and solved by RDB, XML, middleware etc anyway). And it creates new problems.
Yet, I still feel it's revolutionary. And I think your approach (and AWS Lambda) may be the answer: it's not because it's clever and cool, but because it will be cheap. I think it will be "Cheap" for the same reasons the services in the cloud are cheap, but finer grained.
For devs, the finer grains enable components to be loaded only when needed, and only with the dependencies and RAM and infrastructure etc needed. Sort of, iOS's app thinning, or Go's tree shaking, but for resources, at the component level. Needn't be done meticulously to get real benefit - often as easy as "our business logic is simple, but the image processing part needs 8GB RAM".
Similarly, cloud vendors can sell more capacity if it is finer grained (because, geometrically, there are less gaps between the grains). They can therefore sell it cheaper. It is simply more efficient for boths devs and vendors.
Is that how it looks from the inside, too? Is it significantly more efficient, and therefore cheaper?
Because cheaper, simpler, easier is the history of computing (and all technology).
PS: I'm taking a break before replying to the other one - glad you like "json by eg" schema.