Don't let the Cloud Rain on Your Parade

A lightning talk about basic techniques to verify that third-party vendors can't bring your website down from #DjangoCon 2017

Transcript

1. Don’t let The Cloud Rain on Your Parade Adam Fast JBS Solutions
2. “The Cloud” isn’t 100% available • File Storage (S3, …) • Payment Processor (Stripe, Braintree, …) • Sales Tax services • Notification services (SES, SendGrid, Twilio, …) • Error reporting (Sentry, OpBeat, New Relic, …)
3. Where do we start? Before removing the LAN cable or disabling WiFi
4. What failure modes are acceptable (to the business)? • Credit Card Processing • Store order information upon submit (backfill authorizations / charges once available) • Probably can’t add new cards / edit existing (PCI compliance) • Also can’t list / delete cards for a user (could cache tokens and metadata though to make this work) • Sales tax information • Risk customer goodwill by changing pricing later • Allow orders through anyway and pay it for them • Prevent submission
5. What failure modes are acceptable (to the business)? • Transactional alerting • Any other “cloud” function • Repeat similar options to those shown on previous slide • Do you display a 500, use a generic error screen, or adjust the messaging for each instance? • How will these failures be tracked for follow-up? • What management commands / tools are necessary to allow follow-up?
6. Levels of failure • Lack of data link connection (no software needed) • DNS resolution (local router DNS cache table) • Timeout • Connection refused • Other than HTTP 200 responses
7. Determine how to configure a new endpoint URL in the client • Unless you run a local proxy or an SSL version of runserver, each library needs the ability to override going to HTTPS
8. …oh, it isn’t configurable “Messy”, and with drawbacks - but we’re building test tooling here, not production transaction handling.
9. Override SOAP WSDL URLs • Failure to retrieve WSDL will fail differently than a method failure, and often WSDLs are cached • Download WSDL file • Replace URLs in your version (template)
10. Override the WSDL / Service
11. Test • Start with unit / integration tests, if you didn’t mock your third-party libraries all out • However, some failures / errors may be acceptable here - use discretion • Selenium suite (if applicable) • Spidering (patu) • Test as a user • Fix failures as you find them - should not bring down site • Re-test often (dedicated environment / Selenium?)