WEBVTT 1 00:00:00.120 --> 00:00:05.559 Imagine deliberately dropping the price of your core product not 2 00:00:05.679 --> 00:00:09.119 just once, but like thirty two times in just six years. 3 00:00:08.919 --> 00:00:11.279 Right, which in any normal business is basically a one 4 00:00:11.279 --> 00:00:13.000 way ticket to bankruptcy exactly. 5 00:00:13.400 --> 00:00:16.320 But for the invisible engine that powers you know, the 6 00:00:16.320 --> 00:00:19.399 modern Internet, it was actually this calculated master stroke. It 7 00:00:19.480 --> 00:00:21.199 led to total global dominance. 8 00:00:21.359 --> 00:00:24.320 Yeah, and today we're looking at the mechanics of Amazon 9 00:00:24.359 --> 00:00:26.120 Web Services or AWS. 10 00:00:26.559 --> 00:00:30.039 Right, Welcome to today's deep dive. We are stripping down 11 00:00:30.079 --> 00:00:33.359 the architecture behind the book Amazon Web Services and Action 12 00:00:33.679 --> 00:00:35.119 by Andreas and Michael Whittig. 13 00:00:35.399 --> 00:00:38.200 And we're also pulling heavily from that foundational forward by 14 00:00:38.200 --> 00:00:38.759 Ben Wayley. 15 00:00:38.880 --> 00:00:42.240 Yeah. And since you the listener probably already know the 16 00:00:42.280 --> 00:00:44.920 basic definitions of cloud computing, we aren't going to like 17 00:00:45.640 --> 00:00:48.079 waste time reciting textbook acronyms. 18 00:00:48.200 --> 00:00:50.039 No, definitely not yea. We are going to look at 19 00:00:50.039 --> 00:00:54.119 the fundamental inversion of how digital infrastructure is actually built, 20 00:00:54.600 --> 00:00:57.240 scaled and paid for. 21 00:00:57.359 --> 00:01:00.439 The mechanical how and the economic why. Okay, let's unpack 22 00:01:00.479 --> 00:01:03.920 this To understand why those forty two price drops make 23 00:01:03.960 --> 00:01:08.239 perfect sense, you have to look at the environment AWS completely. 24 00:01:07.799 --> 00:01:09.640 Disruptive, oh, the dark ages. 25 00:01:09.359 --> 00:01:14.319 Right, In the forward, Ben Wayey paints this very visceral 26 00:01:14.359 --> 00:01:17.480 picture of it. In the late nineties and early two thousands, 27 00:01:17.560 --> 00:01:22.120 it was brutal. Deploying an application was a heavy construction project. 28 00:01:22.239 --> 00:01:26.359 It's like wanting glass of milk and previously having to 29 00:01:26.400 --> 00:01:29.120 buy the cow, build the barn, and then hire the farmer. 30 00:01:29.359 --> 00:01:31.280 Now you just turn on a tap. 31 00:01:31.480 --> 00:01:33.640 I love that analogy. If we connect this to the 32 00:01:33.640 --> 00:01:37.000 bigger picture, this wasn't just a technological shift. It was 33 00:01:37.319 --> 00:01:41.040 a massive business disruption that leveled the playing field. 34 00:01:40.799 --> 00:01:44.840 Because before it was rooted in physical constraints right entirely physical. 35 00:01:45.120 --> 00:01:47.480 If you had a successful application and you needed more 36 00:01:47.560 --> 00:01:50.879 database capacity, you couldn't just write a line of code. 37 00:01:50.920 --> 00:01:53.239 You had to endure this massive procurement cycle. 38 00:01:53.319 --> 00:01:56.760 Yeah, negotiate with vendors, wait weeks for shipping, and then 39 00:01:56.840 --> 00:01:59.480 deal with what Whaley calls literal. 40 00:01:59.079 --> 00:02:01.159 Cable slinging, which just sounds awful. 41 00:02:01.480 --> 00:02:05.000 It was you had engineers in freezing cold data centers 42 00:02:05.159 --> 00:02:09.400 physically bolting servers into metal racks. They're wiring up power supplies, 43 00:02:09.840 --> 00:02:13.680 walking around with like CDs to install operating systems on 44 00:02:13.759 --> 00:02:14.800 every single machine. 45 00:02:14.879 --> 00:02:16.199 Oh wait, I want to push back on that. A 46 00:02:16.199 --> 00:02:18.800 little bit. Go for if I own the physical box 47 00:02:19.039 --> 00:02:22.000 and I have it in my own server room, isn't 48 00:02:22.039 --> 00:02:24.879 that inherently simpler, Like I have total control over my 49 00:02:24.879 --> 00:02:28.800 own hardware. Sure, so why introduce a massive third party 50 00:02:28.879 --> 00:02:29.560 into the mix? 51 00:02:29.879 --> 00:02:32.560 Well, it feels simpler right up until the moment a 52 00:02:32.599 --> 00:02:34.280 power supply fails at two in the morning. 53 00:02:34.439 --> 00:02:35.240 Ah. 54 00:02:35.280 --> 00:02:37.719 When you own the physical box, you own all the 55 00:02:37.719 --> 00:02:42.280 physical liabilities. To achieve genuine reliability on premises, you have 56 00:02:42.319 --> 00:02:43.000 to buy two of. 57 00:02:42.960 --> 00:02:45.240 Everything, two servers, two switches. 58 00:02:44.919 --> 00:02:49.080 Two independent power grids. To enterprise grade HVAC systems, you 59 00:02:49.120 --> 00:02:52.960 are spending massive amounts of capix capital expenditure. 60 00:02:52.400 --> 00:02:55.120 On redundant hardware that literally just sits there doing. 61 00:02:54.879 --> 00:02:57.479 Nothing, just waiting for the primary system to fail. That 62 00:02:57.560 --> 00:03:01.159 financial barrier to entry strangled innovation. You needed millions in 63 00:03:01.240 --> 00:03:03.919 venture capital just to see if your software even worked. 64 00:03:03.759 --> 00:03:06.240 Which brings us to the seismic shift in two thousand 65 00:03:06.240 --> 00:03:10.960 and six when AWS launched. Suddenly you transition from massive 66 00:03:11.039 --> 00:03:16.039 CAPEX to operational expenditure op X. You drop the starting 67 00:03:16.080 --> 00:03:17.840 costs to mere sense per hour. 68 00:03:18.199 --> 00:03:19.479 It was revolutionary. 69 00:03:19.639 --> 00:03:23.080 But to really grasp how they did this, we need 70 00:03:23.120 --> 00:03:26.759 to address a trope that drives me absolutely crazy. Which 71 00:03:26.759 --> 00:03:29.960 one People constantly joke that the cloud is just quote 72 00:03:30.240 --> 00:03:35.080 someone else's computer. Ah, It completely misrepresents the underlying mechanic. 73 00:03:35.199 --> 00:03:37.960 It completely misses the point. It is not someone else's computer. 74 00:03:38.479 --> 00:03:41.919 It is a highly orchestrated software defined data center. 75 00:03:42.120 --> 00:03:44.840 Right lift Look at the officialness definition for a second, 76 00:03:45.080 --> 00:03:48.080 the National Institute of Standards and Technology. They call it 77 00:03:48.319 --> 00:03:52.039 ubiquitous convenient on demand network access to a shared pool 78 00:03:52.080 --> 00:03:54.680 of configurable computing resources. 79 00:03:54.199 --> 00:03:56.639 Which is a mouthful. But the magic there is the 80 00:03:56.719 --> 00:04:01.080 virtualization layer. AWS uses hypervisors, which is basically software that 81 00:04:01.120 --> 00:04:02.879 sits directly on the bare metal hardware. 82 00:04:02.919 --> 00:04:04.080 And what does that do Practically? 83 00:04:04.159 --> 00:04:07.400 It slices a single mansive physical server into dozens of 84 00:04:07.439 --> 00:04:09.400 completely isolated virtual machines. 85 00:04:09.719 --> 00:04:12.039 So when I spin up an EC two instance, I'm 86 00:04:12.080 --> 00:04:15.439 getting a mathematically isolated slice of compute power. 87 00:04:15.319 --> 00:04:19.360 Exactly, And the hypervisor tricks your operating system into thinking 88 00:04:19.480 --> 00:04:22.079 it has the entire physical machine all to itself. 89 00:04:22.199 --> 00:04:27.120 Wow. And this introduces deep layers of abstraction. AWS hides 90 00:04:27.120 --> 00:04:29.000 the physical hardware layer entirely. 91 00:04:29.160 --> 00:04:32.199 You don't know, and you really shouldn't care which specific 92 00:04:32.399 --> 00:04:35.360 hard drive sector or motherboard your code is running. 93 00:04:35.079 --> 00:04:40.279 On because if the motherboard degrades, AWS just seamlessly migrates 94 00:04:40.319 --> 00:04:43.160 your virtual instance to a healthy physical. 95 00:04:42.720 --> 00:04:46.160 Machine, often without you even noticing a blip in performance. 96 00:04:46.519 --> 00:04:50.240 That abstraction naturally leads into how we deploy architecture. You know, 97 00:04:50.279 --> 00:04:53.720 we have public, private, and hybrid deployment models, and we 98 00:04:53.800 --> 00:04:56.759 all know the basic service types infrastructure as a service, 99 00:04:56.920 --> 00:05:00.839 platform as a service, software as a service, right, POS 100 00:05:00.920 --> 00:05:03.680 and sauce. But let's look at the actual implications of 101 00:05:03.759 --> 00:05:06.319 choosing between them. Wait, can we use the pizza delivery 102 00:05:06.360 --> 00:05:08.800 model to explain the shared responsibility model? Here? 103 00:05:08.879 --> 00:05:10.639 Oh, go ahead, laid out. I like that one. 104 00:05:10.720 --> 00:05:12.959 Okay, So if you build on premises, that's like making 105 00:05:12.959 --> 00:05:16.279 a pizza entirely from scratch. You grew the tomatoes, you 106 00:05:16.319 --> 00:05:19.800 bought the oven, you build the dining table. It takes forever. Right, 107 00:05:20.079 --> 00:05:23.920 infrastructure as a service or ies like Amazon EC two, 108 00:05:24.000 --> 00:05:28.720 that's like buying a frozen pizza. AWS provides the foundational ingredients, 109 00:05:29.079 --> 00:05:32.199 the compute, the storage, the networking, and you still. 110 00:05:32.040 --> 00:05:33.720 Have to put it in your own oven, bake it 111 00:05:33.800 --> 00:05:34.959 and serve it exactly. 112 00:05:35.040 --> 00:05:38.160 You manage the operating system and the run time. Then 113 00:05:38.160 --> 00:05:42.040 you have platform as a service pass like Elastic beanstalk 114 00:05:42.480 --> 00:05:43.959 that's getting a hot pizza delivered. 115 00:05:44.000 --> 00:05:46.879 They manage the underlying infrastructure and the runtime environment. Yep. 116 00:05:47.000 --> 00:05:49.480 You just supply the application code, which is the toppings. 117 00:05:49.720 --> 00:05:49.879 Yeah. 118 00:05:49.920 --> 00:05:52.920 And finally, software as a service like Amazon Workspaces. That's 119 00:05:52.959 --> 00:05:55.360 just going out to a restaurant. You eat the pizza. 120 00:05:55.439 --> 00:05:56.439 They handle everything. 121 00:05:56.600 --> 00:05:59.519 It's an excellent way to visualize the shared responsibility model. 122 00:06:00.199 --> 00:06:03.720 AWS handles the security of the cloud, you know, the 123 00:06:03.720 --> 00:06:07.279 physical data centers, the hypervisors, the network cables. 124 00:06:07.000 --> 00:06:08.439 While you handle the security and the. 125 00:06:08.360 --> 00:06:14.160 Cloud precisely, your firewall configurations, your OS patches, your customer 126 00:06:14.240 --> 00:06:17.839 data encryption. The further up the stack you move from 127 00:06:17.839 --> 00:06:21.600 IAS to pious to sauce, the more responsibility you offload 128 00:06:21.600 --> 00:06:22.399 to AWS. 129 00:06:22.800 --> 00:06:25.800 So instead of looking at isolated textbook examples of how 130 00:06:25.839 --> 00:06:28.240 these services work, let's look at the life cycle of 131 00:06:28.279 --> 00:06:30.720 a modern business. Using the case studies from the. 132 00:06:30.680 --> 00:06:32.319 Text let's weave them together. 133 00:06:32.439 --> 00:06:34.480 Yeah, we'll start at the genesis of a company with 134 00:06:34.560 --> 00:06:39.240 Alexa the startup engineer. Her entire operating philosophy is Murphy's law. 135 00:06:39.399 --> 00:06:42.360 Anything that can go wrong will go wrong, which. 136 00:06:42.120 --> 00:06:46.360 Is the exact right mindset for the cloud. Alexa assumes 137 00:06:46.480 --> 00:06:52.279 virtual servers will fail because well, eventually, underlying hardware always fails, Right, 138 00:06:52.360 --> 00:06:56.240 so she designs a fault tolerant, stateless architecture. Instead of 139 00:06:56.279 --> 00:07:00.000 putting all her application logic on one massive server, she uses 140 00:07:00.199 --> 00:07:01.600 a load balancer. 141 00:07:01.399 --> 00:07:04.720 And mechanically, a load balancer is constantly running health checks. Right, 142 00:07:04.800 --> 00:07:07.160 it's pinging the servers every few seconds. 143 00:07:06.800 --> 00:07:10.199 Exactly, It's actively pinging her fleet of virtual servers. If 144 00:07:10.199 --> 00:07:12.759 a server stops responding to the health check, the load 145 00:07:12.759 --> 00:07:15.279 balancer automatically stops routing user traffic to it. 146 00:07:15.600 --> 00:07:19.199 But Alexa takes it a step further. She deploys redundant 147 00:07:19.360 --> 00:07:22.680 virtual servers across multiple availability zones. 148 00:07:22.800 --> 00:07:24.879 Yes, the ass. 149 00:07:24.480 --> 00:07:28.759 Let's clarify availability zones, because that's crucial. An availability zone 150 00:07:28.800 --> 00:07:31.439 isn't just like a different rack in a server room, No, 151 00:07:31.680 --> 00:07:35.360 not at all. It's a completely distinct physical facility with 152 00:07:35.439 --> 00:07:39.839 its own independent power grid, cooling system, and network connectivity, 153 00:07:40.240 --> 00:07:42.319 usually located miles away from the others. 154 00:07:42.519 --> 00:07:45.000 Right. So if a literal lightning strike takes out an 155 00:07:45.120 --> 00:07:48.480 entire data center, Alexa's startup doesn't go offline. 156 00:07:48.600 --> 00:07:51.839 The load balancer instantly detects the failure and routes all 157 00:07:51.920 --> 00:07:55.680 traffic to the healthy virtual servers in the other availability zone. 158 00:07:55.720 --> 00:07:59.160 She has enterprise grade disaster recovery built in from day 159 00:07:59.199 --> 00:08:01.680 one without buying a single piece of hardware. 160 00:08:01.720 --> 00:08:04.920 Okay, so Alexa startup survives and grows. Now it evolves 161 00:08:04.920 --> 00:08:07.639 into the second stage of our business life cycle, represented 162 00:08:07.680 --> 00:08:08.360 by John the. 163 00:08:08.360 --> 00:08:09.800 Cioh the webshop. 164 00:08:09.920 --> 00:08:13.519 Yeah, he runs a massive high traffic webshop. Traffic is 165 00:08:13.560 --> 00:08:16.639 exploding and his compute costs are starting to rise. His 166 00:08:16.759 --> 00:08:19.920 problem is that he's treating all his web traffic the same, which. 167 00:08:19.759 --> 00:08:23.720 Is incredibly inefficient. When a user loads Jones webshop, they 168 00:08:23.720 --> 00:08:27.160 are requesting dynamic content like querying the database for a 169 00:08:27.199 --> 00:08:30.680 specific user's shopping cart, right, But they're also requesting static 170 00:08:30.720 --> 00:08:34.799 content like the company logo or high resolution product images. 171 00:08:35.440 --> 00:08:39.200 John realizes he shouldn't be using expensive compute instances to 172 00:08:39.279 --> 00:08:43.080 repeatedly serve the exact same static JPEG image, Right. 173 00:08:43.120 --> 00:08:45.519 Why make a virtual server work hard to deliver a 174 00:08:45.559 --> 00:08:46.440 picture of a shoe? 175 00:08:46.519 --> 00:08:49.879 Exactly? Yeah, So John decouples his architecture. He points all 176 00:08:49.919 --> 00:08:53.559 the static content to a CDN, a content delivery network. 177 00:08:53.159 --> 00:08:55.399 And this is what the mechanics get really elegant. A 178 00:08:55.440 --> 00:08:59.559 CDN uses edge locations. So if John's primary servers are 179 00:08:59.600 --> 00:09:03.000 in Forgi, but a user in Tokyo requests the. 180 00:09:02.960 --> 00:09:06.159 Web page, the DNS resolution doesn't send that user all 181 00:09:06.159 --> 00:09:07.639 the way across the Pacific Ocean. 182 00:09:07.679 --> 00:09:10.440 No, the CDN cashes a copy of that image on 183 00:09:10.480 --> 00:09:12.320 a physical server located in Tokyo. 184 00:09:12.399 --> 00:09:15.919 The user in Tokyo gets the image delivered locally in milliseconds, 185 00:09:16.080 --> 00:09:18.000 which drastically reduces latency. 186 00:09:18.360 --> 00:09:21.600 But more importantly for John's wallet, that request never reaches 187 00:09:21.639 --> 00:09:23.200 his primary servers in Virginia. 188 00:09:23.399 --> 00:09:27.840 He is completely offloaded massive amounts of network traffic and 189 00:09:27.919 --> 00:09:33.000 compute load, making his infrastructure drastically cheaper and faster at 190 00:09:33.039 --> 00:09:34.200 the same time brilliant. 191 00:09:34.799 --> 00:09:37.360 So the web shop scales globally, which brings us to 192 00:09:37.399 --> 00:09:40.519 the third stage of our life cycle, the enterprise tier. 193 00:09:40.799 --> 00:09:44.080 This is Maureen the architect doing enterprise Java. Yet right, 194 00:09:44.159 --> 00:09:47.720 the company is now a massive global entity with highly 195 00:09:47.799 --> 00:09:52.320 sensitive regulated corporate data living in legacy on premises databases. 196 00:09:53.200 --> 00:09:56.559 Maureen needs to integrate this with AWS. But here is 197 00:09:56.600 --> 00:09:59.000 where I genuinely have a hard time. If I am 198 00:09:59.039 --> 00:10:03.440 Maureen dealing with highly sensitive corporate data like proprietary trade 199 00:10:03.440 --> 00:10:06.519 secrets or financial data. Why on Earth would I take 200 00:10:06.559 --> 00:10:08.799 that data out of my physical vault and put it 201 00:10:08.840 --> 00:10:09.799 onto a public. 202 00:10:09.519 --> 00:10:11.679 Cloud right where it's sitting on the same hardware as 203 00:10:11.720 --> 00:10:12.639 a million other companies. 204 00:10:12.679 --> 00:10:13.919 Exactly why would you do that? 205 00:10:14.399 --> 00:10:17.080 It is the single most common fear for enterprise architects, 206 00:10:17.120 --> 00:10:19.159 and it brings us back to the power of virtualization 207 00:10:19.240 --> 00:10:22.919 and software defined networking. Maureen doesn't just throw her data 208 00:10:23.000 --> 00:10:26.440 onto the public Internet. She creates a VPC, a virtual 209 00:10:26.519 --> 00:10:27.240 private cloud. 210 00:10:27.399 --> 00:10:29.200 How does that actually guarantee isolation? 211 00:10:29.320 --> 00:10:32.759 Though a VPC allows Maureene to carve out a logically 212 00:10:32.759 --> 00:10:36.679 isolated section of the AWS cloud, she defines her own 213 00:10:36.720 --> 00:10:41.159 IP address range, creates private subnets, and configures route tables. 214 00:10:41.519 --> 00:10:43.720 Okay, but how does it connect back to her office. 215 00:10:43.840 --> 00:10:46.519 The traffic between her on premises data center and her 216 00:10:46.519 --> 00:10:51.039 AWSVPC doesn't travel over the open Internet. It travels through 217 00:10:51.080 --> 00:10:53.960 a cryptographically secured IPSECVPN tunnel. 218 00:10:54.080 --> 00:10:54.720 Oh wow. 219 00:10:55.120 --> 00:10:57.919 Or if she wants to bypass the Internet entirely, she 220 00:10:58.000 --> 00:11:01.159 can use AWS direct Connect to lay a dedicated physical 221 00:11:01.200 --> 00:11:03.960 fiber optic line straight from her data center to the 222 00:11:03.960 --> 00:11:05.120 AWS facility. 223 00:11:05.240 --> 00:11:08.039 So even though she is technically on shared physical infrastructure. 224 00:11:08.399 --> 00:11:11.639 The software defined networking rules make it mathematically impossible for 225 00:11:11.679 --> 00:11:15.360 another AWS customer to access her network packing exactly. 226 00:11:14.919 --> 00:11:17.039 And beyond the logical isolation, you have to look at 227 00:11:17.080 --> 00:11:20.600 the physical and operational security. The text notes that AWS 228 00:11:20.679 --> 00:11:24.080 is compliant with incredibly stringent security frameworks. 229 00:11:23.679 --> 00:11:27.200 Like FedRAMP and DODCSM for the US military right YEP. 230 00:11:27.240 --> 00:11:30.639 And PCIDSS Level one for the global payment card industry. 231 00:11:31.039 --> 00:11:34.720 The reality is the physical security, the access controls, and 232 00:11:34.799 --> 00:11:38.639 the specialized security engineering at an AWI data center are 233 00:11:38.759 --> 00:11:42.200 vastly superior to what almost any independent corporation can afford 234 00:11:42.200 --> 00:11:44.399 to build for their own private server room. 235 00:11:44.759 --> 00:11:48.519 It's an economy of scale applied to security, which transitions 236 00:11:48.559 --> 00:11:51.519 perfectly to the final stage of our company's life cycle, 237 00:11:52.000 --> 00:11:54.480 long term compliance and archiving. 238 00:11:54.039 --> 00:11:56.600 Which brings us to Greg, the IT manager at the 239 00:11:56.639 --> 00:11:57.080 law firm. 240 00:11:57.200 --> 00:12:00.600 Yes, the law firm now has years of legal paperwork 241 00:12:00.639 --> 00:12:05.559 and strict archiving requirements. Greg is trying to replace an archaic, expensive, 242 00:12:05.679 --> 00:12:07.200 dual hardware backup system. 243 00:12:07.279 --> 00:12:09.679 Greg's old system was dangerous. He was backing up his 244 00:12:09.759 --> 00:12:12.759 primary data to a secondary server located in the same building. 245 00:12:12.639 --> 00:12:14.799 So a fire or a flood would destroy both the 246 00:12:14.840 --> 00:12:16.600 primary data and the backup right. 247 00:12:16.639 --> 00:12:19.360 But instead of buying an off site physical facility, Greg 248 00:12:19.399 --> 00:12:21.279 implements an AWS storage. 249 00:12:20.919 --> 00:12:25.759 Gateway, and the book uses this amazing term here, a 250 00:12:25.919 --> 00:12:30.480 virtual tape deck. I love this because it perfectly illustrates abstraction. 251 00:12:31.240 --> 00:12:35.519 We took this archaic physical constraint literally winding magnetic tape 252 00:12:35.559 --> 00:12:39.159 to store cold data, and turned it into infinite software. 253 00:12:39.480 --> 00:12:42.840 Mechanically, the Storage Gateway is a virtual appliance that Greg 254 00:12:42.840 --> 00:12:47.039 installs on his local network. It looks and acts exactly 255 00:12:47.120 --> 00:12:50.840 like a traditional physical storage array to his local servers, So. 256 00:12:50.720 --> 00:12:52.919 His local servers write data to it just like they 257 00:12:52.960 --> 00:12:54.080 always did, but the. 258 00:12:54.039 --> 00:12:59.879 Storage Gateway automatically and asynchronously replicates that data into AWS. 259 00:13:00.120 --> 00:13:04.559 Is highly durable object storage like Amazon S three or Glacier. 260 00:13:04.159 --> 00:13:07.080 So Greg gets to keep his frequently access files cased 261 00:13:07.120 --> 00:13:09.919 locally for instant access, but the massive bulk of his 262 00:13:10.000 --> 00:13:12.399 cold historical data is silently pushed to the. 263 00:13:12.320 --> 00:13:16.200 Cloud, giving him off site disaster recovery and infinite scalability 264 00:13:16.240 --> 00:13:18.799 without changing how his applications actually write the data. 265 00:13:18.840 --> 00:13:22.200 It seamlessly bridges the on premises world on the cloud exactly. 266 00:13:22.320 --> 00:13:24.799 So we've taken this company from a fault tolerant startup, 267 00:13:24.879 --> 00:13:27.480 scaled it with a CDN, secured it with a VPC, 268 00:13:28.080 --> 00:13:29.759 and archived it with a storage gateway. 269 00:13:29.799 --> 00:13:30.720 It's quite the journey. 270 00:13:30.879 --> 00:13:33.720 But like, how is this all managed? If you have 271 00:13:34.000 --> 00:13:38.720 hundreds of virtual servers, load balancers and gateways, human beings 272 00:13:38.720 --> 00:13:41.600 cannot manually configure all of this through a web console 273 00:13:41.639 --> 00:13:43.399 without making catastrophic errors. 274 00:13:43.519 --> 00:13:46.320 And here's where it gets really interesting. This is the 275 00:13:46.399 --> 00:13:50.120 true engine of innovation. Here in the preface, the authors 276 00:13:50.159 --> 00:13:54.000 Andreas and Michael Whittig talk about their experience migrating the 277 00:13:54.159 --> 00:13:57.879 entire IT infrastructure of a German bank to AWS. 278 00:13:57.960 --> 00:14:00.759 They were the first to do it in Germany right first. 279 00:14:00.720 --> 00:14:03.159 And the biggest takeaway wasn't just where the servers lived. 280 00:14:03.440 --> 00:14:06.879 It was a profound shift in operational culture. It shifted 281 00:14:06.919 --> 00:14:10.240 them to micro services and enabled the core DevOps principle 282 00:14:10.360 --> 00:14:11.440 you build it, you run it. 283 00:14:11.600 --> 00:14:14.159 Because the developers are no longer tossing their code over 284 00:14:14.200 --> 00:14:17.480 a literal wall to a separate IT operations team, right. 285 00:14:18.039 --> 00:14:21.639 They are managing the infrastructure themselves through a concept called 286 00:14:21.679 --> 00:14:24.519 infrastructure as code or IAC. 287 00:14:25.000 --> 00:14:28.519 This is the holy grail of cloud computing. Infrastructure as 288 00:14:28.600 --> 00:14:31.360 code means you stop manually clicking buttons. 289 00:14:31.679 --> 00:14:35.200 You write a blueprint using Jason or Yamel templates in 290 00:14:35.240 --> 00:14:40.480 a service like AWS CloudFormation that explicitly declares exactly what 291 00:14:40.559 --> 00:14:41.960 your infrastructure should look like. 292 00:14:42.120 --> 00:14:45.200 You decline that you need a VPC, two load balancers, 293 00:14:45.200 --> 00:14:48.759 and a database. You execute that text file, and the 294 00:14:48.799 --> 00:14:53.559 AWS orchestration engine automatically provisions the entire environment in minutes. 295 00:14:53.720 --> 00:14:56.919 And the mechanical beauty of ISIC is idempotency. 296 00:14:57.399 --> 00:15:00.360 Let's explain idemptancy, because if I run that exact same 297 00:15:00.360 --> 00:15:03.720 script one hundred times, it doesn't create one hundred databases exactly. 298 00:15:03.799 --> 00:15:06.279 It simply checks the current state of the infrastructure against 299 00:15:06.320 --> 00:15:08.720 the declared state in your code and only makes the 300 00:15:08.799 --> 00:15:09.639 necessary changes. 301 00:15:09.840 --> 00:15:12.200 I can now version control my physical data center the 302 00:15:12.240 --> 00:15:14.919 exact same way I version control my software. I can 303 00:15:15.000 --> 00:15:17.759 roll back a firewall change by just reverting a commit. 304 00:15:17.799 --> 00:15:19.919 And get what fascinating here is when you think about 305 00:15:19.919 --> 00:15:23.240 the physical reality underlying it. This level of automation is 306 00:15:23.240 --> 00:15:26.759 what enables the staggering scale of AWS. By the time 307 00:15:26.759 --> 00:15:28.759 the data in this book was published in twenty fourteen, 308 00:15:28.919 --> 00:15:32.759 AWS was operating one point four million servers globally. 309 00:15:32.799 --> 00:15:34.039 That is just insane. 310 00:15:34.080 --> 00:15:35.919 They're releasing new features weekly. 311 00:15:35.879 --> 00:15:37.720 Which brings us all the way back to the hook 312 00:15:37.720 --> 00:15:41.240 of this deep dive, dropping prices forty two times between 313 00:15:41.240 --> 00:15:44.159 two thousand and eight and twenty fourteen. If you are 314 00:15:44.200 --> 00:15:47.600 operating at the scale of one point four million servers, 315 00:15:47.960 --> 00:15:51.240 you fundamentally break traditional supply and demand economics. 316 00:15:51.279 --> 00:15:54.480 You do because AWS is buying hardware at a scale 317 00:15:54.600 --> 00:15:57.159 no other company own earth can match. They dictate the 318 00:15:57.159 --> 00:16:01.639 supply chain. Yeah, they build highly optimized custom hardware. They 319 00:16:01.679 --> 00:16:05.039 squeeze every drop of inefficiency out of their data centers, 320 00:16:05.559 --> 00:16:08.679 and instead of just pocketing the margin, their business model 321 00:16:08.720 --> 00:16:11.559 is to pass those massive economies of scale back to 322 00:16:11.600 --> 00:16:13.720 the customer in the form of price cuts. 323 00:16:13.639 --> 00:16:16.799 Which drives more customers to the platform, which increases their 324 00:16:16.799 --> 00:16:21.320 scale even further. It is a relentless compounding flywheel. 325 00:16:20.759 --> 00:16:21.240 It really is. 326 00:16:21.519 --> 00:16:23.320 So what does this all mean. Let's look at how 327 00:16:23.320 --> 00:16:26.240 that flywheel impacts the wallet of the end user, the 328 00:16:26.320 --> 00:16:28.360 economics of elasticity. 329 00:16:27.799 --> 00:16:28.840 Right, the paper use model. 330 00:16:29.080 --> 00:16:31.399 The book uses an electric bill analogy, which is med 331 00:16:31.720 --> 00:16:33.840 but you know it's also highly accessible for anyone just 332 00:16:33.919 --> 00:16:36.200 wanting to learn. There's the AWS free tier. 333 00:16:36.639 --> 00:16:38.720 Oh yeah, seven hundred and fifty hours of EC two, 334 00:16:39.080 --> 00:16:42.519 seven hundred and fifty hours of load balancer, five GBS 335 00:16:42.519 --> 00:16:45.879 three storage, a twenty GB database, all free for the 336 00:16:45.919 --> 00:16:46.399 first year. 337 00:16:46.600 --> 00:16:49.000 Incredible, But I want to look at the actual math 338 00:16:49.080 --> 00:16:51.720 for growing business. Let's go back to John's webshop. 339 00:16:51.799 --> 00:16:52.799 Okay, John's webshop. 340 00:16:52.919 --> 00:16:56.360 The text gives us a very precise breakdown. In January, 341 00:16:56.519 --> 00:16:59.840 John gets one hundred thousand visitors and his AWS bill 342 00:16:59.919 --> 00:17:02.799 is one hundred and forty two dollars and thirty seven cents. 343 00:17:03.600 --> 00:17:06.759 In February, a marketing campaign goes viral and his traffic 344 00:17:06.839 --> 00:17:10.400 explodes to five hundred thousand visitors. Wow, okay, that is 345 00:17:10.440 --> 00:17:13.359 a five x increase in traffic, but his bill only 346 00:17:13.400 --> 00:17:15.319 goes up to five hundred and thirty eight dollars and 347 00:17:15.400 --> 00:17:18.079 nine cents, which is just a three point seven x increase. 348 00:17:18.799 --> 00:17:21.960 Why isn't the cost scaling linearly with the traffic. 349 00:17:22.039 --> 00:17:25.519 It comes down to decoupling fixed versus variable costs within 350 00:17:25.519 --> 00:17:28.960 his architecture. When traffic spiked, his dynamic computing needs scaled up, 351 00:17:29.240 --> 00:17:31.720 his load balancer spun up more easy two instances to 352 00:17:31.720 --> 00:17:35.519 handle the database queries, and his outbound network data transfer increase. 353 00:17:35.680 --> 00:17:37.160 Those are the variable costs right. 354 00:17:37.079 --> 00:17:39.599 But his static storage costs the gigabytes of space folding 355 00:17:39.599 --> 00:17:42.000 his product images and S three remained exactly the same. 356 00:17:42.200 --> 00:17:44.680 The size of the files didn't change, only the velocity 357 00:17:44.680 --> 00:17:46.079 at which they were accessed. 358 00:17:45.880 --> 00:17:48.720 So a massive portion of his baseline costs remained flat, 359 00:17:48.920 --> 00:17:51.160 while his revenue generating traffic whinentupled. 360 00:17:51.480 --> 00:17:55.279 That nonlinear scaling is the dream for any business. But 361 00:17:55.359 --> 00:17:59.119 the even bigger mechanic here is elasticity. Through auto scaling, 362 00:18:00.039 --> 00:18:01.960 one didn't have to call AWS and ask for more 363 00:18:02.000 --> 00:18:03.759 servers when the viral campaign hit No. 364 00:18:03.960 --> 00:18:07.240 His architecture dynamically reacted to the load. He sets a 365 00:18:07.279 --> 00:18:11.039 cloud watch alarm if his CPU utilization hits seventy percent, 366 00:18:11.400 --> 00:18:15.400 the auto scaling group automatically provisions another virtual server and 367 00:18:15.480 --> 00:18:17.119 attaches it to the load balancer. 368 00:18:17.319 --> 00:18:19.759 And crucially, when the viral spike dies down at three 369 00:18:19.839 --> 00:18:24.200 zero am, the alarm triggers in reverse. The system automatically 370 00:18:24.279 --> 00:18:27.640 terminates those extra servers. He scales down to baseline. 371 00:18:27.720 --> 00:18:31.079 He stops paying for idle resources. If you extrapolate that 372 00:18:31.160 --> 00:18:34.119 across a global enterprise, the amount of wasted CAPEX that 373 00:18:34.200 --> 00:18:36.319 is suddenly reclaimed is astronomical. 374 00:18:36.400 --> 00:18:40.039 It changes how businesses fundamentally assess risk. You don't have 375 00:18:40.119 --> 00:18:42.279 to guess what your peak capacity will be on Black 376 00:18:42.319 --> 00:18:45.200 Friday in over provisioned hardware just in case. You just 377 00:18:45.279 --> 00:18:48.200 let the flexible capacity of the cloud absorb the impact. 378 00:18:48.359 --> 00:18:50.920 So let's pull all of this together. We have journeyed 379 00:18:50.920 --> 00:18:54.400 from the physical, rigid constraints of legacy data centers, where 380 00:18:54.599 --> 00:18:59.640 racking servers and guessing capacities stickled innovation, to a radically elastic, 381 00:18:59.759 --> 00:19:01.319 squere defined ecosystem. 382 00:19:01.480 --> 00:19:05.160 We watched a startup engineer build for inevitable failure. 383 00:19:05.279 --> 00:19:08.960 We watched the CIO leverage edgeenodes to drastically drop costs. 384 00:19:09.079 --> 00:19:13.039 We saw an enterprise architect carve out cryptographically secure networks 385 00:19:13.079 --> 00:19:14.119 on public hardware. 386 00:19:14.160 --> 00:19:18.079 And we saw how infrastructure as code fundamentally changes the 387 00:19:18.119 --> 00:19:19.839 discipline of it operations. 388 00:19:19.920 --> 00:19:22.039 And when you step back and look at the synthesis 389 00:19:22.079 --> 00:19:25.640 of all these mechanisms, the virtualization, the global edge networks, 390 00:19:25.920 --> 00:19:30.079 the automated provisioning, you realize that infrastructure is no longer 391 00:19:30.119 --> 00:19:33.960 a physical constraint. It is a programmable utility. 392 00:19:33.640 --> 00:19:37.119 Which leaves us with a truly staggering philosophical question. 393 00:19:37.319 --> 00:19:37.640 What's that? 394 00:19:37.839 --> 00:19:41.160 Well, think about it. If a massive globally redundant corporate 395 00:19:41.240 --> 00:19:44.839 IT network, complete with firewalls, load balancers, database clusters, and 396 00:19:44.880 --> 00:19:48.039 secure subnets, is no longer made of steel cabinets and 397 00:19:48.160 --> 00:19:51.240 copper wires, but is literally just a text file of 398 00:19:51.279 --> 00:19:55.359 declarative code sitting in a GIT repository. What does that 399 00:19:55.440 --> 00:19:57.640 mean for the traditional concept of a company. 400 00:19:58.319 --> 00:20:01.720 It dissolves the physical boundaries. If you can provision a 401 00:20:01.759 --> 00:20:04.799