Algorithms as Microservices | Hacker News Reader

Algorithms as Microservices

blog.algorithmia.com

93 pointsguifortaine38 comments

This is one of the dumbest things I've read in a long time. Algorithms are not where the real value is: that's why you can pull them off shelves at the bookstore. Algorithms are public knowledge, commodities to be written and rewritten at will by common, workaday developers.

Data is where the value is, because you're the only who has it. It's your competitive advantage. It's your secret stash that no one else can access. And if you're willing to ship it halfway around the world to a microservice provider based on flashy marketing, well, I've got a bridge to sell you before your VC money runs out.

Totally agree.

Facebook - good luck having a news feed algorithm with no actual stories and status updates

Google - good luck having a search algorithm with no actual search index

Amazon - good luck recommending products to others if you zero data on what others are recommending.

With all 3, you can at least create a minimum viable algorithm if you have the data.

Yes, Data is a competitive advantage. However, there ARE plenty of companies who do not know how to interpret that data. Especially companies who are NOT "tech" companies (Home Depot, Ace Hardware).

Hence, companies like Palantir and Pivotal that provide this service. To say that the ability to interpret data is ubiquitous is simply wrong.

This is exactly where SAP/IBM/Oracle are making crazy money. It is not a new untouched market, plenty of big and small players.

Look past the marketing. They aren't selling "we run algorithms on your data" they're selling "we run algorithms on all your data". There is still a large value proposition in managing large data and until something like GCE manages to completely remove the liability of bad developers using its platform, there will be room for these types of services IMO.

Disregarding the article, I sort of disagree with your comment too, maybe you are oversimplifying it too much. Or maybe because it's kind of a chicken and the egg kind of problem - which came first, the algorithm or the data.

Sure, generic sort algorithms come "off-the-shelf", but that is not true for all algorithms. Not all algorithms are public knowledge if they are patented, proprietary, or restricted in use/distribution.

You really need both - algorithms and data, right? And systems of execution for algorithms... and networks to interconnect the systems... and potentially humans to review the algorithm's output... and..... and... and..

I think the key is, algorithms can also represent embedded capabilities (information? knowledge? insight? not sure what to call it) generated from data. I mean, look at a RNN - the values/weights/etc. calculated inside the model are calculated from observations/training on the data. Once you disconnect the algorithm from the data itself, the algorithm alone now has embedded value without the data, potentially enormous.

Or, expert/rule-based systems which contain algorithms explicitly designed to embed human knowledge - those algorithms may not even be trained on actual data, they are simply a simplified expression of codified human knowledge.

If you go one step further and try to make some assumption that the way our brains work is by codifying inputs we receive into algorithmic models... and then using those algorithms to calculate based on new inputs from the environment... we can't keep all the data in our heads, but we can probably keep more algorithms than data.

Maybe I'm being too philosophical, but in my opinion, it's not just about the data.

Very interesting viewpoint. Any algorithm can be replaced by data and a lookup (e.g. Rainbow or multiplication tables.) On the opposite direction, the claim that any data can be replaced by an algorithm is indeed deeply philosophical (c.f. Materialism and free will)

If we want to go deeply philosophical, then fundamentally data and algorithms are the same thing anyway. Whether you interpret something as data or as code depends only on the angle you're approaching a problem at.

From the perspective of a Turing machine, they're the exact same thing. We just created abstractions to separate them. And from the perspective of physics, you've just got yourself yet another isomorphic transformation of the above mentioned Turing machine, so still the same.

Have you got an algorithm to produce my production database?

Philosophically you can reduce them to the same thing, but practically speaking you wouldn't really want to.

Control (i.e. 'moats') is where the real value is, always has been and always will been for all businesses.

E.g. with Google Search it is was perhaps the algo at first but now I'd say it is partly that and partly the high barrier to entry in obtaining all the data (although the data itself is freely available)

> Data is where the value is, because you're the only who has it.

