Hi folks,
I'd like to get your thoughts on which topics make sense as big room conversations at the MediaWiki Developer Summit. Here's a list of candidates: https://phabricator.wikimedia.org/T86028
Current version of the text copy pasted below for the lazy, but there may be updates by the time your read this. Please make your comments in Phabricator.
Thanks Rob
Service-oriented architecture
Discussion or talk?
- Short intro & view back - Layering: Stateful vs. stateless services - special challenges at the state layer: avoid SPOFs, replication and consistency, scaling - High-level functional groups / service candidates - SOA support infrastructure - RESTBase: storage, content API and service orchestration - Auth service - PHP API - public vs. private APIs
Common design goals and issues
Panel discussion
- Demand management, "back pressure" - Authentication - Operational / practical: monitoring, deployment - 3rd party users / distribution / scaling down - Caching & invalidation strategies - Required attendees: Gabriel Wicke, Services team, Faidon Liambotis, Sean, Chris Steipp
Looking ahead: Virtualization, CI and continuous deployment
Panel discussion
- want to share hardware between services while improving isolation for perf and security - moving towards virtualization both in production and CI - what does this mean for our deployment strategy / tools? - dark deploys https://www.facebook.com/note.php?note_id=96390263919 with deployment orchestration integrating with monitoring? - do HET deploy with different VMs? - role of betalabs vs. dark deploys - Participants: @akosiaris https://phabricator.wikimedia.org/p/akosiaris/, @greg https://phabricator.wikimedia.org/p/greg/, @hashar https://phabricator.wikimedia.org/p/hashar/, @Krinkle https://phabricator.wikimedia.org/p/Krinkle/, @bd808 https://phabricator.wikimedia.org/p/bd808/, @cscott https://phabricator.wikimedia.org/p/cscott/, @GWicke https://phabricator.wikimedia.org/p/GWicke/, ?
SOA proliferation through specification
Talk / tutorial by @Jdouglas https://phabricator.wikimedia.org/p/Jdouglas/
- specification-driven service design - specification-driven documentation - Swagger UI sandboxes make services easy to grok - low client-side development/consumption impedance - promotes the creation of numerous and innovative (client) applications - breakout/workshop: quick client generation with swagger-codegen?
The road to multi-DC operation
Should perhaps be covered by main panel, as it affects a lot of decisions
- issues: replication consistency, caches - possible solutions - how this affects our software architecture
Scaling down for third-party users
Should perhaps be covered by main panel, as it affects a lot of decisions
- define minimum resources for a basic MediaWiki install (strawman ex: $2.99 / month VM with 1G of RAM http://www.ovh.com/us/vps/vps-classic.xml?) - simple & small implementations of common services for testing and small installs - setup automation / packaging for VMs
Security in a distributed service environment
Talk / tutorial by @csteipp https://phabricator.wikimedia.org/p/csteipp/. Tracked in more detail in T86049 https://phabricator.wikimedia.org/T86049.
- advantages of isolation between services vs. challenges of multitude of entry points - what we learned from experience in our current architecture - what others learned from experience in a SOA setting - how to address challenges: SOA auth RFC https://www.mediawiki.org/wiki/Requests_for_comment/Service-oriented_architecture_authentication - CSP and other headers - appropriate use of CORS - when to use OAuth
Ideas for content representation / UI / skins
Really in the 'editing' track. TODO: Figure out if other front-end stuff / caching fits in there.
- Move to HTML primary storage / wikitext editing? - Micro-contributions using Parsoid HTML: API needs, how it could look - API-powered front-ends: mobile already very far - Fast logged-in views for mobile web and desktop: ESI vs. client-side customizations & no-JS fall-back - again, mobile very close already
Platform choices for new services
Not convinced that this would really be productive
- SOA gives us freedom to choose (and change) technology per service / task - don't want to go overboard though, as each additional technology has a cost - current main development platforms: PHP, client-side JS & Node.js, some Java - trends: industry and WMF - new candidates: Hack, Go, Rust - relative strengths for our use cases - successful outcome: - shared understanding of relative strengths and trends - possibly guidance on what to choose in which area - awareness of new options