14. Microservices Runtime
- Status: proposed
- Deciders: @butonic, @micbar, @dragotin, @mstingl @pmaier1, @fschade
- Date: 2022-01-21
In an environment where shipping a single binary makes it easier for the end user to use oCIS, embedding a whole family of microservices within a package and running it leveraging the use of the Go language has plenty of value. In such environment, a runtime is necessary to orchestrate the services that run within it. Other solutions are hot right now, such as Kubernetes, but for a single deployment this entails orbital measures.
- Start oCIS microservices with a single command (
ocis server). - Clear separation of concerns between services.
- Control the lifecycle of the running services.
- Services can be distributed across multiple machines and still be controllable somehow.
1.The use of frameworks such as:
- asim/go-micro
- go-kit/kit
- Build and synchronize all services in-house.
- A hybrid solution between framework and in-house.
Pros
- Large community behind
- The creator is a maintainer of Go, so the code quality is quite high.
Cons
- Too verbose. Ultimately too slow to make progress.
- Implementing a service would require defining interfaces and a lot of boilerplate.
Pros
- Implementation based in swappable interfaces.
- Multiple implementations, either in-memory or through external services
- Production ready
- Good compromise between high and low level code.
Number 3: A hybrid solution between framework and in-house.
First of, every ocis service IS a go-micro service, and because go-micro makes use of urfave/cli, a service can be conveniently wrapped inside a subcommand. Writing a supervisor is then a choice. We do use a supervisor to ensure long-running processes and embrace the “let it crash” mentality. The piece we use for this end is called Suture.
The code regarding the runtime can be found pretty isolated here. The runtime itself runs as a service. This is done so messages can be sent to it using the oCIS single binary to control the lifecycle of its services.