Conference Presentation
Caveat Configurator: How to replace configs with code, and why you might not want to
- Jane Street anticipates that designing flexible, reusable systems could theoretically reduce deployment time from a stated but acknowledged as "completely made up" and "way over optimistic" 30 days to one day, though the organization fears a critical bug in a tight loop poses an existential risk to employment while smaller bugs only incur opportunity costs.
- Plans include utilizing configuration strategies that instantiate general systems for specific cases to maximize development efficiency, alongside the potential risk that a domain-specific language (DSL) for configuration may contain bugs indistinguishable from core application errors and suffer from poor tooling lacking standard IDE features like "jumping to definitions."
- The organization expects that relying on an OCaml Plugin library for unrestricted configuration code creates dangerous scenarios where code operates outside developer trust boundaries, and predicts that without disciplined versioning, core application updates will break plugins due to library compatibility issues, a problem that has already led to abandoned applications.
- To resolve versioning and tooling limitations of standalone plugin files, Jane Street plans to bundle plugins with the application as a single versioned unit treated as core application code, effectively avoiding the downsides of dynamic runtime extensions.
- A "Config Generation" approach is preferred for applications not requiring Turing completeness or true runtime dynamism, allowing the generation of files in any format (such as CSV) with clear version diffs, while ensuring generated code is version-controlled either via the generated config file itself or the generator script.
- The organization plans to implement "PlugD," a system to centralize plugins, treat them as application code subject to review and compilation, and manage maintenance currently handled by approximately one person with backup knowledge available within the team.
- PlugD aims to decouple application developers from plugin writers while maintaining stability through a workflow that synchronizes patches between application versions, which is deemed necessary when plugins must be decoupled for use by non-developers to ensure safety through code review and testing.
- Future expectations indicate that plugins are often not migrated to core features in subsequent program versions, a decision contingent on specific use cases and user feedback, while the current tooling for standalone plugins is expected to remain incompatible with standard editors due to distinct file treatment.