Microservices running on unikernels
That's the future of computing, my friend.
For example, that you were writing the weather prediction application, that needs to rapidly execute matrix operations on very large matrices. Your first thought may be, "Well, I find a good linear algebra library, and compile it into my program."
But there are several problems with this approach:
A better solution is for your weather application to rely on a microservice. Some specialists in computational linear algebra will build the service, run it on some highly optimized hardware, and allow people to subscribe to it. When you need a large matrix multiplication, you will passe this service a message across the Internet, and it will do your computation for you, and bill you based upon the size of the computation. Every time the specialists fix a bug, you immediately have their bug fix. Every time they upgrade their hardware, you have upgraded your hardware! Every time they speed up the calculation, you have instant access to the faster version.
And these microservices will increasingly run on unikernels: they will be built by taking a library of operating system components, and compiling in just the minimum set of modules that will enable the service to run. So, for example, the linear algebra microservice does not need a graphical user interface. It does not need mouse drivers, or printer drivers, for display drivers. It does not need code for handling user logins or starting terminal sessions. It does not need process or memory management: it is built to run a single application. It probably does not even need a filesystem: just a way to access disk cache for intermediate results.
For example, that you were writing the weather prediction application, that needs to rapidly execute matrix operations on very large matrices. Your first thought may be, "Well, I find a good linear algebra library, and compile it into my program."
But there are several problems with this approach:
- Every time the producers of the library find a bug and fix it, you will have to recompile your program and redeploy it.
- Every time the producers of the library add a feature you want or improve the performance of the features you use, you will have to recompile your program and redeploy it.
- If there are security holes in the linear algebra library, they are now in your program also.
- Your program is now larger by the size of the linear algebra library.
- If there is specialized hardware for running these sorts of computations, you will need to make sure your program runs on it or forego the speed improvements it would provide.
A better solution is for your weather application to rely on a microservice. Some specialists in computational linear algebra will build the service, run it on some highly optimized hardware, and allow people to subscribe to it. When you need a large matrix multiplication, you will passe this service a message across the Internet, and it will do your computation for you, and bill you based upon the size of the computation. Every time the specialists fix a bug, you immediately have their bug fix. Every time they upgrade their hardware, you have upgraded your hardware! Every time they speed up the calculation, you have instant access to the faster version.
And these microservices will increasingly run on unikernels: they will be built by taking a library of operating system components, and compiling in just the minimum set of modules that will enable the service to run. So, for example, the linear algebra microservice does not need a graphical user interface. It does not need mouse drivers, or printer drivers, for display drivers. It does not need code for handling user logins or starting terminal sessions. It does not need process or memory management: it is built to run a single application. It probably does not even need a filesystem: just a way to access disk cache for intermediate results.
Sounds like SOA.
ReplyDeleteBut if you were hitting the service a lot rather than 'you will passe this service a message across the Internet', wouldn't you want to download a local version ? They would need to find a way to track your usage for billing, and you'd need to download a new version every time something changed, but at least it would be fast.
No: they are the ones with the specialized hardware to run these calculations swiftly. You use something like this precisely in the case where the cost of the messages is trivial compared to the cost of the calculation. The best known matrix multiplication runs in about O(n^2.7). If we are multiplying 100,000×100,000 matrices , we wind up doing 31 trillion operations. That calculation will take hundreds or thousands of hours. The cost of the network messages involved is nothing compared to that calculation cost.
DeleteAlso, given the architecture I described, downloading the maker of service to your own machine would be impossible. Also, given the architecture I described, downloading the maker of service to your own machine would be impossible.
ok, now I understand - I had missed that this is for very long running calculations.
DeleteOops, I was dictating, and something weird came out in my reply at the end!
DeleteYes, clearly we do this when message cost is low compared to the work done. But these microservices exist already, and are becoming more popular by the day, so there are *lots* of cases like this!
"But these microservices exist already, and are becoming more popular by the day, so there are *lots* of cases like this!"
DeleteCan you give us some examples.
Netflix, eBay, Amazon, Twitter, PayPal, and Soundcloud should be pretty good examples of why this is not a "nightmare"!
DeleteAnd I wonder: Samson, is Google banned on your network? Because that's how I found these examples.
DeleteGood post at the Netflix tech blog on the topic:
ReplyDeletehttps://medium.com/netflix-techblog/towards-true-continuous-integration-distributed-repositories-and-dependencies-2a2e3108c051
There will be two-way traffic. In this scheme data moves to the logic. There will also be, and of course already is, a scheme where logic is moved to the data. That is how Hadoop works, mostly. Or of course cases where logic and data meet at rented by the operation hardware.
ReplyDelete"A better solution is for your weather application to rely on a microservice. Some specialists in computational the near algebra Will build the service, right on some highly optimized hardware, and allow people to subscribe to it. When you need a large matrix multiplication, you will passe this service a message across the Internet, and it will do your computation for you, and bill you based upon the size of the computation. Every time the specialist fix a bug, you immediately have their bug fix. Every time they upgrade their hardware, you have upgraded your hardware! Every time they speed up the calculation, you have instant access to the faster version."
ReplyDeleteWhat a nightmare.
Every single thing I described in that paragraph is a great plus. Why do you describe them as "a nightmare"?!
DeleteSamson's great grandfather fixed his own shoes, because sending them to a microservice vendor, sometimes known as a cobbler, was a nightmare.
Delete