I just stumbled on my debrief of the OpenStack Summit 2016 in Austin, Texas and thought that my request for Nomadic Code was spot on. Some movement has happened to enable Nomadic Code, like with docker, serverless functions, and WebAssembly. In some Technical Due Diligences that I have led in the meanwhile, I can see that some people don’t want to burden themselves with all the cloud plumbing. The first PaaS offerings in 201x failed due to adoption problems rather than for technical reasons. After the slow IaaS adoption we see now a 2nd wave of PaaS offerings or even higher level functional domain offerings that point toward composable architecture. Pulling back my definition, which is by no means complete (happy if you want to chip in here), I would see the following with NomadicCode and have added points 8ff:
- Context: this would be the context of the code to fulfil its function with a clear description and purpose to understand when it can be applied and when not. This context is for the potential user of that function to be able to make a decision whether the component fits the use case.
- The artefacts in its package: modules to define composition within the package. This is important to enable further extensibility on the code level.
- Dependencies: what other software library or service dependencies are there.
- Test code of different categories: tests and how to run them to check validity. There should be the ability to add new test cases by the user to ask for more coverage also of new use cases.
- Resource demand: memory, CPU, network bandwidth demand for a defined workload of the service
- SLAs: what can you expect from the service. Where can you get a higher service level for the service?
- Costs: clear price for different service levels
- Version: Version description
- Licence
- Update cycle: version update service and also roadmap outlook
- Author
- Sponsoring: ability to donate to the service maintenance / development
