AWS re:Invent 2018: [REPEAT 1] A Serverless Journey: AWS Lambda Under the Hood (SRV409-R1)
Amazon Web Services2 HN recommenders · recommended in 2 months, 2019-2019
72K views · 7 years ago · talk · dated
An AWS re:Invent 2018 session in which Holly Mesrobian and Marc Brooker explain how AWS Lambda is built, including its sandboxing, isolation and scaling architecture. It covers what happens under the hood when serverless code runs.
HN cites it as the authoritative description of Lambda internals and isolation, by the engineers who built it.
53:43AWS re:Invent 2018: Amazon DynamoDB Under the Hood: How We Built a Hyper-Scale Database (DAT321)
Amazon Web Services
112K views • 7 years ago
46:15AWS re:Invent 2014 | (SPOT302) Under the Covers of AWS: Its Core Distributed Systems
Amazon Web Services
10K views • 11 years ago
55:44AWS re:Invent 2018: How AWS Minimizes the Blast Radius of Failures (ARC338)
Amazon Web Services
37K views • 7 years ago
42:26AWS re:Invent 2015 | (NET403) Another Day, Another Billion Packets
Amazon Web Services
55K views • 11 years ago
47:51AWS re:Invent 2014: AWS Innovation at Scale with James Hamilton (SPOT301)
Amazon Web Services
70K views • 11 years ago
1:33:27AWS re:Invent 2016: Tuesday Night Live with James Hamilton
Amazon Web Services
133K views • 9 years ago
59:13AWS re:Invent 2019: [REPEAT 1] Amazon DynamoDB deep dive: Advanced design patterns (DAT403-R1)
AWS Events
115K views • 6 years ago
59:56AWS re:Invent 2018: Amazon DynamoDB Deep Dive: Advanced Design Patterns for DynamoDB (DAT401)
Amazon Web Services
468K views • 7 years ago
1:05:06AWS re:Invent 2018: Powering Next-Gen EC2 Instances: Deep Dive into the Nitro System (CMP303-R1)
Amazon Web Services
57K views • 7 years ago
17:22AWS re:Invent 2020: Working backwards: Amazon’s approach to innovation
AWS Events
80K views • 5 years ago
56:55AWS re:Invent 2017: How Netflix Tunes Amazon EC2 Instances for Performance (CMP325)
Amazon Web Services
18K views • 8 years ago
1:10:23"Systems that run forever self-heal and scale" by Joe Armstrong (2013)
Strange Loop Conference
85K views • 5 years ago
53:14Mastering Chaos - A Netflix Guide to Microservices
InfoQ
2.3M views • 9 years ago
23:20Keynote: KubeCon Opening Keynote - Kelsey Hightower, Google
CNCF [Cloud Native Computing Foundation]
27K views • 8 years ago
48:30Design Microservice Architectures the Right Way
InfoQ
741K views • 8 years ago
5:28Inside a Google data center
Google Workspace
22.6M views • 11 years ago
47:43"Turning the database inside out with Apache Samza" by Martin Kleppmann
Strange Loop Conference
205K views • 12 years ago
32:24RustLatam 2019 - Without Boats: Zero-Cost Async IO
Rust Programming Language
55K views • 7 years ago
52:41Seattle Conference on Scalability: YouTube Scalability
Google TechTalks
30K views • 19 years ago
28:21Velocity 2012: Richard Cook, "How Complex Systems Fail"
O'Reilly
60K views • 14 years ago
3 comments from Hacker News
Here are a couple videos from reInvent 2018: Jaso talking about DynamoDB internals link Marc talking about Lambda internals ▶ this video
AWS SDE here. The short answer is, in order to get your team to adopt something, you need to make the case that it's better for customers (including things like migration costs). If the modern thing is more efficient, is higher availability, increases velocity, and so on then the case can be made. Some specific examples based on things you cite: * For an example of something OSS or "modern" coming from AWS, checkout Firecracker (written in Rust): link * With regards to "reinventing wheels" Apollo + EC2 solves a lot (not all) of the problems that containers solve, and existed for years before containers became the hotness. * Docker, which brought containers to the masses launched in 2013. * EC2 launched in 2006 (7 years before Docker). * Apollo (and the build system Brazil) predated EC2 by many years. * Amazon.com was migrating to EC2/AWS before 2012 ( link ) * Another example, Lambda, which launched in 2014 runs on EC2 ( ▶ this video ). * New services get to build in AWS and use Lambda, ECS, DynamoDB etc based on their business needs.
I believe AWS does share customer information within a device, but with a lot of sandboxing below that. You can watch this talk to learn more: ▶ this video I think the threat model is basically that you'd need a KVM kernel 0-day + the ability to exploit it, so a point of privilege such as outside of the firecracker sandbox.