For those of us who have no data, algorithms are the most valuable things.

    Algorithms are public knowledge, commodities to be written and rewritten at will by common, workaday developers.

I don't think the article is talking about sorting a linked list. Clever and non-trivial algorithms are being researched and discovered everyday both in academia and the industry (take ML as an example). Programs = Algorithms + Data (Structures). You can have a competitive advantage on either or both.

It's not that black and white. Sure, all the algorithms I use are available in published papers and often have open source implementations, but knowing exactly which combinations of algorithms to use on which datasets is a real value. As is knowing exactly how best to tweak those algorithms when the underlying dataset changes. Furthermore running a bunch of algorithms on some data is only the first and easiest step. Interpreting the results of that and then deciding what action, if any, to actually take is often the real challenge.

That being said I agree that having access to data that no one else has is a massive competitive advantage and with your skepticism about the concept being presented.

I went to the algorithmia site and looked through their algorithms.

Some aren't algorithms (or at least not of any algorithmic note) - for example https://algorithmia.com/algorithms/web/ShareCounts count social shares on facebook, pinterest, twitter, linkedin.

There are a lot of text analysis algorithms, but I find that problematic because in many cases the accuracy of the result on the data you pass it is going to depend on the training corpus. And you don't give it that.

When I look at any reasonably complicated algorithm the price is also quite a lot, if for example you want to use AutoTag https://algorithmia.com/algorithms/nlp/AutoTag to extract tags the price is $116 for 10,000 calls. If I am extracting tags to play around with something personally then I won't hit 10,000 calls quickly, but on the other hand it's my money and I would rather implement it myself so as to not spend the money. If I am extracting tags for a real application running in production 10,000 calls could go quite quickly. I would want to develop the in house capability pretty soon.

Maybe it would be useful to build MVPs that used the functionality and then just slot the algorithm in with a TODO replace this as soon as possible so as not to pay lots message. but my personal predilection would be to just build the functionality I need.

should also note that, in my experience, if you need one nlp algorithm you probably need more than one, and if you have developed the architecture/skills/code to use one probably using the others will decrease in the time required to implement, while with algorithmia you don't seem to get a discount on higher numbers of calls, or using related algorithms.

This really also goes for other things, like image analysis etc. etc.

Problem I see is that given following algorithm types, I see only one of them really fits this model:

1. common algorithms (sorting, graph algorithms, etc) - are commodity and there are tons of free libraries that have good enough implementations.

2. generic data dependent algorithms with many parameters (classification, NLP, neural networks, etc) - many many parameters to tune and they need to be tuned for each type of dataset. Unless you understand the algorithm, there is no real value in playing around with parameters. But if you understand algorithm then you probably want to implement or modify it to your specific needs (speed, complexity, etc). Only people who just want to play around with data might want to try off the shelve stuff to see how it performs but I don't see much market for serious users. I might be wrong here though.

3. Very specialized algorithms (3D surface reconstruction out of points, antenna analysis, etc) - this includes above algorithm types(common and generic data driven) that were specifically tuned to specific purpose. Some companies sell libraries that do that and those companies would probably benefit from Algorithmia.

If an algorithm is on another server, you have to pump the data over there, process it, and pump the results back. If the data size is large, transferring the data will take some time. Thus, the algorithm must require substantially more time than the data transfer. Render farms are the classic example.

There are some commercial desktop applications which do this. Autodesk Fusion is one. Some of the more compute-intensive tasks are sent to servers at Autodesk. If you don't like that, you can buy Autodesk Inventor, which is more expensive and requires a big desktop machine locally. (I've used a 24 CPU machine with Inventor. If you're doing finite element analysis or injection molding simulation or ray tracing rendering, it can be worth it.) Autodesk 123 Catch (3D model from photos) also works that way, which allows running it from a phone app.

Another possibility is that the algorithm is proprietary. This comes up with oil well data analysis. But the data is proprietary too, so everybody has to sign tough agreements.

This article mostly looks like a way to have micropaments (maybe not so micro) for software accessed from servers. If you're running on Linux, it's hard to license software to a server, what with virtual machines, cloud systems, and containers being started and stopped.

