Evaluate options and propose a solution for storing and serving online assets commonly used at Stanford (e.g., identity images, website design and development framework code, desktop client installers). This Stanford Content Delivery Network (CDN) could create efficiencies, particularly by reducing the duplication of such assets across the university and by improving the speed of delivering those assets to computers and mobile devices.
Notes
- Joe Little
- S3 clone for hosting videos - restricted
- nginx proxy/Varnish Cache on the backend to service
- Quick interest - dies out; over-engineered, Cheap
- Not much concurrent load needs
- Accessibility of the solution
- Ties to research
- Don’t want to worry about how much it costs (Centrally funded)
- Archival of long term data
- Julian Morley (Associate Director of IT Operations at Libraries
- Would like to move to CDN, not hugely popular
- Terabytes of data
- International audience, high visibility
- Scotty suggested that not all locations need to be fast, different ways of caching for different locations.
- Static content
- https://sdr.stanford.edu
- Most folks are storing Stanford CSS/JS locally on servers
- Shea suggests FONTS! too
- Set up caching, expiration headers
- Sriram asks: security - what kinds of security would be needed - Scotty - these are public content, so we won’t address it at first
- Know where the files are, known secret (Joe Little)
- Encrypted URLs? Similar to Drupal
- John mentioned that there’s been distributed attacks before. CDN vendors can use WAF - firewalls, e.g., Fastly, Cloudflare. Richard in TCG used AWS.
- Shea comments:
- I'd like to put website assets (fonts, images, video) on a CDN and I'd like that CDN to have an image optimization and video streaming service like cloudfront or cloudinary
- Julian comment:
- We currently run on-prem Wowza for video streaming, but are thinking about alternatives.
- Javascript Cross - origin requests
- Some requirements to possibly proxy other sites (like Netlify) to Stanford?
- Shea / Joe might have such need.
- Assets.stanford.edu (Shea)
- Proxy for hosting image/video assets to cloudfront CDN
- Unique hashed URLs to assets
- John recommend completely delegate hostname to CDN provider
- How to structure/control access within CDN?
- Joe suggested unique namespace for different groups
- Publishing to CDN
- Using code.stanford.edu to control publishing / sync to CDN, protected branches, timestamped versions (Scotty)
- I guess there would be two parts for upload. 1. When the asset has already been created and can be pushed independently of the website that is consuming it. Other times, the build tooling will generate the asset and will need to publish the asset to the CDN at build time as well. (Shea)
- Wordpress had a plugin that once you uploaded an asset, it’s goes to S3 and deletes locally. (Scotty)
- Still need to have WAF
- Block DDOS attack
- U-Comm is using an S3 bucket at https://www-media.stanford.edu to host their shared assets and things that come from the identity guide. (Shea’s comment)
- So Scotty what you’re planning to implement is mostly a CDN but not really for Edge purposes? Or will it be also act like an EDGE in various timezones around the world? (Reynaldo Santos)
- Depends on cost (Scotty)
- Do we protect users from themselves? Service offering for standard versus advanced users.
- Using CDN for research data/published work
- Different use case?
- How do we handle life cycle? Who is responsible for the content?
- Strict namespacing
- Use code.stanford.edu to track who is pushing content
- Charge for it even if it’s nominal amt (John)
- Slack Channel
