Author(s):	Sam Kitajima-Kimbrel
Location	Room 106
Date	aug Sat 13	Days Raw Files
Start	11:50	First Raw Start	error-in-template
Duration	0:30:00	Offset	None
End	12:20	Last Raw End
Chapters
Total cuts_time	None min.

https://2016.pycon-au.org/schedule/23/view_talk
raw-playlist raw-mp4-playlist encoded-files-playlist mp4 svg png

assets release.pdf From_Flying_Circus_to_Holy_Grail_Migrating_the_Twilio_API_from_PHP_to_Python_3.json
logs
Admin: episode episode list cut list raw files day marks day marks day image_files

State:	--------- borked edit encode push to queue post richard review 1 email review 2 make public tweet to-miror conf done
Locked:	clear this to unlock
Locked by:	user/process that locked.
Start:	initially scheduled time from master, adjusted to match reality
Duration:	length in hh:mm:ss
Name:	Video Title (shows in video search results)
Emails:	email(s) of the presenter(s)
Released:	Unknown Yes No has someone authorised pubication
Normalise:
Channelcopy:	m=mono, 01=copy left to right, 10=right to left, 00=ignore.
Thumbnail:	filename.png
Description:	Almost every software project of meaningful scale eventually runs into architectural problems. One of the larger issues we’ve dealt with at Twilio is an increasingly-brittle and hard-to-manage PHP codebase, originally responsible for running a website and public REST API. Rather than risk a from-scratch rewrite of the entire system, we chose to extract small and well-defined chunks one at a time into simple services using a common internal interface standard. Given a new fleet of services and a set of internal REST APIs, how do we get to parity with the existing public API specifications? Rather than force every service to implement authentication, data validation, rate-limiting, and so on, we chose to build a simple federation service to translate and proxy customer requests to internal systems. Python was a natural choice for this application due to its flexibility, extensive library and testing ecosystem, and suitability for rapid prototyping and development. But: how did we get from A to B? This talk will cover the details of Twilio’s past and current API architecture, how we adapted the service-oriented architecture pattern to build a consistent public interface, and the testing and deployment strategies we used to migrate 5 billion monthly requests from old to new systems with no downtime. markdown
Comment:	production notes