(A few) Lessons we learned in >5 years Amazon Web Services

Transcript

1. (A few) Lessonswelearnedin >5 years Amazon Web Services Markus Ostertag (@Osterjour) Team Internet AG
2. Who isthisguy? • >20 yearsin Online-Business • Graduatedin IT @ TU Munich • Working withTeam Internet AG as VP Engineering • Organizer AWS Usergroup Munich • AWS Community Hero Markus Ostertag (@Osterjour)
3. Who is Team Internet? • Domain monetization business • 35 people • HQ in Munich, Germany • Tech focused
4. Whycloud–a decisionmorethan5 yearsago
5. >5 yearslater–nowayback and happy aboutit! We have more and more infrastructureat AWS… … every single day
6. Be „cloudnative“ • Commitmentto thecloud is thekey (Don‘t limit yourselfwith hesitation) • Cloud is morethan a glorified data center • Use thedifferent servicesand each benefits – security groups on EC2 – SQS to decouple your systems – let AWS do the heavy lifting – …
7. Focus on yourproductnot theinfrastructureor technicaleffortbehindit! Your customerswill loveyou for this!
8. Thereisnot onedatabasetorulethemall MongoDB Tracking API RTB Engine User&Stats API Tracking API RTB Engine DynamoDB Decoupled Amazon Aurora Amazon Redshift User&Stats API
9. Pick therighttoolforthejob DynamoDB • Key/Value • Scalable throughput • Low latency Amazon Aurora • More complex data/queries • Scalable storage Amazon Redshift • Big (complex) data • Higher latency ElastiCache for Redis • Key/Value • In-Memory • (Very) low latency
10. Split yourarchitectureintoseveralstacks • Divide the needs – Write-heavy vs. Read-heavy – Unstructured data vs. structured data – Consistent load vs inconsistent load • Instance costs: 2x db.r3.large === 1x db.r3.xlarge • More granular scaling (= morecost effective) • Issue pinpointing and team responsibilityeasier
11. „Everythingfailsall thetime“ –Werner Vogels Be prepared & know the impact of failures
12. Fails happen on everylevel • Instance level – Be stateless as much as possible – Use auto-scaling groups and or spot instances as it forces you to deal with it • Availabilityzones (data centers) – always use >= 3 AZs – Go serverless -> AWS handles AZ outages for you • Make „everythingfails all thetime“ your mantra for your architecture
13. Multi Region • Use theglobal footprint! • Regionsare independent from each otherat AWS – Fallback to another region in your code (SQS, S3) – Multi-region replication (RDS) – „Automatic“ failover systems by building auto-scaling groups in multiple regions and switch on high-level (i.e. Route53)
14. Last andmostimportant
15. Knowyourapplication(s) • Rethinkeverything! – What are the real requirements? (Never use something just because „it‘sthere“) • Try to leverageevery serviceand combine them • Focus on your product not the technicaleffortbehind it • Each part of your architectureis an own stack (End-to-End)! • Be prepared for failures!
16. Don‘tbeafraidtoaskforhelp! • AWS Solution Architects& Account Managers • AWS Usergroups: http://aws-muc.de • AWS Forums • Me ;-)
17. • Mail: markus@teaminternet.com • Xing: http://xing.to/mo • Linkedin: http://de.linkedin.com/in/ostertag • Twitter: @Osterjour