From 68fdbbabf130f8fcc15964006cd18f148dd841b6 Mon Sep 17 00:00:00 2001 From: Alex Unger Date: Wed, 26 Jan 2022 13:41:31 +0100 Subject: [PATCH 1/3] runtime adr --- docs/ocis/adr/0014-microservices-runtime.md | 58 +++++++++++++++++++++ 1 file changed, 58 insertions(+) create mode 100644 docs/ocis/adr/0014-microservices-runtime.md diff --git a/docs/ocis/adr/0014-microservices-runtime.md b/docs/ocis/adr/0014-microservices-runtime.md new file mode 100644 index 0000000000..11dce88beb --- /dev/null +++ b/docs/ocis/adr/0014-microservices-runtime.md @@ -0,0 +1,58 @@ +--- +title: "14. Microservices Runtime" +weight: 14 +date: 2022-01-21T12:56:53+01:00 +geekdocRepo: https://github.com/owncloud/ocis +geekdocEditPath: edit/master/docs/ocis/adr +geekdocFilePath: 0014-microservices-runtime.md +--- + +* Status: proposed +* Deciders: @butonic, @micbar, @dragotin, @mstingl, @pmaier1, @fschade +* Date: 2022-01-21 + +## Context and Problem Statement + +In an environment where shipping a single binary beats the deployment wars, framing a whole family of microservices within a package and running it using Go language mechanisms has plenty of value. In such environment, a runtime is necessary to orchestrate the services that run within it. + +## Decision Drivers + +- Start oCIS microservices with a single command (`ocis server`) +- Clear separation of concerns + +## Considered Options + +1.The use of frameworks such as: + - asim/go-micro + - go-kit/kit +2. Build and synchronize all services in-house. +3. A hybrid solution between framework and in-house. + +## Options + +### go-kit/kit + +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. + +### asim/go-micro + +Pros +- Implementation based in swappable interfaces. +- Multiple implementations, either in-memory or through external services +- Production ready + +## Decision Outcome + +Number 3: A hybrid solution between framework and in-house. + +### Design + +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](https://github.com/thejerf/suture). + +The code regarding the runtime can be found pretty isolated [here](https://github.com/owncloud/ocis/blob/d6adb7bee83b58aa3524951ed55872a5f3105568/ocis/pkg/runtime/service/service.go). 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. From c25ab1db86ba06bfb2ea91574162b9891370e45e Mon Sep 17 00:00:00 2001 From: Alex Unger Date: Fri, 28 Jan 2022 21:22:29 +0100 Subject: [PATCH 2/3] diagrams and clarifications --- docs/ocis/adr/0014-microservices-runtime.md | 11 ++++++++--- docs/ocis/static/runtime.drawio.svg | 4 ++++ 2 files changed, 12 insertions(+), 3 deletions(-) create mode 100644 docs/ocis/static/runtime.drawio.svg diff --git a/docs/ocis/adr/0014-microservices-runtime.md b/docs/ocis/adr/0014-microservices-runtime.md index 11dce88beb..b062027011 100644 --- a/docs/ocis/adr/0014-microservices-runtime.md +++ b/docs/ocis/adr/0014-microservices-runtime.md @@ -13,12 +13,14 @@ geekdocFilePath: 0014-microservices-runtime.md ## Context and Problem Statement -In an environment where shipping a single binary beats the deployment wars, framing a whole family of microservices within a package and running it using Go language mechanisms has plenty of value. In such environment, a runtime is necessary to orchestrate the services that run within it. +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. ## Decision Drivers -- Start oCIS microservices with a single command (`ocis server`) -- Clear separation of concerns +- 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. ## Considered Options @@ -46,6 +48,7 @@ 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. ## Decision Outcome @@ -53,6 +56,8 @@ Number 3: A hybrid solution between framework and in-house. ### Design +{{< svg src="extensions/storage/static/runtime.drawio.svg" >}} + 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](https://github.com/thejerf/suture). The code regarding the runtime can be found pretty isolated [here](https://github.com/owncloud/ocis/blob/d6adb7bee83b58aa3524951ed55872a5f3105568/ocis/pkg/runtime/service/service.go). 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. diff --git a/docs/ocis/static/runtime.drawio.svg b/docs/ocis/static/runtime.drawio.svg new file mode 100644 index 0000000000..bbaa9ba620 --- /dev/null +++ b/docs/ocis/static/runtime.drawio.svg @@ -0,0 +1,4 @@ + + + +
Runtime
Runtime
ocs
ocs
graph
graph
glauth
glauth
accounts
accounts
storage
storage
proxy
proxy
idp
idp
thumbnails
thumbnails
webdav
webdav
suture
suture
$ ocis server
$ ocis kill proxy
$ ocis start proxy
$ ocis list
$ ocis server...
the runtime component starts services
and suture then takes over, keeping
track of every started service, restarting
it when needed if an error occurred.
the runtime component starts services...
each service is implemented as a sub-command. The binary essentially calls itself with the right arguments and the side effect is that a
service is started. The service will then be monitored by Suture.
each service is implemented as a sub-command. The binary essentially calls itself with the right arguments and the side e...
the runtime is a service in itself. Starting an
oCIS instance will start a runtime service.
the runtime is a service in itself. Star...Text is not SVG - cannot display \ No newline at end of file From 0edd178d73ac5defdf441db012cb1cecc233f9e4 Mon Sep 17 00:00:00 2001 From: Alex Unger Date: Mon, 31 Jan 2022 09:48:03 +0100 Subject: [PATCH 3/3] @wkloucek feedback --- docs/ocis/adr/0014-microservices-runtime.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/ocis/adr/0014-microservices-runtime.md b/docs/ocis/adr/0014-microservices-runtime.md index b062027011..820c7f6739 100644 --- a/docs/ocis/adr/0014-microservices-runtime.md +++ b/docs/ocis/adr/0014-microservices-runtime.md @@ -56,7 +56,7 @@ Number 3: A hybrid solution between framework and in-house. ### Design -{{< svg src="extensions/storage/static/runtime.drawio.svg" >}} +{{< svg src="ocis/static/runtime.drawio.svg" >}} 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](https://github.com/thejerf/suture).