Hi all,

While creating a workflow to deploy folio in a kubernetes-cluster i
stumbled upon some principals of folio which i find rather complicated.
Since it might also be a philosophical manner I want to discuss it here
instead of the slack-chat (also it is a lot of text).

# Okapi-Registry
One thing is the "global registry"[1] which holds a description of all
backend- and frontend-modules in all versions.
As I understand it its purpose is to provide every okapi with a list of
all installable modules (frontend and backen) in all versions, so okapi
can automatically deploy the modules needed by a tenant into its own
docker-daemon.
In a single-server environment this might be a comfortable solution to
a manual setup where an admin has to create each backend-module in
particular.
In a cluster-setup on the other hand i find it difficult to give okapi
access to an underlying cluster or let okapi having its "own cluster"
within the cluster.
In my setup I create all backend-modules myself, and here i find it
redundant to let okapi know of all installable the modules. Since i
take care of all installed modules okapi does not need to know which
modules exists afterall.
My deployment-process for backend-modules right now looks like this:
[2]. The problem is that i have to create a new docker-image for each
backend-module in order to wrap the helper-script in it. As you can
imagine i would like to omit it and just use the folio-images instead.

# Okapi-Cluster
The docs I found so far[3] explain running okapi in cluster-mode by
using a cluster-toolkit called hazelcast. It describes clustering on a
single machine and on separate machines.
There are some issues i have with this cluster-solution:
- I as admin have to decide on which okapi-node a backend-module is
deployed
- One Okapi-node is acting as proxy and is proxying all traffic to the
responsible okapi-node (the one on which the backend-module is
deployed), so there is no load-balancing possible between the okapi-
nodes
- Okapi itself seems to be stateful with its registered modules, so the
application and cannot be load-balanced at startup. However i could
loadbalance okapi by increasing its replicas after all modules were
registered. Perhaps it is an easy task to make module-data storage-
agnostic as well.

In ideal an application should be infrastructure-agnostic and process
what it gets with the information it has. If the state is part of that
process it should be available to the application and each of its
replicas.

I would like to hear your opinion about it and please correct me if I
am wrong. Also I intend to participate in the conference-call on friday
.

Regards
Ulf

[1]: http://folio-registry.aws.indexdata.com
[2]: https://tinyurl.com/y6l3mxvu
[3]:
https://github.com/folio-org/okapi/blob/5fa2880fccd1b3d9013e89fed401bd7233b8b994/doc/guide.md#running-in-cluster-mode

--
Ulf Seltmann
Bereich Digitale Dienste
Webmaster

Universitätsbibliothek Leipzig
Beethovenstraße 6, 04107 Leipzig

T +49 341 97 30624

seltmann@ub.uni-leipzig.de
www.ub.uni-leipzig.de