Show HN: Odin – The Observable and Distributed Workflow System
Few bits of advice&#x2F;comments:<p>1. the schedule syntax. It can seem much easier to work directly with English, but there&#x27;s a reason most systems use cron-style schedules and it isn&#x27;t because it&#x27;s legacy. There&#x27;s a benefit in having a syntax that is &quot;alien&quot; when you&#x27;re crossing that human&#x2F;computer&#x2F;dev border, as it forces your users to think about how to achieve something. The other half of the reason is because it&#x27;s a lot easier to validate a strict syntax with a formal grammar than anything even close to natural language. I can basically guarantee you that if someone had come up with a way to accurately parse english recurrence statements, it would have already been adopted by cron in the past (or at least a website like crontab guru[0].<p>2. There is no description of the job execution semantics in the distributed sense. Is it at most once, or at least once? This is important if you&#x27;re designing jobs, so if someone is switching to your system from an existing system with a different semantic it will cause a lot of friction especially if you don&#x27;t even list it in your documentation.<p>3. You have two data stores. You&#x27;re using Raft for backing your key&#x2F;value store, and mongo for both job metadata and also communicating with the dashboard. This is a bit confusing because in the docs you wrote that metadata goes in a sidecar yaml file. What job metadata are you referring to then? Results? Fundamentally, having multiple data stores makes your projects orders of magnitude more complicated to operate and monitor. My guess is you&#x27;ll see this as a major pain point in the future when you want to scale a cluster in different ways (more jobs, more frequent jobs, longer histories, more nodes in the cluster).<p>All in all, it looks like a pretty decent distributed cron, but I wouldn&#x27;t touch your project for my production systems. It&#x27;s lacking a lot of features we need for getting Legacy (TM) work done[1] like running a specific job on a specific worker because it needs access to special hardware or some filesystem or because our PHB decided that as a policy only one of our servers can run billing code on Tuesdays.<p>[0]: <a href="https:&#x2F;&#x2F;crontab.guru&#x2F;" rel="nofollow">https:&#x2F;&#x2F;crontab.guru&#x2F;</a><p>[1]: &quot;Legacy code is code that makes money&quot;