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_archit…>
- 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