2023-09-08 Sys Ops & Management SIG Agenda and Meeting notes

Session of the SysOps SIG at WolfCon: WOLFcon 2023: Platform Decisions for FOLIO Self-Deploy... (sched.com)

Ingolf: A concern about the (proposed) changing notion of a Platform. If there will be not just one big platform (platform-complete), as it is now, but several smaller platforms, maybe specialized to ERM, circulation, other specific purposes:  All modules which one might possible install must go through thorough buckfest testing (or some QA testing of similar quality). Having just a smaller set of modules undergo the QA testing workflows does not seem acceptable.

----------------------------------------------------------------------------------------------------------------------------

Topics for this Meeting:

• Microservice boundaries, Application Descriptors

Meeting Notes 2023-09-08:

Microservice Boundaries
- example of a large, monolithic module: Inventory & Inventory Storage
 - avoid circular dependencies
 - another example: edge-rtac & mod-rtac; they are useless without each other
    - at the moment, each of it would be considered a microservice
    - it makes sense for some API calls that other modules make use of them,
      but not all of them
    - join databases:
       - cons: even more dependencies
       - pros: smaller data sets via APIs
     - the boundaries of the modules need to be redefined
     - direct database access for other modules should be restricred. This is dangerous.
     - modules within an application are typically being developed by the same developer team
      - loan, users ,   probably not
      - calendar & circ rules could be coupled together
       - define what are really closely related modules
         Julian: Okapi is already an Application Manager
    Nils: If one team changes the database model, the other team needs
           to chnage their module as well
    Nils/Julian: Applications need to be small enought that ONE team can handle this.

    Ingolf: I don't agree with this. It should be possible for any team to contribute to any application. I can assume that teams talk to each other.
     Not related to optimistic locking
    Julian: Needed in some case. But should not be handled in this discussion. Should be restricted to cases where it is needed.
            Discussion should be among the Tech Leads / Dev Leads.
    Tod: It is going to be case by case.
         Check out a single item takes more than 30 disctinct API calls.
     Tod: You cannnot do queriying at a large scale, because you can not do the database joins.
   Julian: Queriyng mod-fqm could produce queries that could take a very long time. You have additinal http request if you do not have database joins.
      You don't have database indices. People could run any query that they want.   A way out could be to allow only specific joins, and dissallow other joins.
   Tod: I think this is the way how the list application is set up.
   Tod: Tod will find some context to the fqm app.

   There is general agreement that it is useful to have database joins.

    Nils: Applications should not expose storage modules APIs to the outside.
    This helps to create a translation how users and admins think of an application.
   Tobias: a platform descripor only shows interface versions.

Discussion about ui boundaries.

Julian, Florian, Tobias: One does not need applications in order to decouple modules, backend or frontend. It could be done with the existing concept. Could be decided on a case by case basis by the dev leads. Introducing Applications will introduce unneccesarry complexity.

Ingolf: But Applications would make it much more clearly structured and visible to the operator what has been deployed (and for what tenant). Applications will be an incentive for dev teams to bundle some modules closer together while decoupling them from the dependencies to other modules. Having 135+ modules to install is a nightmare to an operator. Would be much more clear to have to administrate just ca. 20 Applications. Don't want to go into the details for what happends on the module level, want to hand that over to the Application Manager. 

Others says that this could all be done with the existing structure, using Okapi as the application manager.

Comparison with linux system which has just one level of complexity.

Agreement, that not having the domain explicitly been baked into the UI bundles will be an improvement.

There is no agreement about introducing the notion of an application descriptor. The majority of the group is against having application descriptors.

https://folio-org.atlassian.net/wiki/pages/viewpage.action?pageId=2098208

Julian Ladisch  an  Alle 16:38
https://folio-org.atlassian.net/wiki/display/~marcjohnson/Check+Out+Performance
However, that check out performance analysis had been done before the optimization that greatly reduced the calls.

his is the PC meeting where the Lists App was presented: https://folio-org.atlassian.net/wiki/display/PC/2023-06-08+Product+Council+Meeting+notes
The meeting recording would have more detail.

Need to pick up topics from the Application Formalization proposal in further sessions:

• Application store or marketplace?

• Overview: List of Integrations - System Operations and Management SIG - FOLIO Wik