ticketea Why the cloud? ✤ Offer high-availability despite of load-spikes. ✤ Scale from 3 servers to 350 in minutes. ✤ Access to awesome services provided by your IaSS. ✤ Be more cost efficient.
ticketea Why the cloud? ✤ Easier to be fault tolerant. ✤ They have a huge team improving always their service. ✤ Incredible uptime (some of them with 99.999999999%).
ticketea Pitfalls ✤ Everything can fail… everything. Have a good plan B. ✤ A plan B isn't a plan B, until is tested. ✤ Pre-heat everything before big events. ✤ Read about your IaSS in forums/email groups. ✤ Try to distribute your machines to avoid thunderbolts ;)
ticketea Distributed systems ✤ Granular failing. ✤ Avoid single point of failure. ✤ Easy code maintainability ✤ Choose the best tech for each project. ✤ Scale the team easier.
ticketea Distributed systems ✤ Hard to deploy. ✤ Hard to see the whole picture. ✤ More complexity: easy to fail. ✤ When shit happens: you need a plan B.
ticketea Development keys ✤ Code reviews in every pull request. ✤ Continuous integration with a strong test suite. ✤ Cook your own receipts. ✤ One-click deployment. ✤ “Continuous” delivery. (not always)
ticketea Deploying code ✤ We’ve changed between a few models, but finally: 1. Create a complete new environment in prod machines. 2. Deploy your code there. 3. Extract one machine from the load-balancer. 4. Create a golden-image
ticketea Deploying code ✤ Atomic deploys. ✤ 0s-downtime deploys. ✤ Easy rollback to the last N versions. ✤ Money-cost friendly ;) ✤ Insanely fast to scale machines when needed.
ticketea Production vs Development environments ✤ Using the same ansible roles ✤ Meta-roles: roles/ | ——django/ | ————tasks/main.yml | ——api/ | ————tasks/main.yml |—— tkt-api/ |———— meta/main.yml api.yml development.yml
ticketea Automating common procedures ✤ fab -f heracles.py stop_consuming_messages:queue ✤ fab -f frontend.py maintenance_on ✤ fab -f sg.py open_sg ✤ fab -f api.py fast_rollback:version