4 ms·
I don't think OP necessarily implied that the compute cycles had to be free.
by anthuswilliams 6y ago
I don't think OP necessarily implied that the compute cycles had to be free.
- nawgz 6y agoRight, so then he's proposing that this streaming service is enabling derivative services by not only managing the API for the streaming service but also by running their own public cloud which issues micro-charges for compute cycles. That seems even more pie-in-the-sky.
- anthuswilliams 6y agoIt's definitely pie-in-the-sky. I wouldn't argue otherwise. But I do think this is a problem our industry will have to solve eventually. The volume of data we have to move between servers in order to ask questions is exploding. We move petabytes of image data between filesystems in order to train machine learning models. If the problems in this thread can be solved (admittedly a big if), moving the code to the data would be fundamentally better.
- miki123211 6y agoMind you, most of this should be handled by some kind of runtime. Any complex enough web service runs HTTP Servers, databases, sometimes messaging queues, caches or even things like Kubernetes. There's no reason why it couldn't be running yet another program to manage all this. Such a thing could become the de-facto API, if Rest or GraphQL were needed, they could even be implemented on top of it.
- nawgz 6y ago>There's no reason why it couldn't be running yet another program to manage all this Yes there is - that program would need to be extremely hardened (even against DDOS style attacks - run a ton of memory-consuming cycle-hogs on a service's platform), integrated with tracking & billing, and open-source (or itself charging). I just don't see the incentive for someone building this, and then I doubly don't see the incentive for a corp running this. Why take on this huge extra burden of infra to help derivative services? It's not going to make you money.