4 ms·

I'll admit, I clicked on this "Launch HN" mostly because the name sounded cool, but after reading the description... the name doesn't seem particularly relevant

I'll admit, I clicked on this "Launch HN" mostly because the name sounded cool, but after reading the description... the name doesn't seem particularly relevant to the business in any way, which can be fine, it's just interesting to note. I am a little confused about the product purpose and the definition of who your competition is in the market. I think new SaaS hosting providers are interesting, so please don't take any of this the wrong way, just hoping to give you some space to expand on your ideas more. > Here's an example. Imagine you make an application for investigating fraud in a large transaction database. Users want to interactively filter, aggregate, and visualize gigabytes of transactions as a graph. Instead of sending all of the data down to the browser and doing the work there, you would put your code in a container and upload it to our platform. Then, whenever a fraud analyst opens your application, you hit an API we provide to spin up a dedicated backend for that analyst. Your browser code then opens a WebSocket connection directly to that backend, which it uses to stream data as the analyst applies filters or zooms/pans the visualization. You say "put your code in a container", but... wouldn't you basically have to put all your gigabytes of data into a container? The bottleneck to the types of analytic applications you're describing seems unlikely to be the custom backend code, and far more likely to be whatever database is powering the application, which means that each interactive instance really needs to spin up a complete copy of the dataset to gain any performance benefit for these on-demand analytic workloads. I've worked with a number of high-scale applications, and scaling the backend API server has never been even remotely the main challenge... plus, having dedicated instances of the web server process wouldn't make anything faster than just having an appropriate number of instances, it would just make it more expensive. It's almost always a question of scaling the database -- not the API layer. For offline analytic workloads like you describe, you could potentially spin up fresh copies of the database for each user, and that would make things better, but the challenge of scaling (online) OLAP and OLTP comes from the shared-everything nature of the database itself. If you're intending to provide unique database instances to each user, then all the data needs to either be packaged up with the application, or stored somewhere that the application can retrieve it on startup and load the database, which could be a time-consuming process that creates painfully long cold starts. > Many high-end web apps give every user a dedicated connection to a server-side process. That is how they get the low latency that you need for ambitious products like full-fledged video editing tools and IDEs. > We have not solidified a price plan yet, but we’re aiming to provide an instance capable of running VS Code (as an example) for about 10 cents an hour, fractionally metered. Since you bring up the examples of running GUI desktop applications, I'm wondering if your competition isn't actually AWS WorkSpaces. Someone could build an image for a WorkSpace that includes everything the analyst needs, and then AWS will manage the lifecycle of that instance as the analyst connects and disconnects, billing entirely based on usage. That image could even include vast quantities of data pre-populated into a database, along with a web server that offers local dedicated processes to serve requests from the browser in the WorkSpace, if the company prefers to develop their application's GUI using the web as a platform. Obviously the challenge with WorkSpace is if you want to offer it to parties outside your company, but AWS does address this use case to some extent: https://aws.amazon.com/blogs/security/how-to-secure-your-amazon-workspaces-for-external-users/ https://aws.amazon.com/blogs/security/how-to-secure-your-ama... A company could definitely address the nuances and automation of offering WorkSpace to third parties, but such a business would likely be extremely vulnerable to AWS just improving WorkSpace to include those features out of the box.

paulgb 5y ago
> You say "put your code in a container", but... wouldn't you basically have to put all your gigabytes of data into a container? The bottleneck to the types of analytic applications you're describing seems unlikely to be the custom backend code, and far more likely to be whatever database is powering the application, which means that each interactive instance really needs to spin up a complete copy of the dataset to gain any performance benefit for these on-demand analytic workloads. You're right that it does depend a lot on the needs of a specific application. If a bunch of users are accessing the same dataset, and can constantly access the subset of data they need with low latency through a global index, and there isn't much need to do computation interactively at runtime, then a standard architecture is probably a better fit. Where this approach is useful is if every user needs access to a different subset of the data (e.g. if the underlying dataset is petabytes, and each user needs to interactively explore a different gigabytes-big subset of it). Or if there is a lot of derived compute on top of it, for example, a graph visualization that needs to be updated when the user changes the subset of data in focus. > I'm wondering if your competition isn't actually AWS WorkSpaces The general approach of "run and render elsewhere and stream the pixels back" is definitely our competition in the sense that it's something companies currently do. What we provide is a way of moving the client/server boundary to wherever makes sense for your app: if it makes sense to render server-side and stream pixels, you can do that (although we don't yet support UDP, which would be useful in this case); if it makes sense to do data aggregation server-side but render through WebGL, that's also an option.

paulgb 5y ago

> You say "put your code in a container", but... wouldn't you basically have to put all your gigabytes of data into a container? The bottleneck to the types of analytic applications you're describing seems unlikely to be the custom backend code, and far more likely to be whatever database is powering the application, which means that each interactive instance really needs to spin up a complete copy of the dataset to gain any performance benefit for these on-demand analytic workloads. You're right that it does depend a lot on the needs of a specific application. If a bunch of users are accessing the same dataset, and can constantly access the subset of data they need with low latency through a global index, and there isn't much need to do computation interactively at runtime, then a standard architecture is probably a better fit. Where this approach is useful is if every user needs access to a different subset of the data (e.g. if the underlying dataset is petabytes, and each user needs to interactively explore a different gigabytes-big subset of it). Or if there is a lot of derived compute on top of it, for example, a graph visualization that needs to be updated when the user changes the subset of data in focus. > I'm wondering if your competition isn't actually AWS WorkSpaces The general approach of "run and render elsewhere and stream the pixels back" is definitely our competition in the sense that it's something companies currently do. What we provide is a way of moving the client/server boundary to wherever makes sense for your app: if it makes sense to render server-side and stream pixels, you can do that (although we don't yet support UDP, which would be useful in this case); if it makes sense to do data aggregation server-side but render through WebGL, that's also an option.