2016-04-25

Nanoservices

That link to Shoutcloud made me laugh and then made me think. It’s not the first time I see some micro-service publicly available. 2 years ago there was some talk about nano-services as an antipattern. But when you push the logic a little further, and at a very large scale, maybe it’s a projection of what the future will be.

Imagine our software totally destructured, calling functions taht are stored on the net, using some load balanced worldwide environment. We already do that with CDNs. Javascript next Modules proposals will go in that direction as well. But what is a method call in a program that we know today could become a service call of an external globally available function.

After all we always write the same code. How many time did you write a regexp for email pattern validation? The RFC 822 and 5322 are nasties, yeah. If we had no latency consideration, I would gladly delegate various pieces of code to a specialized service. But latency, is it really an issue now? We work more and more with async code, with queues and messages. What seems heretic for our current legacy standards would not seem that foolish in a slightly different context.

So technically, I suppose nanoservices are a possible future. I even think it’s a requirement for scaling any kind of agent-based architecture. Machine learning will be much better off by just registering maps to knowledge than knowledge itself. But I wonder about the economical side of things. The old capitalist market economy is already stretching its reach far beyond its original statement with immaterial economy. The totally destructured immaterial one will certainly propose an interesting challenge.

comments powered by Disqus