3 ms·

Thanks so much. Yes, we've pivoted a few times, first starting out with trying to be the 'github for live API's, which is an idea we love but found that the ch

by mands 11y ago

Thanks so much. Yes, we've pivoted a few times, first starting out with trying to be the 'github for live API's, which is an idea we love but found that the chicken-and-egg situation was tricky to overcome, and that most users just wanted a way to deploy their code to the code to support a webservice. As such we pivoted to building a shared hosting service that let's users just write their code and deploy it. Regarding your 3 questions, my preliminary responses would be (bear in mind we probably would need to think about this further!), 1) We were super excited by the idea based on our own use cases - I found it a nightmare trying to build a distributed back-end to process video in the cloud for a previous startup. This got in the way of building my product but had to be done. Similarly, my co-founder ahead ran into the same issue when he needed to perform web-rendering on the server and just needed an easy way to wrap up this functionality. At this point we though perhaps we could use containers to wrap up the code but found the container ecosystem was focussed heavily on dev-ops and not services, so we built this. 2) Yes, totally agree - our messaging needs a lot of work, we've actually become a lot better in real life but unfortunately haven't updated the website to reflect this! The basic problem is that deploying your code to the cloud is hard. After writing your code locally, you have to do all kinds of orchestration to get your code into the cloud, run it at scale, handle faults, client integration, and more. We feel we can make this simpler. As for why you'd want to move your code to the cloud, hmm, that's a good question. Why the cloud? Don't worry about physical infrastructure., have capacity and capability to scale up compute resources dynamically, ignore hardware maintenance and amortise sys-ops costs with other users. Getting across why users want our code to get to the cloud, if they know what the cloud is, is tricky. Absolutely, becoming an easy way to get code into the cloud followed after this, as we realised just how hard it was. We've moved to the cloud but our tools haven't. 3) Yes, this is the hard bit. Lots of users have existing code, perhaps in the cloud already or locally deploy. They don't know or care about Docker / Kubernetes, etc - and shouldn't have to. We think Docker is a great building block to build services on top of, but we should be able to abstract it away and build on top of it. Eventually we'd hope we can get across our core message - deploy your code to the cloud as easy as running locally - without ever mentioning containers, docker, and more. Perhaps we can do that now, we just to update our message to get that across. For now we're thinking of targeting client-side JS developers as an initial niche and going deep with that while we figure out our tech and message. but yes, the core message is the same - a really simple way to write some code and get it hosted in the cloud as simply as possible (and yes, with a free tier also). It can, and should, be simpler.

hyperpallium 11y ago
Thanks for such a considered reply! "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/ 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-architecture-a-serverless-microservice-using-aws-lambda/ 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.

by mands 11y ago

hyperpallium 11y ago

Thanks for such a considered reply! "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/ 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-architecture-a-serverless-microservice-using-aws-lambda/ 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.