Skyscanner
•Download as PPTX, PDF•
2 likes•3,508 views
5 Top Tips for Designing Applications for AWS
Recommended
More Related Content
What's hot
What's hot (20)
Viewers also liked
Viewers also liked (20)
Similar to Skyscanner
Similar to Skyscanner (20)
More from Amazon Web Services
More from Amazon Web Services (20)
Recently uploaded
Recently uploaded (20)
Skyscanner
- 2. Adopting AWS
- 3. Who am I? Phil Dalbeck Principal Engineer 6+ years and counting… Recovering Cloud Skeptic
- 4. We aim to be the most trusted and most used online travel brand in the world
- 5. Who are Skyscanner? • Europes leading travel metasearch site • Receive nearly 4m unique visitors a days • >900 staff, with 48 nationalities (at last count!) – 50% are Software engineers • Headquartered in Edinburgh, with offices in London, Singapore, Beijing, Shenzen, Tokyo, Miami, Budapest, Sofia, and of course Glasgow • Recently confirmed as one of the UK’s ”Unicorns” • Regard ourselves as a Tech company, rather than a Travel company
- 6. Now a bit about all of you… Decision makers or influencers Interested in adopting AWS Have lot of questions, and are not sure who’s advice to take Not sure how to get started Probably a bit skeptical Probably not scared of heights
- 7. A brief history of hosting Skyscanner 5000+ Production VM’s 2000+ Development VM’s
- 8. Where are we with AWS adoption? In the last 18 months ~1500 EC2 instances Critical Production workloads Nearly 1PB in S3 Aggressive containerization using Docker on ECS (with some in- house secret sauce) Lambda (Functions as a service)
- 9. Complete migration? Eventually… but Hybrid Cloud a necessity for now Large legacy codebase Still a few nasty architectural Monoliths to address Another 18 – 24 months.
- 10. Why not faster? Manpower and brainpower are finite Faster migration = slower feature delivery
- 11. Why have Skyscanner adopted AWS? Scalability Flexibility Reliability Cost optimization Accelerated product delivery
- 12. Scalability Rapid growth is a nice problem to have… if you have a solution!
- 13. Flexibility Stuff changes. Make sure you can deal with it.
- 14. Reliability “Design for failure and nothing will fail”
- 15. Cost Optimization Q: How much could your business benefit if every penny you wasted on under utilized capacity could instead be spent on driving growth? (Or paying dividends if that’s your thing)
- 16. Accelerating product delivery 3 Years ago 6 to 8 weeks Today 6 to 8 minutes How? AWS supported Containerization and Deployment Automation tooling. API driven infrastructure.
- 17. Accelerating product delivery – some examples Skyscanner Facebook Messenger Bot Amazon Alexa travel search
- 18. Learn from other peoples mistakes “An expert is a man who has made all the mistakes which can be made, in a narrow field.” Niels Bohr
- 19. The One Question to ask yourself before you get started What business need does your cloud project satisfy?
- 20. The single biggest challenge to AWS adoption today
- 21. Skills shortages – Option 1 – Bring in outside help • Advice and hands on support is available from both AWS and a wide range of 3rd party professional services companies. • They can help with discovery, architectural planning, migrations, right up to fully managed services • Take time to decide which partner(s) and what kind of engagement best suit your needs. Be clear with them. • CAUTION: No-one knows your business better than you and your staff. You have the final say!
- 22. Skills shortages – Option 2 – Hire in AWS skilled staff • Good luck! • Crippling practical skills shortage (supply and demand spike) • Consultancies often snap up the best candidates • Make sure they are a fit for your culture. Don’t hire on technical skills alone. • Real experience trumps all else. Certification exams aren't that hard to get* • Make sure you are able to properly technically vet your candidates before arranging interviews! Hands on exercises are best!
- 23. Skills shortages – Option 3 – Upskill from within • Who will operate things once the consultants leave? • Nobody knows your business better than your own staff • Be ready for some reluctance / apprehension / resistance to reskilling • Managing cloud environments will be a natural career progression for many operational staff in the coming years. • Proficiency takes time and hands on practice. Don’t expect miracles overnight. • Cloud architecture / best practice training is often more valuable than practical training at first. Most will pick up the operational bits quickly with a little hands on practice. • Beware of training staff for their next employer!
- 24. Some stuff that isn’t in the manual. Don’t believe everything you read in the documentation The difference in service level between AWS support tiers is huge Before building tools ask AWS if they are in the pipeline already Some pretty important services are not available in every region Architecting for The Cloud: Best Practices < Obligatory read for all staff
- 25. A great way to accelerate your AWS journey Form a center of excellence from your keenest / most skilled staff (operational AND developers!) • Inhouse training • Example scripts/templates • Internal consultancy • Run regular demo’s and showcases • Eat the dogfood
- 27. Demystifying the Cloud How to Leverage the AWS Cloud for your Business
Editor's Notes
- Name Role (with explanation of function – architect, advise) 7 Years @ Skyscanner (should have read the contract better, should have been suspicious when they had me sign it in blood) Recovering Cloud Sceptic (Most important) So I’m pretty well placed to give you some perspective on why you might want to adopt AWS.
- Unicorn who actually makes money. So in the world of unicorns we’re a flying unicorn that lays golden eggs and grants wishes. The engine behind many other travel brands via our B2B engine (Secret Escapes, Lonely Planet etc) Over 50% of our total staff are software engineers, working on new features, backend services or the tools to help deliver those.
- Depending how this goes I ma have to change the punchline of a few jokes.
- SkyscannerB2 (Box 2). Box 1 rumored to have gained sentience and currently runs Switzerland or something. At some point our CEO realized that running the service from a server in his loft was a plan that had run its course. We moved to a singe datacenter here in London, Telehouse. Over time we leased some racks and hardware from a small hosting partner, eventually got to about 40 servers, all bare metal, no two the same… Most recently, big push for virtualisation (NOT private cloud!, still ops managed!). Expanded out to 5 global DC’s. Ability to scale and maintain really beginning to creak.
- No AWS to speak of 18 months ago. Perhaps a similar situation to all of you. Since then we’ve migrated a major business critical workload, many smaller (but no less critical) workloads, and the majority of our development and sandbox workloads now reside on AWS. (We’ll talk about why later). We’ve also aggressively adopting containerization and function-as-as-service mechanisms for reasons we’ll cover later.
- We all have our own reasons for being here today (even if its just for a free lunch and a day out of the office), but if you are considering expanding your infrastructure platforms to include public cloud, its likely there are a few that will be common among all of us. Scalability – Growing too fast for us to keep up with in our own datacentres. Window for upgrading equipment widening every year. Even harder with geographic expansion. **Facebook app example** Flexibility – bloody developers, always changing their minds. One box one day, one technology… do you tie them in for 3-5 years, or do you let them innovate painlessly? Reliability – 99.99% uptime target. We’re really strict with that, if a single subservice is unavailable for a single domain (carhire in spain) then we consider that an outage. We have enough issues with human error without building on a platform that can’t cope with localized failures gracefully. Cost optimization – Sin Graph of global traffic. Kit doing nothing in some places, working its butt off in others. Bought kit can’t be scaled back at night to save costs. #1 Accelerate product delivery – the faster we can build and present quality services to our partners and users, the more successful we become. Anything that stands in the way of that has to go! Traditional infrastructure platforms either don’t fit our needs, or would require a huge investment and transition process to adopt ( true private cloud etc). We’re a technology company, not an infrastructure company. That may seem like an odd thing for a former infx guy to say – but its harsh reality. Every minute, every penny we spend dealing with operational overhead is resource wasted – its time and money we could be spending on growth and features that actually deliver value to users. That’s the core reason we’re embracing AWS. The faster and easier we can deliver product, the faster we can
- Talk about both Upward scaling and outward scaling. More users More products (Mobile, B2B, Hotels, Carhire etc) More geographies. European core (UK really) – but now huge growth in europe, then APAC, now Americas. **HK Datacenter story** Kit arivval delays.
- If we could predict the future we’d all be a damn sight better paid! Requirements change, workloads shift, markets expand and contract. If you can’t adjust then you either incur wastage, or miss opportunities. AWS offers a degree of flexibility in hosting previously unheard of. Turn everything off, and move it half way around the world without downtime faster than you could fly the hardware there. Bring up a DR environment automatically within minutes, without paying for it if you never need to use it. That’s a no brainer.
- The hardware AWS use is not inherently more reliable than enterprise hardware you can buy off the shelf from any number of vendors. Even Jeff Bezos can’t break the laws of physics. Stuff breaks down. Where things differ with AWS versus your own kit is that you no longer need to maintain spares stock, or renew hardware support contracts with a half a dozen vendors, or monitor the tin. Or pay someone to do it all 24/7. That all comes as standard. Something breaks? You either wont notice, or or automatically migrated to something unbroken. If you design your systems properly, you don’t even notice. Skyscanner have a 99.99% uptime target, its written in our company wide objectives. Its massively easier to achieve that with properly architected Systems that we run in AWS compared to workloads we host internally.
- AWS and their partners offer some fantastic tools to help you easily recognize and eliminate wastage on the AWS platform.
- Online business is cut throat. The ability to develop, deploy and assess the performance of new features faster than your competitors is what drives growth of market share.
- Online business is cut throat. The ability to develop, deploy and assess the performance of new features faster than your competitors is what drives growth of market share. Facebook Bot.
- So here’s the good bit, where I impart upon you all literally months of collected wisdom on how to get going with AWS. **CUE INFOMMERCIAL VOICE** BUT THAT’S NOT ALL! We’ll
- Recognize this guy? This is Mr Hank Scorpio. Mr. Scorpio had a problem. It may surprise you to hear that it’s a similar problem that you will all face if you decide to move into AWS. Let me explain. It wasn’t interference from the UN, Nato or MI6 he was worried about. Guys got a flame thrower. In fact, Hank needed to find employees with a specific set of skills (nuclear generator operation in his case) to help advance his plans for world domination, but he had a problem:- Those skills are generally pretty scarce in the marketplace. It can be hard to know what to look for. The people with the proven skills are often not interested in changing employer, or have been snapped up by consultancy companies. In Hanks case this led to him headhunting the second most senior staff member at the Springfield Nuclear Plant… Who turned out to be Homer Simpson, who we all know isn’t exactly a real go-getter, and he didn’t really fit in too well in the end. Lesson 1 – don’t assume that tenure elsewhere equals capability. Be sure if you are hiring in to fill gaps in your AWS skillset, that you’re hiring people that are first and foremost a good fit for the business. Lesson 2 –The best people for your business may well already work there. Look at whether you can promote from within, or discover if there are any latent cloud guru ambitions in the ranks already. You might be surprised. My advice – look internally and externally for people who “get” what cloud can do for your business. The resilience, the flexibility, the scalability, the improved time to market, the reduced need to build tooling yourself. Those are real catch. You can teach someone the mechanics of any platform surprisingly quickly, provided they are already enthusiastic about using it properly. Lesson 2 -