Opinions are welcome on whether this kind of approach could help move forward from the microservice/monolith debate:
- Teams commit to individual repositories so that team membership, changeset review, and issue management are kept close to the relevant code, and checkout sizes are minimal
- Strong language support for inter-repository dependency management is introduced to enable effective rollback and rollforward of commits that affect other repositories
- The function call becomes the unit of deployment -- not a microservice, and not a monolith. This allows for low bandwidth deployments and for small amounts of highly-utilized code to migrate to the devices where they are needed for computation
- Function calls and return values are signed cryptographically so that inter-function calls have integrity, regardless whether within a single device or across the network
- Functions that perform I/O calls are tagged with the virtual storage and/or network interfaces that they require access to
- Kubernetes-like infrastructure manages the deployment, scaling, and resource allocation of functions to devices
This seems to me like it would provide the organizational benefits of microservices while reducing developer hand-wringing over where to define service boundaries. It just becomes a question of 'should this be a function?'.
Good tooling around binary-dependency-or-source-code retrieval could make it easy for developers to work on large applications built like this and inspect / debug / modify code as-needed without having to check out or download all the source code and binaries at once.
- Teams commit to individual repositories so that team membership, changeset review, and issue management are kept close to the relevant code, and checkout sizes are minimal
- Strong language support for inter-repository dependency management is introduced to enable effective rollback and rollforward of commits that affect other repositories
- The function call becomes the unit of deployment -- not a microservice, and not a monolith. This allows for low bandwidth deployments and for small amounts of highly-utilized code to migrate to the devices where they are needed for computation
- Function calls and return values are signed cryptographically so that inter-function calls have integrity, regardless whether within a single device or across the network
- Functions that perform I/O calls are tagged with the virtual storage and/or network interfaces that they require access to
- Kubernetes-like infrastructure manages the deployment, scaling, and resource allocation of functions to devices
This seems to me like it would provide the organizational benefits of microservices while reducing developer hand-wringing over where to define service boundaries. It just becomes a question of 'should this be a function?'.
Good tooling around binary-dependency-or-source-code retrieval could make it easy for developers to work on large applications built like this and inspect / debug / modify code as-needed without having to check out or download all the source code and binaries at once.