Change Details

In the self-service deployment world of [WikiKube](https://wikitech.wikimedia.org/wiki/Kubernetes/Clusters), it's helpful to have a starter kit for product/feature engineering teams. For the last ~8 years, that starter kit has been [wikimedia/service-template-node](https://github.com/wikimedia/service-template-node). From my perspective, this has two main drawbacks: - It's based on Node.js and its ecosystem, which is not a stack that we assess in hiring product/feature engineer staff. Consequently we don't have a lot of in-house expertise on which packages to use, application setup, dependency update practices, testing setup, etc - Perhaps due to lack of in-house expertise, we haven't been making many improvements/fixes to wikimedia/service-template-node for [several years](https://github.com/wikimedia/service-template-node/graphs/code-frequency). To give one example, it has dependencies on [deprecated projects](https://github.com/wikimedia/service-template-node/blob/master/package-lock.json#L5030), and in other cases is using [deprecated dependencies released ~5 years ago](https://github.com/wikimedia/service-template-node/blob/master/package-lock.json#L5837). This makes it hard/impossible to run tools like `osv-scanner` on apps that build on top of `wikimedia/service-template-node`. ### Hypotheses for PHP-based framework * because we have a lot of PHP experience in-house, teams will be much more productive in building new applications to deploy to Kuberentes * if we have a PHP-based framework to point teams to, we'll have a better chance of maintaining a shared framework for services that feature teams deploy to the Kubernetes cluster. We'd also be able to reuse components from MediaWiki. [wikimedia/ToolforgeBundle](https://github.com/wikimedia/ToolforgeBundle) is an example of what I'm talking about, though I think we'd want something more specifically tailored to API use cases. ### Drawbacks / Critiques * There's no guarantee we'd end up with a maintained framework. That requires resourcing. I think we'd have a better likelihood of it due to in-house familiarity with PHP, though. * A common use case for deploying applications to Kubernetes is to integrate with a machine learning model, and that will end up using Python code and libraries. We also don't (as far as I know) have a consensus or common framework for shipping Python applications. Maybe that is more important to focus on than a PHP-based distribution.

In the self-service deployment world of [WikiKube](https://wikitech.wikimedia.org/wiki/Kubernetes/Clusters), it's helpful to have a starter kit for product/feature engineering teams. For the last ~8 years, that starter kit has been [wikimedia/service-template-node](https://github.com/wikimedia/service-template-node). From my perspective, this has two main drawbacks: - It's based on Node.js and its ecosystem, which is not a stack that we assess in hiring product/feature engineer staff. Consequently we don't have a lot of in-house expertise on which packages to use, application setup, dependency update practices, testing setup, etc - Perhaps due to lack of in-house expertise, we haven't been making many improvements/fixes to wikimedia/service-template-node for [several years](https://github.com/wikimedia/service-template-node/graphs/code-frequency). To give one example, it has dependencies on [deprecated projects](https://github.com/wikimedia/service-template-node/blob/master/package-lock.json#L5030), and in other cases is using [deprecated dependencies released ~5 years ago](https://github.com/wikimedia/service-template-node/blob/master/package-lock.json#L5837). This makes it hard/impossible to run tools like `osv-scanner` on apps that build on top of `wikimedia/service-template-node`. ### Hypotheses for PHP-based framework * because we have a lot of PHP experience in-house, teams will be much more productive in building new applications to deploy to Kuberentes * if we have a PHP-based framework to point teams to, we'll have a better chance of maintaining a shared framework for services that feature teams deploy to the Kubernetes cluster. We'd also be able to reuse components from MediaWiki. [wikimedia/ToolforgeBundle](https://github.com/wikimedia/ToolforgeBundle) is an example of what I'm talking about, though I think we'd want something more specifically tailored to API use cases. ### Drawbacks / Critiques * There's no guarantee we'd end up with a maintained framework. That requires resourcing. I think we'd have a better likelihood of it due to in-house familiarity with PHP, though. * A common use case for deploying applications to Kubernetes is to integrate with a machine learning model, and that will end up using Python code and libraries. We also don't (as far as I know) have a consensus or common framework for shipping Python applications. Maybe that is more important to focus on than a PHP-based distribution. * @Tgr: "A possible drawback is that PHP's shared-nothing architecture makes the handling of slow setup steps (e.g. pulling config from a MediaWiki API) complicated. (There are threaded / event looping PHP frameworks these days, though.)"

In the self-service deployment world of [WikiKube](https://wikitech.wikimedia.org/wiki/Kubernetes/Clusters), it's helpful to have a starter kit for product/feature engineering teams. For the last ~8 years, that starter kit has been [wikimedia/service-template-node](https://github.com/wikimedia/service-template-node). From my perspective, this has two main drawbacks: - It's based on Node.js and its ecosystem, which is not a stack that we assess in hiring product/feature engineer staff. Consequently we don't have a lot of in-house expertise on which packages to use, application setup, dependency update practices, testing setup, etc - Perhaps due to lack of in-house expertise, we haven't been making many improvements/fixes to wikimedia/service-template-node for [several years](https://github.com/wikimedia/service-template-node/graphs/code-frequency). To give one example, it has dependencies on [deprecated projects](https://github.com/wikimedia/service-template-node/blob/master/package-lock.json#L5030), and in other cases is using [deprecated dependencies released ~5 years ago](https://github.com/wikimedia/service-template-node/blob/master/package-lock.json#L5837). This makes it hard/impossible to run tools like `osv-scanner` on apps that build on top of `wikimedia/service-template-node`. ### Hypotheses for PHP-based framework * because we have a lot of PHP experience in-house, teams will be much more productive in building new applications to deploy to Kuberentes * if we have a PHP-based framework to point teams to, we'll have a better chance of maintaining a shared framework for services that feature teams deploy to the Kubernetes cluster. We'd also be able to reuse components from MediaWiki. [wikimedia/ToolforgeBundle](https://github.com/wikimedia/ToolforgeBundle) is an example of what I'm talking about, though I think we'd want something more specifically tailored to API use cases. ### Drawbacks / Critiques * There's no guarantee we'd end up with a maintained framework. That requires resourcing. I think we'd have a better likelihood of it due to in-house familiarity with PHP, though. * A common use case for deploying applications to Kubernetes is to integrate with a machine learning model, and that will end up using Python code and libraries. We also don't (as far as I know) have a consensus or common framework for shipping Python applications. Maybe that is more important to focus on than a PHP-based distribution. * @Tgr: "A possible drawback is that PHP's shared-nothing architecture makes the handling of slow setup steps (e.g. pulling config from a MediaWiki API) complicated. (There are threaded / event looping PHP frameworks these days, though.)"