> Thus, the algorithm must require substantially more time than the data transfer. Render farms are the classic example.

Unless you work at Pixar, where render farms have been bandwidth-limited from day one.

If only there was a service that offered left padding. That would be huge.

Worry not, http://left-pad.io/ has you covered.

Too bad that they don't offer a hosted version of left-pad stack, our CEO worries about privacy. And I can't find SLA.

What do they mean by "microservice" in this context? In a microservice architecture there is a topology of services. Data & Requests move and fan out in this topology.

For algorithms "microservice" architecture is highly dubious. You may perform point-lookups (given X, categorize Y) but you may also perform a large-scale computation (given millions of X, categorize Y). In that case, moving _code_ around instead of data is much more valuable. Thus you get systems like SQL, Hadoop, Spark where code is shipped around instead of data.

https://en.wikipedia.org/wiki/Flow-based_programming

https://en.wikipedia.org/wiki/Dataflow

https://en.wikipedia.org/wiki/Dataflow_programming

https://en.wikipedia.org/wiki/Pipeline_(software)

And similar premises. This isn't a totally new idea. Come up with the minimum functionality for a process. Construct a method of communicating and plumbing these together. Spin them up on demand as needed. Many companies have done research on this concept.

This seems like marketing speak gone wild. First, 'data' and 'algorithms' really don't have much meaning here because if you already are producing 'data' then you have software which implements 'algorithms' to pull the data in the first. Adding functionality to whatever software you're using is more a matter of finding out what you need to know from your 'data' so why leave it in the hands of someone who doesn't know what you really need? It just seems like people assume that writing or utilizing software are easily outsourced/commodified when in practice you will always have an analyst or a programmer somewhere in your business. Just pay the for person and get over it, already.

Ethereum is sort of like "any-algorith-as-a-service"

This is the most insightful comment so far. Recently there was posted the pay-per-use API market 21.co, a "micropayments marketplace" [1]. We do have solutions for moving code to data, sure, like Hadoop and Joyent's Manta.

But consider we already outsource algorithms for bitcoin generation and transaction processing. A small amount of data that does require specialized processing. We're seeing it again with voice recognition and image processing APIs. This will continue as we have more data which will encourage more specialized hardware and create situations where algorithms as a service make sense, like Ethereum's smart contracts and 21.co's flat pricing.

In theory it could be very efficient for easy code problems to be solved, leaving man-hours for innovation. Which is what we have all worked towards in open-source. But the flattr/gittip model essentially fails in this regard. Can it be solved by the free market?

[1]: https://news.ycombinator.com/item?id=11270292

This would only makes sense when Internet connections reach 1Tb at low cost. The only "algorithms" this currently makes sense for are very complex ones such as voice recognition which require too much data and processing power to include in a phone's OS.

What do you guys think about Saas vs licensing containers? With Saas, the vendor takes care of operating the infrastructure. With containers the customer is responsible for the infrastructure. Which do you prefer and why?

Containers, because they can be made simple enough to not require having a specialized sysadmin, and they give you full control - it's your network, your data and your machines executing code. No third party can suddenly disappear, "update" to add "features", get acquihired, etc. I understand that the benefits of SaaS is that it is easy, but if you step back and look at it from an engineering (or security) point of view, the current obsession with it is simply insane.

initial impression: pretentious marketing

This is what all big fat BI/BW providers have been doing for decades now, isn't it?

Hey guys we haven't gone small enough. We really need to just write operations as micro services. Because really all we are doing is fitting puzzle pieces together and we don't need to worry about the gritty details of the operations themselves.

These should be nanoservices. Then breaking it down further we'll get to picoservices.

You're not hip enough anymore, the new good practice in the valley is femtoservices. Each statement running on its own server.

Run each machine code instruction in its own container.

NGaaS: NAND Gates as a Service

Someone will fall for these buzzwords.

Reply on news.ycombinator.com