This is the transformation (and delivery) from the unified service-developer representation of the schema to the active schema model in Kessel. There have been two main approaches identified:

• Monolithic - this is similar to what happens today, where schema files (of various types) are tracked in git, transformed (as-needed) by git workflows, and artifacts released to the appropriate services
  • This could produce multiple necessary build artifacts from a unified schema input
  • This allows upfront validation of schema changes prior to deployment + review
  • ..And for management fabric teams to plan for things like breaking changes (that may require data purging or migration)
  • However..
  • This operates on a separate release cycle from the service, allowing code and schema to get out of sync
    • Which we've seen happen- code is released after a schema change is merged but before the schema is released, and runtime errors result
  • ..And requires toil from management fabric teams
• Incremental - this is more like how database schemas operate, with services deploying their sub-schemas at release via an API (ex: with an init container)
  • This eliminates the separation between the schema release and the code release so they're always in sync
  • This is potentially easier to reason about as it's more similar to other familiar abstractions
  • This is entirely self-service
  • However..
  • This shifts producing build artifacts to Kessel, which must be done at runtime
    • Also, the "current" schema must be retained across pod restarts so that there is always a schema (service sub-schemas will be reported eventually but not immediately and in a non-deterministic order, meaning dependent services may report their sub-schemas before their dependencies do)
  • Updates happen immediately, potentially without review from management fabric team
    • Service developers will need a reliable means to test not only their sub-schemas but merging their sub-schemas with the larger whole prior to release (ex: via Kessel-in-a-Box)
    • Any breaking changes (ex: a relationship being removed) need to be handled appropriately
• Some hybrid - it may be possible to combine some aspects of both approaches.
• Monolithic-then-Incremental - some phasing may be appropriate, ie: keeping the transformation and delivery monolithic initially but with a plan to migrate to incremental schema later (recognizing that would impact adopters)