WEBVTT 00:00:00.110 --> 00:00:02.450 So if you've started looking into cloud computing 00:00:02.450 --> 00:00:04.370 lately, you probably know that feeling right 00:00:04.370 --> 00:00:08.070 just this Absolute flood of jargon hitting you. 00:00:08.070 --> 00:00:13.630 Oh, yeah, I asked Paris Oz BPC C2 It feels less 00:00:13.630 --> 00:00:16.149 like technology and more like trying to learn 00:00:16.149 --> 00:00:18.370 a completely new language. Honestly, it really 00:00:18.370 --> 00:00:21.210 does It's a it's easy to feel pretty overwhelmed 00:00:21.210 --> 00:00:23.510 before you even get to what it all means But 00:00:23.510 --> 00:00:25.489 you know the thing we really want to unpack today 00:00:25.489 --> 00:00:28.289 is that? underneath all that cloud computing, 00:00:28.489 --> 00:00:32.030 it's built on just a few pretty powerful, straightforward 00:00:32.030 --> 00:00:34.829 ideas. So our mission here is to kind of strip 00:00:34.829 --> 00:00:37.850 away that noise, use some clear analogies, and 00:00:37.850 --> 00:00:40.390 really build a solid foundation for you. Exactly. 00:00:40.770 --> 00:00:43.770 Think of this as the shortcut to getting informed. 00:00:44.549 --> 00:00:46.390 Because by the end of this chat, you will just 00:00:46.390 --> 00:00:47.929 know what the cloud is, but hopefully you'll 00:00:47.929 --> 00:00:53.100 really grasp the core reasons. economic, technical, 00:00:53.259 --> 00:00:55.700 why it's become just this massive force in tech 00:00:55.700 --> 00:00:57.979 today. Yeah, the why is key. So let's get into 00:00:57.979 --> 00:01:00.020 it, maybe starting with the huge shift, the big 00:01:00.020 --> 00:01:02.340 change in how IT budgets even work. Okay, where 00:01:02.340 --> 00:01:04.920 do we start? The old way. Yeah, got to look back 00:01:04.920 --> 00:01:07.700 first. To really get the cloud, you need to remember 00:01:07.700 --> 00:01:12.069 the world of on -premises infrastructure. You 00:01:12.069 --> 00:01:13.930 know how things worked just a couple of decades 00:01:13.930 --> 00:01:16.670 ago? Right. If you wanted to launch, say, a new 00:01:16.670 --> 00:01:19.129 website or app, you had months of work ahead 00:01:19.129 --> 00:01:21.909 of you, a huge list of things to do before you 00:01:21.909 --> 00:01:24.750 even thought about writing cloud. You were basically 00:01:24.750 --> 00:01:29.730 a full -time capacity planner. Yeah. And a guesser, 00:01:29.769 --> 00:01:32.609 really. You had to predict, like six months out, 00:01:33.170 --> 00:01:35.170 how many people would visit your site. And that 00:01:35.170 --> 00:01:38.340 guess, it was loaded with risk. Seriously, best 00:01:38.340 --> 00:01:40.500 too low, your site crashes, the minute you get 00:01:40.500 --> 00:01:43.239 popular, boom, lost sales, lost trust. But guess 00:01:43.239 --> 00:01:45.760 too high. Well, you've just spent a ton of money, 00:01:45.780 --> 00:01:47.939 capital on servers that are just gonna sit there, 00:01:48.000 --> 00:01:50.299 maybe doing nothing 90 % of the time. Yeah, and 00:01:50.299 --> 00:01:52.099 that wasn't small change either. We're talking 00:01:52.099 --> 00:01:56.560 massive upfront capital expenditure, CapEx, buying 00:01:56.560 --> 00:01:59.019 physical servers, networking gear, cooling systems. 00:01:59.879 --> 00:02:02.219 Actual physical stuff. Physical assets, exactly. 00:02:02.540 --> 00:02:04.659 Then you waited maybe weeks, maybe months for 00:02:04.659 --> 00:02:07.760 delivery. Then you needed a special room, a data 00:02:07.760 --> 00:02:11.099 center with power, security. The whole setup. 00:02:11.340 --> 00:02:13.879 Right. You were spending all your energy on what 00:02:13.879 --> 00:02:17.240 we now call, and this phrase is important, undifferentiated 00:02:17.240 --> 00:02:19.539 heavy lifting. OK, break that down. It means 00:02:19.539 --> 00:02:22.280 all the work -racking servers, stacking them, 00:02:22.439 --> 00:02:25.539 replacing drives when they fail, physical security, 00:02:26.240 --> 00:02:28.120 managing the network stuff that doesn't actually 00:02:28.120 --> 00:02:30.259 make your products special or different from 00:02:30.259 --> 00:02:32.599 anyone else's. Like you said, building your own 00:02:32.599 --> 00:02:35.699 power plant just to turn the lights on. Pretty 00:02:35.699 --> 00:02:38.280 much. It's a huge drain on resources. Terrible 00:02:38.280 --> 00:02:40.659 use of time, yeah. It is. And that's precisely 00:02:40.659 --> 00:02:43.340 what the cloud wave fixes. So cloud computing, 00:02:43.620 --> 00:02:46.759 fundamentally, it's the on -demand delivery of 00:02:46.759 --> 00:02:50.020 IT resources. Things like virtual servers, storage, 00:02:50.500 --> 00:02:54.300 databases, even specialized AI tools. Exactly. 00:02:54.439 --> 00:02:56.680 All delivered over the internet. And here's the 00:02:56.680 --> 00:02:59.770 kicker. with pay as you go pricing. Okay, so 00:02:59.770 --> 00:03:01.509 that's the core economic shift you mentioned, 00:03:01.849 --> 00:03:05.110 moving from that huge upfront capex to operational 00:03:05.110 --> 00:03:07.430 expenditure, OPEX. Right. Instead of that big 00:03:07.430 --> 00:03:09.289 initial investment, your infrastructure becomes 00:03:09.289 --> 00:03:12.699 more like a utility bill. You pay as you go, 00:03:12.860 --> 00:03:15.360 only for what you actually use. The electrical 00:03:15.360 --> 00:03:17.439 grid analogy, that makes sense. It's perfect, 00:03:17.539 --> 00:03:19.280 isn't it? You don't build your own power plant. 00:03:19.639 --> 00:03:22.039 You just plug into the wall, pay the utility 00:03:22.039 --> 00:03:25.300 like AWS or Google Cloud or Azure only for the 00:03:25.300 --> 00:03:27.620 electricity you consume. You don't worry about 00:03:27.620 --> 00:03:29.699 how they make the power. You just use it. You 00:03:29.699 --> 00:03:32.400 just use it. And because these big providers 00:03:32.400 --> 00:03:35.240 run these enormous global networks of secure 00:03:35.240 --> 00:03:38.340 data centers, when you use a cloud service, you're 00:03:38.340 --> 00:03:42.620 basically renting A tiny slice. A tiny but crucially, 00:03:42.800 --> 00:03:45.099 logically isolated slice. Yes, very important. 00:03:45.199 --> 00:03:48.319 Logically isolated. But it means even a tiny 00:03:48.319 --> 00:03:50.919 startup gets access to the kind of power and 00:03:50.919 --> 00:03:54.479 scale that used to be only for massive corporations. 00:03:54.639 --> 00:03:57.099 That's huge. It really is. And that idea of renting 00:03:57.099 --> 00:03:59.060 is slow, so it leads us right into those service 00:03:59.060 --> 00:04:01.900 models. The menu, if you will. This is where 00:04:01.900 --> 00:04:04.280 IAS, PIAS, and SOS come in. Different levels 00:04:04.280 --> 00:04:06.580 of management. Right, the infamous acronyms. 00:04:06.699 --> 00:04:09.819 And to make sense of who manages what you, versus 00:04:09.819 --> 00:04:12.360 the provider, we need the pizza analogy, don't 00:04:12.360 --> 00:04:14.659 we? The pizza analogy is classic for a reason. 00:04:14.840 --> 00:04:16.720 Let's start with IAS Dryas. Infrastructure as 00:04:16.720 --> 00:04:19.680 a service. IAS gives you the basic building blocks. 00:04:20.220 --> 00:04:23.060 Think compute power, virtual servers networking, 00:04:23.540 --> 00:04:27.220 raw storage. But you, the customer, you manage 00:04:27.220 --> 00:04:29.839 the operating system, the runtime, your applications, 00:04:30.040 --> 00:04:33.310 your data. Everything on top. So in pizza terms, 00:04:33.589 --> 00:04:35.850 this is the take and bake option. Exactly. The 00:04:35.850 --> 00:04:37.470 pizza place gives you the kitchen, the oven, 00:04:37.610 --> 00:04:39.990 the dough, sauce, cheese, toppings, all the raw 00:04:39.990 --> 00:04:42.230 ingredients. You assemble it. You bake it. You 00:04:42.230 --> 00:04:44.550 decide exactly how it's done. Maximum control. 00:04:44.829 --> 00:04:47.069 Maximum control. Key examples here are things 00:04:47.069 --> 00:04:49.689 like Amazon EC2. Those are the virtual servers. 00:04:50.310 --> 00:04:53.430 And Amazon S3 for object storage, the fundamentals. 00:04:53.509 --> 00:04:56.069 Got it. So moving up a level. Moving up in abstraction. 00:04:56.290 --> 00:04:58.569 Yeah. We get to pick an S platform as a service. 00:04:58.689 --> 00:05:02.199 OK. Here, you, the user, you only really worry 00:05:02.199 --> 00:05:04.740 about your application code and your data. Deploying 00:05:04.740 --> 00:05:06.800 it, managing it. Ah, so this is like ordering 00:05:06.800 --> 00:05:09.000 pizza for delivery. Perfect analogy. You don't 00:05:09.000 --> 00:05:11.339 care about the kitchen, the oven, making the 00:05:11.339 --> 00:05:13.800 dough. A ready to eat pizza just shows up at 00:05:13.800 --> 00:05:16.199 your door. The cloud provider handles all the 00:05:16.199 --> 00:05:19.120 stuff underneath my app. The OS, patching, servers, 00:05:19.439 --> 00:05:22.180 storage. All of it. They manage the platform. 00:05:22.439 --> 00:05:25.839 Think about services like... AWS Elastic Beanstalk, 00:05:26.019 --> 00:05:28.199 which automatically handles capacity and load 00:05:28.199 --> 00:05:32.519 balancing, or Amazon RDS for managed databases. 00:05:32.680 --> 00:05:35.019 Oh, RDS is huge, right? Not having to manage 00:05:35.019 --> 00:05:37.379 database patching and backups yourself? Massive 00:05:37.379 --> 00:05:39.819 time saver for developers. Yeah. Let's them focus 00:05:39.819 --> 00:05:42.579 purely on the application, not database administration. 00:05:42.680 --> 00:05:44.899 OK, that sounds way easier. But what's the catch? 00:05:45.339 --> 00:05:47.319 If they manage the OS and runtime, does that 00:05:47.319 --> 00:05:49.660 mean I lose control if my app needs something 00:05:49.660 --> 00:05:52.420 really specific? like a custom OS setting or 00:05:52.420 --> 00:05:54.500 something. Ah, that's the core trade -off right 00:05:54.500 --> 00:05:56.819 there. You trade some of that fine -grain control 00:05:56.819 --> 00:05:59.639 for speed and convenience. Right. If you absolutely 00:05:59.639 --> 00:06:03.000 need deep OS access or very specific network 00:06:03.000 --> 00:06:06.399 configurations, you probably need IS. But if 00:06:06.399 --> 00:06:08.360 speed and easier maintenance are the priority, 00:06:08.660 --> 00:06:10.459 paid us is often the better choice. It really 00:06:10.459 --> 00:06:12.660 depends on the application. Makes sense. OK, 00:06:12.759 --> 00:06:15.860 and the last one, SaaS. SAAS, software as a service. 00:06:16.000 --> 00:06:17.819 This is the simplest one, really. It's a finished 00:06:17.819 --> 00:06:20.360 product, completely run and managed by the provider. 00:06:20.680 --> 00:06:23.079 So the pizza analogy here is just dining out 00:06:23.079 --> 00:06:25.620 at the restaurant. Exactly. You show up, order, 00:06:25.740 --> 00:06:28.180 eat. The restaurant handles everything, cooking, 00:06:28.420 --> 00:06:30.360 serving, cleaning up. You just use the software, 00:06:30.620 --> 00:06:32.480 usually through your web browser. So things like 00:06:32.480 --> 00:06:37.259 Gmail, Salesforce, Dropbox, Netflix, even Amazon's 00:06:37.259 --> 00:06:40.490 own work mail. All SAAS. Things you use every 00:06:40.490 --> 00:06:42.529 day without thinking much about the infrastructure 00:06:42.529 --> 00:06:45.449 behind them. Right. And understanding these three 00:06:45.449 --> 00:06:48.649 models, IS, PAS, SAS, is absolutely critical 00:06:48.649 --> 00:06:51.930 because it feeds directly into the shared responsibility 00:06:51.930 --> 00:06:54.410 model. Ah, yes. That's key for security, isn't 00:06:54.410 --> 00:06:56.930 it? Knowing exactly what the provider is responsible 00:06:56.930 --> 00:06:59.069 for. Like the physical security of their data 00:06:59.069 --> 00:07:01.389 centers? And what you are responsible for. Oh. 00:07:01.750 --> 00:07:03.750 Which could be anything from patching the OS 00:07:03.750 --> 00:07:07.240 in IS. all the way up to just managing who has 00:07:07.240 --> 00:07:09.759 access to the SaaS application, knowing that 00:07:09.759 --> 00:07:11.740 dividing line is crucial. Definitely. Okay, so 00:07:11.740 --> 00:07:13.699 we know the service types, but where does this 00:07:13.699 --> 00:07:16.779 cloud actually live? Let's talk deployment models. 00:07:16.920 --> 00:07:19.259 Good question. Most of what people mean when 00:07:19.259 --> 00:07:21.500 they just say the cloud is the public cloud. 00:07:21.680 --> 00:07:24.399 Right. Owned and run by a third party like AWS, 00:07:24.639 --> 00:07:27.980 Google, Azure. Exactly. Services delivered over 00:07:27.980 --> 00:07:30.660 the public internet, and it's a multi -tenant 00:07:30.660 --> 00:07:33.379 architecture. Okay, multi -tenant might sound 00:07:33.379 --> 00:07:35.970 a bit... Scary to some people. Does that mean 00:07:35.970 --> 00:07:39.009 my stuff is mixed in with others? It's a fair 00:07:39.009 --> 00:07:42.610 concern, but no, not really. While you are sharing 00:07:42.610 --> 00:07:44.509 the underlying physical hardware of the building, 00:07:44.949 --> 00:07:46.810 basically your data and applications are kept 00:07:46.810 --> 00:07:49.329 separate and secure through logical isolation. 00:07:49.709 --> 00:07:52.129 Ah, so the analogy is like living in a big, secure 00:07:52.129 --> 00:07:54.259 apartment building. That's a great way to put 00:07:54.259 --> 00:07:56.699 it. You share the foundation, maybe the security 00:07:56.699 --> 00:07:59.199 guards downstairs, but you have your own private 00:07:59.199 --> 00:08:01.199 apartment with your own locks. That locked apartment, 00:08:01.259 --> 00:08:03.660 that's your VPC. Your virtual private cloud. 00:08:03.879 --> 00:08:06.399 Okay, explain that bit. Right. The VPC is fundamental. 00:08:06.519 --> 00:08:09.540 It's how you carve out your own private, isolated 00:08:09.540 --> 00:08:12.600 section of the provider's network. Inside your 00:08:12.600 --> 00:08:16.040 VPC, you control your own IP addresses, subnets, 00:08:16.220 --> 00:08:19.100 route tables, firewalls. It's your virtual network 00:08:19.100 --> 00:08:22.120 boundary. Super important for security. Got it. 00:08:22.139 --> 00:08:24.040 So that's public cloud. What's the opposite? 00:08:24.120 --> 00:08:26.620 It'll be a private cloud, or what we used to 00:08:26.620 --> 00:08:28.579 just call on -premises infrastructure. Running 00:08:28.579 --> 00:08:31.579 your own data center, basically. Exactly. Operated 00:08:31.579 --> 00:08:35.059 purely for one single organization. You get maximum 00:08:35.059 --> 00:08:37.539 control, sure. And sometimes regulations require 00:08:37.539 --> 00:08:41.240 it. But you completely lose those huge economies 00:08:41.240 --> 00:08:43.200 of scale, the agility. You're back to owning 00:08:43.200 --> 00:08:46.259 the whole house again. Total control, but also 00:08:46.259 --> 00:08:48.799 total responsibility for fixing the roof and 00:08:48.799 --> 00:08:50.970 mowing the lawn. You got it, all the costs and 00:08:50.970 --> 00:08:53.950 maintenance fall on you. Okay, so public, private, 00:08:54.690 --> 00:08:56.950 is there something in between? There is, and 00:08:56.950 --> 00:08:59.529 it's very common, especially for larger companies, 00:09:00.389 --> 00:09:03.029 the hybrid cloud. Hybrid, makes sense, a mix. 00:09:03.090 --> 00:09:05.970 A mix, yeah. Signing a private cloud or your 00:09:05.970 --> 00:09:08.190 on -prem setup with one or more public cloud 00:09:08.190 --> 00:09:11.389 services, the key is having tools that let data 00:09:11.389 --> 00:09:13.950 and applications move between them somewhat easily. 00:09:14.169 --> 00:09:16.190 Why would you do that? Lots of reasons. Maybe 00:09:16.190 --> 00:09:18.429 disaster recovery, keeping backups in the public 00:09:18.429 --> 00:09:21.590 cloud. Or maybe to handle temporary spikes in 00:09:21.590 --> 00:09:23.669 traffic. You can burst out to the public cloud 00:09:23.669 --> 00:09:25.970 for extra capacity just when you need it without 00:09:25.970 --> 00:09:28.769 buying permanent servers for that peak. Ah, OK. 00:09:29.169 --> 00:09:31.070 Like owning your house but renting a storage 00:09:31.070 --> 00:09:32.850 unit for the holiday decorations you only need 00:09:32.850 --> 00:09:35.629 once a year. Perfect. Exactly like that. It gives 00:09:35.629 --> 00:09:38.129 you flexibility. Cool. Okay, so we've covered 00:09:38.129 --> 00:09:40.669 the what and the where. Now let's really nail 00:09:40.669 --> 00:09:44.269 the why. The six big advantages that drive cloud 00:09:44.269 --> 00:09:47.549 adoption. Yeah, these six points from AWS really 00:09:47.549 --> 00:09:50.049 summarize the business case, the revolution. 00:09:50.610 --> 00:09:52.929 First, and we've touched on this, trading capital 00:09:52.929 --> 00:09:56.309 expense for variable expense. CapEx for OPEX. 00:09:56.389 --> 00:09:59.330 Pay as you go. Freeze up cash. Hugely important. 00:09:59.769 --> 00:10:02.350 Second, you benefit from massive economies of 00:10:02.350 --> 00:10:06.149 scale. Because providers like AWS buy hardware 00:10:06.149 --> 00:10:08.690 in such incredible volumes. The Costco effect. 00:10:08.789 --> 00:10:11.529 The Costco effect. It means lower prices for 00:10:11.529 --> 00:10:14.629 everyone. Prices that no single company could 00:10:14.629 --> 00:10:16.909 ever achieve buying servers on their own. Makes 00:10:16.909 --> 00:10:19.669 sense. Third. Third, stop guessing capacity. 00:10:19.750 --> 00:10:21.669 Remember that nightmare? Oh, yeah. Eliminated 00:10:21.669 --> 00:10:23.710 by elasticity. You can get exactly the capacity 00:10:23.710 --> 00:10:25.909 you need when you need it. Scale up in minutes, 00:10:26.049 --> 00:10:28.330 scale down in minutes, traffic triples for an 00:10:28.330 --> 00:10:30.509 hour. Fine, your capacity triples for that hour, 00:10:30.509 --> 00:10:33.850 then shinks back. Automatically. That's incredibly 00:10:33.850 --> 00:10:37.830 powerful. Okay, fourth advantage. Fourth, increase 00:10:37.830 --> 00:10:40.389 speed and agility. This is huge for developers. 00:10:40.870 --> 00:10:43.750 Need a new server, a database, a machine learning 00:10:43.750 --> 00:10:45.870 environment. You can get it in minutes, not weeks 00:10:45.870 --> 00:10:48.549 or months. So experimenting becomes cheaper and 00:10:48.549 --> 00:10:51.149 faster. Massively cheaper and faster. Yeah. And 00:10:51.149 --> 00:10:53.970 this speed combined with elasticity leads to 00:10:53.970 --> 00:10:57.330 something really profound. The democratization 00:10:57.330 --> 00:10:59.870 of advanced technology. What do you mean by that? 00:10:59.950 --> 00:11:02.389 It means things that used to be incredibly expensive 00:11:02.389 --> 00:11:05.590 and complex, like massive clusters of GPUs for 00:11:05.590 --> 00:11:08.809 AI training, are now accessible to almost anyone, 00:11:08.990 --> 00:11:11.990 almost instantly. You can rent supercomputing 00:11:11.990 --> 00:11:14.309 power for like five minutes, run your job and 00:11:14.309 --> 00:11:18.039 turn it off, pay pennies. That ability to just 00:11:18.039 --> 00:11:20.279 try things with cutting edge hardware, that's 00:11:20.279 --> 00:11:22.379 transformed innovation in the last decade. Yeah, 00:11:22.480 --> 00:11:24.100 I can see that changes everything. Okay, fifth 00:11:24.100 --> 00:11:26.899 advantage. Fifth, stop spending money on that 00:11:26.899 --> 00:11:28.940 undifferentiated heavy lifting. We talked about 00:11:28.940 --> 00:11:31.679 that. Let your smart engineers focus on building 00:11:31.679 --> 00:11:33.500 your actual product, the thing that makes you 00:11:33.500 --> 00:11:36.100 money, not racking servers. Focus on what matters 00:11:36.100 --> 00:11:39.080 to the business. Makes sense. And the last one, 00:11:39.320 --> 00:11:43.840 sixth. Sixth, go global in minutes. Seriously, 00:11:44.259 --> 00:11:46.340 you want to launch your app for users in Europe 00:11:46.340 --> 00:11:49.600 and Asia. You can deploy it in AWS regions around 00:11:49.600 --> 00:11:52.659 the world with a few clicks. Reduce latency, 00:11:52.899 --> 00:11:55.460 give everyone a better experience. Doing that 00:11:55.460 --> 00:11:58.980 the old way. Months of work, millions of dollars, 00:11:59.299 --> 00:12:02.629 now. Minutes. Wow, okay, that's... That's a compelling 00:12:02.629 --> 00:12:06.049 list. Yeah. Economics, scale, elasticity, speed, 00:12:06.450 --> 00:12:09.350 focus, global reach. A combination that's pretty 00:12:09.350 --> 00:12:11.169 much unstoppable, really. All right, let's tie 00:12:11.169 --> 00:12:13.029 this all together. Let's use that startup example 00:12:13.029 --> 00:12:14.950 you mentioned, Photoverse, the photo sharing 00:12:14.950 --> 00:12:17.750 app. OK, great idea. So Photoverse, old way, 00:12:17.830 --> 00:12:20.350 they'd need, what, tens, hundreds of thousands 00:12:20.350 --> 00:12:23.730 in seed funding just for hard work. Easily. Months 00:12:23.730 --> 00:12:26.529 setting it up, and then that constant fear, crash 00:12:26.529 --> 00:12:28.850 if you succeed, stuck with useless gear if you 00:12:28.850 --> 00:12:32.200 flop, high risk. Very high risk. Now, the AWS 00:12:32.200 --> 00:12:34.559 way, the cloud way, it's total different. Okay, 00:12:34.779 --> 00:12:37.559 they launch a few virtual servers, Amazon EC2 00:12:37.559 --> 00:12:40.659 instances, that's IAS, to run their web application 00:12:40.659 --> 00:12:43.639 code. Simple. For storing potentially billions 00:12:43.639 --> 00:12:47.100 of user photos, they use an object storage service, 00:12:47.360 --> 00:12:52.600 like Amazon S3. Also, IAS. Super durable, incredibly 00:12:52.600 --> 00:12:54.870 cheap. per gigabyte. And the database. Yeah. 00:12:55.009 --> 00:12:56.590 They don't want to manage that themselves, right? 00:12:56.750 --> 00:12:59.090 Definitely not. So they use a managed database 00:12:59.090 --> 00:13:03.330 service like Amazon RDS. That's Pay S. AWS handles 00:13:03.330 --> 00:13:05.549 the backups, the patching, the headaches. They 00:13:05.549 --> 00:13:08.350 just use the database. Nice. And what about handling 00:13:08.350 --> 00:13:10.950 unexpected traffic spikes, like if a photo goes 00:13:10.950 --> 00:13:14.159 viral? Ah, elasticity comes to the rescue. They 00:13:14.159 --> 00:13:16.419 set up auto -scaling, it automatically watches 00:13:16.419 --> 00:13:19.179 the traffic, adds more EC2 servers when needed, 00:13:19.679 --> 00:13:22.320 remove them when things quiet down. So the capacity 00:13:22.320 --> 00:13:25.440 problem is just handled? Handled. Automatically 00:13:25.440 --> 00:13:27.639 and elastically. Okay, so let's sum up the result 00:13:27.639 --> 00:13:30.259 for Photoverse using the cloud. Zero dollars 00:13:30.259 --> 00:13:33.799 in upfront hardware costs. Zero. 100 % of their 00:13:33.799 --> 00:13:35.639 team's effort goes into building the app, not 00:13:35.639 --> 00:13:38.019 the infrastructure. They get instant elasticity, 00:13:38.460 --> 00:13:40.720 much lower business risk, and they can scale 00:13:40.720 --> 00:13:43.440 globally basically overnight if needed. That 00:13:43.440 --> 00:13:45.220 really paints the picture. It's just a fundamentally 00:13:45.220 --> 00:13:48.059 different, more agile way to build and run technology. 00:13:48.620 --> 00:13:50.799 It absolutely is. So maybe we can leave folks 00:13:50.799 --> 00:13:54.000 with this thought to chew on. If companies don't 00:13:54.000 --> 00:13:56.419 need that massive upfront capex anymore, and 00:13:56.419 --> 00:13:59.799 if they can instantly access the world's most 00:13:59.799 --> 00:14:03.519 powerful specialized hardware affordably, what 00:14:03.519 --> 00:14:06.259 does that really do to the barriers for innovation, 00:14:06.700 --> 00:14:09.759 for competition? Yeah, what major roadblocks 00:14:09.759 --> 00:14:13.320 for developers, for entrepreneurs have just been 00:14:13.320 --> 00:14:15.820 vaporized by this shift? Exactly. What becomes 00:14:15.820 --> 00:14:18.980 possible now that wasn't before? That's a powerful 00:14:18.980 --> 00:14:21.240 question. And maybe for you listening, think 00:14:21.240 --> 00:14:23.340 about the sauce apps you use constantly streaming 00:14:23.340 --> 00:14:26.159 documents, whatever. Just try to picture the 00:14:26.159 --> 00:14:28.320 incredible infrastructure layer underneath managed 00:14:28.320 --> 00:14:31.080 by the provider and think about that shared responsibility 00:14:31.080 --> 00:14:33.480 line. Where does their job end and yours begin? 00:14:33.820 --> 00:14:35.940 It's a useful exercise. Well, thanks for joining 00:14:35.940 --> 00:14:37.799 us as we've tried to unpack some of these cloud 00:14:37.799 --> 00:14:39.580 fundamentals today. Yeah, I hope this was helpful. 00:14:39.779 --> 00:14:40.360 We'll catch you next time.