Simplistic cloud-native distributed scheduler, serverlessly built on top of AWS services
Even this is not essentially a technical decision, I believe that this “simple” name probably will drive some other important decisions, like the creation of terminologies, naming packages and other stuff, helping defining functionalities, etc. According to Martin Fowler naming things figures out as one of the hardest things in computer science. Apart of a joke, I believe that choose a good name is a good success factor, but this is not a technical decision, which can make things harder.
Chosen option: “delayer-aws”.
All the conception and idea behind of this project was made over the “scheduler” word, which sounds natural, since the main purpose of the project is to schedule a task to run in the future. However, the term “scheduler” reemsemble a lot of things that already are in place, like recurrence e orchestration. The main objective of this project is to provide a way to easily and cost-effectively execute tasks in future. Easily because it will be based in a Restful API to deal with tasks (in face of config files or configuration screen), and cost-effective by using serveless architectural approach. This is very different of current set of tooling, which could be called “schedulers” too (and actually are!), but do a LOT of thing other then this, like but not limited to, recurrence and orchestration. In summary, I would like to think that people would find here more a “system-to-system-todo-list” than in a complete “scheduler”. That’s why I think that “delayer” reflects much more what it will do then “scheduler”. The suffix “-aws” aims to:
This is the name originally chosen (the repository was created with this name). Below arguments fits for all “scheduler”-like names in the list.