Oslo AWSome Day keynote
•
0 likes•282 views
The slides from my keynote presentation during the AWSome day in Oslo on June 15th
Recommended
Recommended
More Related Content
What's hot
What's hot (20)
Similar to Oslo AWSome Day keynote
Similar to Oslo AWSome Day keynote (20)
More from Adrian Hornsby
More from Adrian Hornsby (20)
Recently uploaded
Recently uploaded (20)
Oslo AWSome Day keynote
- 1. © 2017, Amazon Web Services, Inc. or its Affiliates. All rights reserved. AWSome Day Velkommen!
- 2. © 2017, Amazon Web Services, Inc. or its Affiliates. All rights reserved. Adrian Hornsby, Technical Evangelist Oslo, June 15th 2017 AWSome Day @adhorn adhorn@amazon.com
- 3. Thank you to our sponsors!
- 4. Leverage the community: AWS User Groups
- 5. AWS User Groups Norway Independent user groups in Oslo and Bergen https://aws.amazon.com/usergroups/ https://www.meetup.com Join a user group today!
- 6. #AWSomeDay
- 8. we want to be earth’s most customer centric company
- 9. A look back at our story.
- 11. 2001 Development transformation at Amazon: 2001-2009 2009 monolithic application + teams microservices + 2 pizza teams
- 12. Things went much better under this model and teams were releasing faster than ever, but we felt that we could still improve.
- 13. In 2009, we ran a study to find out where inefficiencies might still exist
- 14. We were just waiting. WaitWrite Code WaitBuild Code WaitDeploy to Test Deploy to Prod
- 15. • Self-service • Technology-agnostic • Encourage best practices • Single-purpose services
- 16. • Deployment service • No downtime deployments • Health tracking • Versioned artifacts and rollbacks
- 17. Pipelines • Continuous delivery • Automated release process • Faster and more reliable releases • >90% of teams
- 18. = 50 million deployments a year Thousands of teams × Building Microservice × Practicing continuous delivery × Multiple environments (staging, beta, production)
- 20. 75% Reduction in outages triggered by software deployments since 2006 90% Reduction in outage minutes triggered by software deployments ~0.001% Software deployments cause an outage Frequent Deployments
- 21. Drone & Robots Advanced Shopping Kindle Reader In-house Entertainment Grocery Delivery Video Streaming Home AutomationCloud Computing Amazon today
- 22. What about AWS?
- 24. ”Amazon S3 helps free developers from worrying about where they are going to store data, whether it will be safe and secure, if it will be available when they need it, the costs associated with server maintenance, or whether they have enough storage available. Amazon S3 enables developers to focus on innovating with data, rather than figuring out how to store it.” Andy Jassy, 2006
- 26. * As of 1 January 2017 2010 61 516 1,017 159 2012 2014 2016 AWS Pace of Innovation
- 27. we start with the customer and work backwards.
- 29. write the press release
- 30. write the FAQ
- 31. define the user interaction and write the documentation
- 33. Some customers from the Nordics https://aws.amazon.com/solutions/case-studies/
- 34. Some customers from the Nordics https://aws.amazon.com/solutions/case-studies/
- 35. Where do you ?
- 36. Learn from our customers.
- 42. Invest time to save time.
- 43. Thank You!
Editor's Notes
- 1000 members combined now.
- "Our vision is to be earth's most customer-centric company; to build a place where people can come to find and discover anything they might want to buy online."
- Conway's law Single-purpose Connected via APIs Highly decoupled
- So we conducted a study. “Understanding Amazon’s Software Development Process Through Data” in 2009 by John Rauser We wanted to find out how long it takes to go from code check-in through to code being available in production. This included the time it took to build, test and deploy our software. We learned that this was taking a long time. In the order of weeks. And we didn’t want it take weeks to get a code change out to production.
- What we did discover was our processes had lot of human, manual work in them which were taking most of the time. Developers would use tickets or emails to track their release process. Developers would ticket or email other developers to run a build at which point a bunch of requests would batch up before being run. Once the build was done, new tickets were cut to deploy their software. Those requests may also batch up, increasing the time it took for a change to reach production. This was the problem we needed to solve. We needed to automate the production line of developer work so that humans were not longer causing developers to wait, when that work could be automated away.
- - these new tools had some unique characteristics - the tools had to be self-service, because there's no other way to be able to scale to that many customers - the tools had to be technology agnostic, because the teams chose many different types of platforms and programming languages for their services - the tools had to encourage best practices, while we allow autonomy, we also want to support shared learning across the teams so everyone can improve - and of course, in the service-oriented mindset, the tools were delivered as primitive services
- - one of the first primitives to emerge was Apollo, a name that we clearly borrowed from Nasa - Apollo is the deployment engine for Amazon, everything from the retail site to AWS services - it's how we roll out software changes across our servers - we first launched Apollo over a dozen years ago - in that time we've been continually learning about how to manage deployments and baking that knowledge back into the service - one capability was zero downtime deployments - there's no way we would allow taking the retail site down just to push a software change - Apollo supports rolling out a software change without taking down an application - we also can't let a deployment bug take down the app, so Apollo tracks deployment health and stops bad deployments
- - From that study, new primitive emerged: Pipelines, our continuous delivery service - started after we did a study of how long a software change took to go from a developer check in to running in production - I'm not going to share any numbers, but let's say that it was embarrassing how long that took - we found that it wasn't the builds, tests, or deployments that were taking so long, but rather the human processes that tied them all together - one person would notify another person that a task was ready, eventually they'd see the request and batch it with others, finally they'd start a job and let it run, they'd come back later to see if it completed successfully or needed to be re-run, then they'd finally route the task onto another group for the next job - this process added in a ton of human delay, and for a company with an insane focus on efficiency, this was unacceptable - since we're automating our fulfillment centers, we thought we should automate our software delivery - we created Pipelines to automate that end-to-end release process, from code check-in to build to test to production - this tool is used pervasively across Amazon, by well over 90% of the teams
- - what does success look like - there are a lot of ways that you can measure the process, and no one way is perfect - but here's one data point - when you have thousands of independent teams - producing highly-factored microservices - that are deployed across multiple dev, test, and production environments - in a continuous delivery process - you get a lot of deployments - at Amazon in 2014, we ran over 50M deployments - that's an average of 1.5 deployments every second
- Business Value of Frequent Deployments
- Today Amazon is a lot more than just a book store –[..] we are a technologie company with high focus on Customers and Innovations. Willing to bet long term and no scared to fail.
- In November 2004, the first AWS service launched for public usage: Simple Queue Service (SQS) Amazon Web Services was officially re-launched on March 14, 2006,[2] combining the three initial service offerings of Amazon S3 cloud storage, SQS, and EC2.
- Geodata: cost-effectively store millions of aerial GIS images- needed to support a Windows-based file system to process more than 120 TB of raw aerial image data. Telenor : IoT platform for automated management of connected devices and real time analytics Vimond: global broadcast media platform - re-engineered its distribution platform to run on AWS, to reduce costs for its customers and provide them with more agile workflow – support move to IP-format media.
- Lingit: has created software that helps individuals with dyslexia improve their written communication. statistically accurate language model using big data on aws. Get: fibre-based broadband and content provider- launched a new OTT service to its 500,000 households based on AWS. high quality live channels, VoD content Opera: Gelato:
- https://www.flickr.com/photos/stevendepolo/5749192025/ - after we tell customers the story of our DevOps transformation, they typically ask us how they can do the same - I'm not going to over-simplify this, because it is a very complex answer - this can involve organizational changes, cultural changes, and process changes - plus there's no one right answer for these - every company is going to tweak their approach to optimize for their own environment - but there is one standard thing that every DevOps transformation needs, and that's an efficient and reliable continuous delivery pipeline - that's the focus for the rest of this talk
- Today, meet Summit Aws user groups Tech blog Aws use cases
- Story of lift and shift, but embracing is better. Elasticity On-demand Can start 1000 instances, test and shut down. A B testing Load testing experiment
- Story of RDS Story of Cognito
- WirelessCar Expedia https://aws.amazon.com/cloudformation/aws-cloudformation-templates/
- Story of security group changes Aws config Cloudtrail
- Story of lift and shift, but embracing is better. Elasticity On-demand Can start 1000 instances, test and shut down.