Change Details

Determine must/should/may evaluation criteria for comparing FLOSS PaaS solutions. These should cover both operational and end user concerns. Add proposed criteria as comments on this task and then summarize here in the main description as consensus is found. Announced on labs-l: https://lists.wikimedia.org/pipermail/labs-l/2016-May/004494.html

Determine must/should/may evaluation criteria for comparing FLOSS PaaS solutions. These should cover both operational and end user concerns. Add proposed criteria as comments on this task and then summarize here in the main description as consensus is found. Announced on labs-l: https://lists.wikimedia.org/pipermail/labs-l/2016-May/004494.html === What's a PaaS and why do I care? === PaaS is an acronym for "Platform as a Service". In this case the platform being described is a software hosting platform and the "as a Service" part means that the platform will be hosted in the Tool Labs project of the Wikimedia Labs public cloud computing offering. The Labs team has already chosen Kubernetes as the next generation replacement for Open Grid Engine to handle the process of running tools and bots on a flexible grid of compute nodes. Using Kubernetes directly is possible, but it provides a really large number of choices for the end user to make. A PaaS would add an opinionated command and control layer over the top of Kubernetes and hide most or all of the complexity of the underlying system from the average Tool Labs maintainer. Another way to think if this is that PaaS is to Kubernetes as `jsub` is to Open Grid Engine. The `jsub` program and it's siblings `jstart` and `qcronsub` form a platform that Tool Labs maintainers have been using since they moved over from toolserver. The conventions of where files must be placed on the bastions, where output logs are sent, and how to start and stop grid jobs form a type of PaaS over Open Grid Engine. `jsub` has a couple of downsides. First and foremost it is a homegrown system which means that no one helps share the burden of maintaining the software and its documentation. Additionally it is a "leaky abstraction" in that it allows and in some cases requires the user to use Open Grid Engine terminology and command line arguments to accomplish certain tasks. Finally it's a system that still allows a nearly infinite amount of freedom in how things are done. This can be great for the occasional power user, but is challenging for the typical beginner because there are no best practices to follow and a large number of choices to make. A PaaS doesn't need to be inflexible, but ideally it will provide an obvious best way to do most things that lowers the initial learning curve and complexity for a typical small Tool Labs project. For the programming language geeks in the audience, I'm hoping for something closer to Python than Perl. Some tools may end up being more difficult to fit into a given PaaS workflow than others due to the opinions enforced by the PaaS.

Determine must/should/may evaluation criteria for comparing FLOSS PaaS solutions. These should cover both operational and end user concerns. Add proposed criteria as comments on this task and then summarize here in the main description as consensus is found. Announced on labs-l: https://lists.wikimedia.org/pipermail/labs-l/2016-May/004494.html === What's a PaaS and why do I care? === PaaS is an acronym for "Platform as a Service". In this case the platform being described is a software hosting platform and the "as a Service" part means that the platform will be hosted in the Tool Labs project of the Wikimedia Labs public cloud computing offering. The Labs team has already chosen Kubernetes as the next generation replacement for Open Grid Engine to handle the process of running tools and bots on a flexible grid of compute nodes. Using Kubernetes directly is possible, but it provides a really large number of choices for the end user to make. A PaaS would add an opinionated command and control layer over the top of Kubernetes and hide most or all of the complexity of the underlying system from the average Tool Labs maintainer. Another way to think if this is that PaaS is to Kubernetes as `jsub` is to Open Grid Engine. The `jsub` program and it's siblings `jstart` and `qcronsub` form a platform that Tool Labs maintainers have been using since they moved over from toolserver. The conventions of where files must be placed on the bastions, where output logs are sent, and how to start and stop grid jobs form a type of PaaS over Open Grid Engine. `jsub` has a couple of downsides. First and foremost it is a homegrown system which means that no one helps share the burden of maintaining the software and its documentation. Additionally it is a "leaky abstraction" in that it allows and in some cases requires the user to use Open Grid Engine terminology and command line arguments to accomplish certain tasks. Finally it's a system that still allows a nearly infinite amount of freedom in how things are done. This can be great for the occasional power user, but is challenging for the typical beginner because there are no best practices to follow and a large number of choices to make. A PaaS doesn't need to be inflexible, but ideally it will provide an obvious best way to do most things that lowers the initial learning curve and complexity for a typical small Tool Labs project. For the programming language geeks in the audience, I'm hoping for something closer to Python than Perl. Some tools may end up being more difficult to fit into a given PaaS workflow than others due to the opinions enforced by the PaaS.