Reading/FY2016-2017 Architecture Needs

The WMF fiscal year 2016-2017 (FY16-17) starts July 1, 2016 and ends June 30, 2017.

What shape does the architecture Reading wants take on for FY16-17? Granted, strategy processes are in flight, but based on what information exists today and looking into the crystal ball what do we think?

Please sub-bullet comment inline with the customary MediaWiki signature. If there are additional areas we really need to think hard about, please add a new bullet.

More specifically:
 * Do we plan to begin the migration to a Node.js server side composited experience with distinct page components or do we instead plan to do most web things exclusively in MediaWiki PHP?
 * Do we anticipate creation of more RESTbase microservices (e.g., aggregators or what roughly amount to versioned proxies to ensure backward compatibility) or do we anticipate defining canonicalized shared URL formats (less likely alternative: edge side canonicalizer) and using smaxage for scaling for api.php endpoints?
 * How much do we foresee a need to grow the memcached object pool?
 * How much do we foresee a need to grow the Varnish object pool?
 * How much do we foresee a need to grow the Cassandra object pool?
 * What sort of notifications architecture do we want and for what purposes?
 * What sort of trending and hybrid algorithm/human curator endpoints and rule engine do we want for things like Trending?
 * What sort of additional analytics hosting needs would we ideally have fulfilled?

Note:
 * Various budget was already requested in the "core narrative" for testing devices, software/SaaS licensing, and known contracting needs
 * No budget was requested for an additional Mac Mini in the "core narrative" (no input was received on this page).