Live data from Hacker News

Algorithms as a Service

mikesingleton.net

1–10 of 30 posts

Re: Algorithms as a Service

#5
A big problem for this would be the transfer of data to and from the API. Imagine an algo to analyze gigabytes or terabytes of data.

Also, protection of the data as it is being transfered, stored, and analyzed is an issue. This is both data integrity and also protection for privacy or confidentiality reasons.

Re: Algorithms as a Service

#6

A big problem for this would be the transfer of data to and from the API. Imagine an algo to analyze gigabytes or terabytes of data. Also, protection of the data as it is being transfered, stored, and analyzed is an issue. This is both data integrity and also protection for privacy or confidentiality reasons.

This is true. A possible solution is if the service was run in EC2, you could leverage the speed on the amazon network if the data was already stores in S3.

Re: Algorithms as a Service

#7
This is where I usually draw the line at the "everything is a service" world view. It is much better to provide this as a library than as a service, particularly algorithms that run across large data sets.

However, the exception I see to this is a service that applies the algorithm across a large dataset that is owned by the service. An example of this is geocoding, where you probably don't want to store the addresses of everyone in the world in your database, but it is easy to reach out to a range of providers to get latitude longitude for your address.

Re: Algorithms as a Service

#8

A big problem for this would be the transfer of data to and from the API. Imagine an algo to analyze gigabytes or terabytes of data. Also, protection of the data as it is being transfered, stored, and analyzed is an issue. This is both data integrity and also protection for privacy or confidentiality reasons.

This is true. A possible solution is if the service was run in EC2, you could leverage the speed on the amazon network if the data was already stores in S3.

I was thinking that as I was typing my comment. Another solution, which S3 uses, is to ship hard disks by courrier. I guess the real metric here is cost per GB transfered in a unit time, say $/GB-hr.

Re: Algorithms as a Service

#9
This is already being done lots of places. And if you take the literal definition of the word algorithm, then all web API services are algorithms as a service. So I don't like the name, but the general idea of the post is interesting.

Thinking along these lines, something that I would find more useful would be a web service that makes a well defined managed infrastructure available to me to run my own jobs or algorithms on. For example a service I can use to submit my own map/reduce style jobs to and have it run on a big cluster of systems managed by someone else; Or a service that allows me to submit jobs to run on specialized hardware, like a cluster of systems packed with NVIDIA CUDA cards. Providers of these services could also have a library of pre-canned jobs for common tasks like text indexing, link extraction, parsing W3C logs into stats, etc. With a library like that then you've got what this post is describing and more.

Re: Algorithms as a Service

#10

Earlier quoted context omitted.

This is true. A possible solution is if the service was run in EC2, you could leverage the speed on the amazon network if the data was already stores in S3.

I was thinking that as I was typing my comment. Another solution, which S3 uses, is to ship hard disks by courrier. I guess the real metric here is cost per GB transfered in a unit time, say $/GB-hr.

At what point does it become ridiculous to move the data, which may be measured in TB or PB, when the algorithm itself would be measured in KB or MB?
Post reply on HN