Cloud Computing Explained: The Most Important Concepts To Know

in this video we're going to be talking about some of the most important cloud computing Concepts that you need to know about this video is great if you're a beginner to cloud computing looking to enter the industry or if you're already familiar with it and just looking for a refresher on some of the main Concepts then this video is going to be perfect for you so let's get started right away and first concept that we're going to be talking about is scaling so when we say scaling what we're generally referring to is application scaling so

say for example you develop an app and like this is a chart that shows the request rate over time and in the beginning like your app basically has no traffic and a lot of apps these days tend to like go viral maybe there's uh some kind of blog post or it gets featured on some news Outlet or something like that and they can very quickly explode so their traffic basically looks like a curve like this right and the problem with this is that a lot of applications aren't really meant to handle this rapid increase in

traffic from an influx of users and typically what happens is that you see like errors on the web page or the application just stops working um so this is something that cloud computing can help with quite a bit in fact it's one of the main benefits of using cloud computing because it allows us to scale rather seamlessly so in terms of the scaling concept there's two kind of subtopics within scaling there's what's called vertical scaling vertical scaling and then there is horizontal scaling right these are the two methods that we use to scale up our

application to handle an increase in traffic let's talk about vertical first because it's kind of the traditional approach before cloud computing really existed although you can still vertically scale your application within Cloud providers these days so what I mean by vertical scaling is imagine that you have a machine that's hosting your application and what we used to do in the past is when we had a a rapid increase in traffic to our application kind of like what we were talking about right here what we would do is try to scale this machine upwards right so

we would add more CPU maybe add more cores we would add more memory we would add more disc space you know there's a lot of different um kind of Dimensions that you can scale on even Network through put uh is another one so we would basically just scale this instance up uh as much as we could and if you ever like tried to buy computer parts before you've probably noticed that you know when when you try to buy a more powerful CPU or more memory and add it to a machine like talking about a single

stick in terms of memory here what you probably notice is that when you buy 16 GB of memory for example it costs like some amount say it's $100 right but when you buy 32 gabes of memory right in a single stick it doesn't necessarily cost $200 which is double 16 it may cost like $225 right and the same kind of thing applies right if if you keep on kind of doing this if you buy a 64 gigabyte stick it wouldn't necessarily cost double of 225 it may cost more it may cost like5 or $600 right

so what I'm trying to say here is that as you vertically scale up your application you end up getting diminishing returns in terms of cost so this is actually one of the the downfalls of using vertical scaling right this is a negative of vertical scaling cost is a problem right because you get diminishing returns and these um machines can quickly become very very expensive it's also a problem in terms of your application stability right if this instance let's call this stability stability if this single instance that you scaled up you know suddenly becomes unavailable there's

some like kind of problem with your application on this instance then your entire application pretty much goes down right um so this is kind of the main problem with vertical scaling cost becomes an issue and stability or availability of your application uh becomes questionable and now this is where horizontal scaling comes in because it solves uh both of these problems so horizontal scaling uses a very different approach whereas vertical you're you're kind of adding a more beefy machine or you're beefing up your machine machine to handle an increase in traffic horizontal uses a different mental

model different Paradigm if you will and instead of adding more resources to a single machine its mental model is why don't we just clone our application and host it on multiple other machines right so have smaller machines that typically cost less uh as a really really large machine but just have a whole bunch of them and so if you think about this right if you have an application now and you have 1 2 3 four five machines if one of these machines Mach ends up going down like maybe there's a problem with this machine or

there's a problem with this machine these other instances that are still here 1 2 and four still have the ability to serve incoming traffic from your users so your stability of your application is greatly improved also in terms of cost as we saw you can buy a lot cheaper machines right so you can go for these a lot of 16 gbyte memory sticks if we're just talking about memory for example and you know stack them on each machine and the total amount of memory that you have across each machine will be a lot cheaper than

if you have just one machine with like you know 64 GB where it costs $600 so the benefit here is that you get more stability so Plus in terms of stability and you get potentially lower cost right um and lower cost so these are the advantages of going with horizontal scaling in fact this is the most kind of popular approach that you know cloud computing makes very very easy um and so my next topic is actually closely related to horizontal scaling right and this topic is called load balancing I'm just going to keep this diagram

here um because it's convenient for what we just talked about um and let me just erase a little bit of the arrows so I don't uh confuse you sorry this is a new app that I'm drawing with these days um so I'm still learning it okay now load balancing what does this refer to now we saw that you know in the vertical scaling example if you have a single host and this is Trivial right how you distribute load to your application it's just going to a single host or a single machine uh but now on

the right hand side here since you have multiple machines how do you send traffic to each of the corresponding machines right how do you monitor whether or not these machines are healthy and how do you know whether or not um you know if a request comes in you should send traffic to it this is what load balancing is all about and what it essentially is is it's a layer that sits in front of your application right and it has a DNS or an IP address that's associated with a load balancer and when a request comes

in it essentially distributes the traffic to one of the available hosts that are in this kind of virtual Network so in the example that we have here if R request comes into the load balancer it may pick uh number one in this case right because it's currently available or it may pick number two similarly it would not pick number three because it's unavailable right uh or it could pick number four and what this essentially allows you to do is it allows your application to Route traffic to the available instances and there's a whole bunch of

different algorithms that you can pick from in terms of selecting which instance you want to direct your traffic to uh there's things called around Robin where basically you just kind of go through each of them like one two four in this case just cuz you know three and five are down and then you do one two and four again so one two and four you're basically just um iterating through each of them over and over again there's other more adaptive and intelligent methods that allow you to select which machine doesn't have as many connections as

the other so say your first instance has like 10 connections your second instance has 20 your third instance over here has 30 then your traffic would be directed to the one with the least number of connections you can also use other methods like utilization of resources on the machine so say you're at like 99% uh CPU utilization on the first machine uh but on the second maybe you're at 50 and then on the thirdd you're you're maybe at like 20 then the request can be configured to go to the machine with the lowest amount of

utilization uh so there's a whole bunch of different methods that you can use to distribute load to your different uh instances in your application but this is the key idea of load balancing right it's a way uh when combined with horizontally scaled application to direct traffic to the different instances that are hosting your application so that's the idea with load balancing now the next one I want to talk about is kind of similar to this but I'm actually going to redraw it because I'm running out of real estate here here uh this one is called

autoscaling and let me just make a little bit of room at the bottom um okay this looks good okay so this one is autoscaling auto scaling and also very closely related to horizontal scaling uh but this is really where you get a lot of power in cloud computing applications so we saw with this horizontally scaled example you know you have multiple different machines here just going to redraw this really briefly um say you initially set this to be you know three different machines that you want to provision for your application right and as we were

kind of drawing up over here in the top left you know your application can grow very very rapidly based on you know maybe someone post something or I don't know someone um or maybe you get funding for your application or maybe just on launch day and uh kind of your traffic explodes for some reason now initially when you set up autoscaling you may say Okay three instances looks good for me right this is something reasonable that I can start with but how do you seamlessly deal with this situation up here right like we don't want

to necessarily be monitoring our graphs and say oh shoot like we got an increase in traffic let's add a fourth instance over here and let's add a fifth instance over here and the reverse also applies right when traffic kind of goes from really really high and then drops down like this um then we want to maybe remove these instances right and this is what autoscaling is all about autoscaling is the concept where we can automatically add more instances or remove instances in response to fluctuating traffic or when the resources start to become exhausted in our

application okay and this is a very very powerful concept A lot of the different Cloud providers handle this automatically for you uh there's things like uh what are called autoscaling groups in in AWS where you essentially create a group of different instances that can live within it and then you set a metric to say you know when connections goes above some key value then add them another instance and when it goes below then remove an instance or you can do it based on CPU utilization there's a whole bunch of different metrics that you can hook

into to automatically add and remove instances so this is the key idea of autoscaling okay let's move on to the next topic now and this one is is similar but different enough that it warrants I think a a new screen here um this is serverless and this is VE a very popular topic these days and kind of a um how do I want to say this a little bit of contentious topic because it started with a certain definition and it kind of changed over time um there's been a lot of blog posts and articles about

like what serverless means these days it's kind of like a bit subjective uh but I can tell you what it originally meant and kind of what it's devolved into these days um so when we said serverless in the beginning actually serverless became a really popular concept with AWS Lambda um maybe I can just tell you the history of this and this will probably make more sense um and if you don't know about AWS Lambda it's a compute service it makes it so that if you want to you know host a web app with a backend

API uh or you want to like perform some uh write some scripts and then execute them in the cloud what you had to do in the past was you had to provision an instance what they call an ec2 instance which is like a virtual instance and then you know load your code onto here and then execute your code it's just a pain in the butt with um having to manage instance es because you know there's a lot of things you got to deal with in terms of setup and config they're all expensive so this became

a bit of a problem and what AWS Lambda did that kind of revolutionized this this mental model was that you know what most people don't necessarily want to worry about provisioning or uh setting up instances and then maintaining the security of them and all the networking configuration and that what people really just want to do is they want to write code right they want to write code and they don't necessarily care where it's executed what instance it's on or what machine they just want to write their code and run it and so what Lambda did

is they they kind of took advantage of this model and they created what are called Lambda functions and Lambda functions it's kind of this like abstract thing that exists in Lambda world but essentially um you write your code over here you load it onto a function which is just like a thing that you create in the AWS console in this case and then you don't know about like the underlying ec2 machines that are executing your code it could be one machine right there could be a single machine here it could be multiple right could be

like two or three for example but from your perspective like you're just executing your code and you can hook it up to like rest apis or applications and then the Lambda service is kind of Distributing your traffic to the underlying ec2 instances on your behalf and then kind of scaling them up or down depending on your usage so this is what the idea of server lless originally was right it was the idea where we can create this this function as we used to call it which is this Center entity here and then we don't have

any concept any idea of the underlying infrastructure that's beneath it uh and we just essentially worry about writing our code and our business logic in our application so this was kind of how things were for a really long time since Lambda got started but this has kind of changed recently and it's it hasn't been like officially declared by ews in this case but it has been changed in the way that they're using the serverless term to describe a whole bunch of new feat features that they're releasing across different AWS services and let's take an example

for of this there's a service called AWS let me get a different color um open search right open search which is elastic search if you've ever used that um now with open search what you used to have to do when you when you set this up is that you had to set up like different instances within it you have to say Okay I want three Master nodes uh that are going to be within this and then I want maybe like two data nodes or whatever Master nodes and data nod are just you know terminology that's

specific to open search uh but you had to like set this up and then configure it and then um open search would hook into it and then this is kind of like how you would originally do it and this is not considered server list by the way this was kind of like the traditional model so what AWS decided to do was kind of adapt this model slightly and what they essentially said is that okay we're going to make it so that you don't necessarily have to worry about any of the underlying instances we're just going

to create a version of open search where it kind of scales automatically to rapidly Inc increasing traffic and when your traffic drops down similarly right now the problem with this is that like this would be great if under normal circumstances um you only paid for your usage you only paid for like number of executions for example but that's not the the model that they use like paper use is how they they do it in the AWS Lambda world and also Dynamo DB which is another kind of serverless service so with open search what they did

is like they're calling this feature serverless but what you still have to do is pay for the number of underlying instances right so say uh when we're over here right in this this graph you'd have like two instances right maybe these instances cost like $100 per month so you'd pay like 200 bucks um pro rated based on the amount of time and then when your application scaled up maybe this will go up to six instances so now you're paying $600 per month pro rated for how long um you're using this amount of infrastructure and so

this is what they're calling serverless these days which is kind of conf confusing for most people and not something I'm a particular fan of but this is what serverless is kind of starting to become so when you hear the term just be careful with it because some people use it in the old context some people use it in the new context especially if you like look at AWS announcements they like to call like oh everything is serverless these days uh but that's not necessarily the case like AWS Lambda is a good example of how serverless

should work um but this whole kind of open search model where you're kind of paying for the underlying infrastructure but you don't have to manage it is not really serverless at least in my mind okay um let's move on now the next topic that I'd like to talk about is something called event driven architecture and sometimes you'll hear this as uh its acronym which is Eda or venten architecture but in order to understand this let's talk about how we used to kind of communicate with other services or applications in the past so say you had

an application maybe it's like an order application maybe it's like Amazon right so Amazon Amazon okay and customers are placing orders right they're placing orders all the time and one of the things that you need to do when you place an order if you're your Amazon is that first you need to charge the customer right so you charge the customer and maybe in order to do that you need to call some like credit card service or something like that credit card service right then the next thing that you need to do is maybe you need

to call some like Warehouse service warehouse to kind of see if there's anything in stock or just confirm it there something in stock and then kind of Kickstart the process to um you know start picking the order and packing it and all the things that they do um so this is kind of like a fulfillment or FC uh service and then maybe you also have some like fraud and analytics kind of concept right so fraud where people are placing orders maybe it's with like stolen credit cards or something so if you start the process of

placing the order you may want to interrupt it at certain point in time if there's some kind of you know fraud Vector that's being abused here right so like there's fraud that could potentially be an issue so what we used to do in the past um before this whole concept of event driven architecture ever it came up was you know an an order would come in and then we would synchronously call the different things in order right we would first try to to charge the customer okay if that return success great now we would call

the FC service and say like okay start picking and pack in the order and then maybe the third thing that we would do or maybe this is the first thing we can kind of reverse the order if we want is we would call the fraud detection service this is what's called the request response model so the problem with this approach is that it creates what we call tight coupling between your dependencies tight coupling it means that the service that's over here right which is kind of the um the thing that Brokers the the the orchest

or orchestrates rather the coordination across these different uh underly Services needs to know about these different components right it needs to know how to charge a customer it needs to know how to initiate a fulfillment for this order it needs to know that like this fraud application exists and is listening for events right so this is like the request response model and part of the problem with it is that like you have this tight coupling concept and this is where event driven architecture starts to come into play so let me draw this out for you

in the context of event driven architectures to show you as a comparison what this looks like okay so we're going to use the same kind of concept right so we still have our Amazon application down here and it works in a very similar way actually now I'm thinking about the diagram is going to look like very very similar uh but essentially the idea is that instead of Amazon uh the Amazon application or like the order taking application synchronously calling the credit card application and the FC application and the fraud application essentially what it does is

it sends a message to a notification engine okay and it basically will say okay or customer placed an order so it's going to send a notification to this piece of infrastructure right usually in the context of AWS there's two services that allow you to do this the first one is called NS and the second one is called event Bridge or EB for sure and essentially what this service will do or what Amazon will do when it sends this message to this service is be like okay here are the details for this thing so it's order

ID uh 123 it costs you know $100 and you know a whole bunch of other metadata here's the customer ID here's all the different things that are related to it and it's kind of like an envelope so you can think of it as like an envelope that uh contains the payload for the order that the customer just placed and what happens is that using this model um the SNS or eventbridge service are able to distribute a copy of this message to any number of consumers that are currently subscribed to this piece of infrastructure this envelope

so to speak which is either an SNS topic or an event Bridge event bus in the context of AWS and so what this allows you to do and so to complete this picture you know talking about a previous example a subscriber of this data would be the credit card Card application another subscriber would be the FC application another subscriber would be the fraud detection application an N number of applications that you can add right there's no there's no limit to the number of like outbound arrows we call this Fanning out because you can fan out

uh and add more dependencies as you wish now the great part about using this uh kind of Paradigm is that the service that kind of created the events right which was the order taking service in this initial case no longer needs to know about any of the downstream use cases that are related to it right it no longer needs to care about the fact that like oh there's an FC processing service there's a credit card service there's a fraud service or whatever service may come um so this is it allows for decoupling right decoupling which

is the main advantage of using event driven architectures now you may ask yourself okay doesn't this introduce problems like if you place an order right and the credit card processing like we fire a notification off credit card processing system gets it that succeeds um the FC processing system gets it that succeeds within the fraud detection system is like oh shoot like this is not a um a valid order it's actually fraud what happens now don't we kind of need to somehow resolve this issue like we need to indicate to the FC service like hey stop

what you're doing credit card system go issue a refund for this or whatever it may be this is true it's actually like one of the complexities of using Avent Ren architectures but there are ways around it so what you can do is like distribute a a new message from the order taking service that says hey this order was cancelled and then redistribute that to your downstreams and then they can start like reversing what they did previously okay um so this is a vent driven architecture an extremely extremely powerful Paradigm in contrast with request response and

it's something that you see more and more of in Cloud providers and cloud computing in general because it allows you to seamlessly add new dependencies uh without the producer of the messages having to worry about it uh there's two other terms that I just wanted to briefly touch on that are important in this event driven AR architecture World um the first one is called publisher it's a publisher and the publisher is like Amazon in this case right it's the person that is producing the message and the other one is subscriber right subscriber and subscribers are

are these categories of people over here these categories of services these are the consumers of your of your data or your information and typically you hear this in short form it's often called Pub sub uh for short um so that's what what these terms mean if you ever hear them in the context of event driven architecture okay so that's it for this topic let's move on now and talk about our next one and again making some more space for me here okay for this one we're going to talk about container orchestration okay and just as

a as a very brief recap I'm pretty sure like 90% of you probably know what containers are but just to briefly cover this for people that don't containers are are kind of like an isolated environment that you can create like on your home machine for example that has all your dependencies in it so it has your code it has your dependencies it has all your configuration you can bundle all this stuff up on your home machine and then Port this anywhere you can host this application on the cloud you can host this on your friend's

computer you can host this on um maybe your work infrastructure this is the idea with containers and they're they're very convenient they make it so that you know if you ever had the works on my machine problem you tried to run something and it works perfect on yours but on your co-workers it's like something's broken it's like the same code you know something's wrong here obviously um this solves that issue and what container orchestration is well maybe it's useful to talk about um the problem of not having cont container orchestration so a lot of AWS

providers offer you the ability to deploy your containers right so ec2 is a good service um that allows you to do this uh so ec2 is basically like rent a machine from AWS and so what you can do as a user is you can you know take your your container from home and then deploy it onto your ec2 instance and now like it starts receiving traffic and everything's going great right so this is like a very simple trivial way that you can deploy your containers onto the cloud now the problem starts to to creep up

is uh what if like this container starts to fill right maybe it's got like some problem with it maybe it's uh over overused or it's its usage is really really high or it's running out of memory in order to perform its function or maybe it just shuts down for some inexplicable reason you'd have to set up some process to monitor this and then kind of restart it over time or you'd have to detect this and do it manually which is a pain in the butt something you don't necessarily want to deal with even the ability

to deploy code like to deploy code onto an ec2 machine for a container is kind of complicated and non-trivial so what container orchestration allows you to do is basically simplify this process greatly there's certain services in AWS uh ECS is the most popular one there's also KS for kubernetes elastic uh container service and elastic kubernetes service and essentially what these two Services they're two flavors of the of solving the same problem what they allow you to do is say like okay you have a piece you have a container that you develop and you want to

host it on many different machines so you can easily say I want to deploy this onto three different machines uh for the same code and you can also provision a uh load balancer for it to start Distributing traffic which we talked about previously uh you can also Define health checks to kind of check on these instances and replace them if there's ever an outage uh you can automatically get Behavior like if this instance ever goes down then just remove it from the group so traffic will only start flowing to the remaining remaining instances there's also

monitoring and availability functions that you can use as part of these different Services they basically make it a lot easier to deploy container-based applications either for ad hoc one-time jobs or for services that are going to persist for a long period of time so container orchestration services have become very very popular because it makes your life easier um but this is essentially the key idea of them and what you need to know about at a high level okay let's move on now to the second concept this one is in terms of Storage storage and you

may think that this is a simple thing to talk about but it's actually like not that simple there's like a lot of different uh terms or it's kind of an over loaded terms so there's like a couple underlying concept for storage that I think we should talk about uh so the first flavor of storage when working with with uh cloud computing is just a general object storage right General object storage and object storage refers to things like could be media files right could be media files like um I don't know uh MP4s for example could

be uh audio files or or videos or whatever um I don't know what the what the formats AV eyes is that still a thing I'm not even sure anymore uh could be Json objects right so like structur Json objects could be like CSV files that you want to store uh could be like a whole bunch of other things could be just like blobs or bite stream data that you'd like to to store as an object uh on the cloud um so this is what we generally refer to as object storage it's just kind of like

a general purpose Dumping Ground where you can put miscellaneous uh types of media and then access it later on within an application right so this is one format of storage that is very very popular within cloud computing because you know there's a lot of use cases where you need to store media and images and Json config files and CSV data and things like this before we used to host these on like on a volume on a dis on that's attached to an application but uh the Advent of object storage kind of trivializes this problem and

makes this so that you don't need to worry about like where you're hosting this thing it's in the cloud so you can access it pretty much any time uh this is a good seg way into like the second category of storage which is like what we call block storage um and block storage essentially are like volumes right so volumes uh and a lot of cloud providers make this easy where these volumes can automatically scale up or down uh depending on how much how much like resources you need as part of it uh so if you

have like a hard drive for example that's what I mean when I say volumes by the way um maybe you need like a lot of data on your hard drive for some job but not for a long period of time maybe it's for some like machine learning processing job and you quickly will want to release that piece of uh infrastructure once you're done right uh so Cloud providers support autoscaling on your volumes uh they also support if you have like a bunch of different instances over here and you want to attach this volume to this

instance and also this instance and also this instance and then like it's the same data but it's shared across these different instances that's also supported uh so this is what we refer to generally as block storage right um just just erase this so I can clear up some space uh block storage and then the third one is probably kind of like the most popular which is databases right databases and there's a whole bunch of different types of databases on cloud providers there's like the traditional relational databases relational um there's no SQL databases which are databases

that um kind of typically use like a document model well this is kind of a category of databases it's not a particular type um but let me just make some room while I'm at it too um you know you can have things like mongod DB in here you can have things like uh Dynamo DB you can have things like open search which is what we talked about previously or elastic search uh you can have a variety of graph databases that are considered um no SQL so this is like a large category and this is the

third category um nosql is a large category that has a lot of different types of databases that you can use kind of the traditional one this is where you would use like SQL um so things like postr things like MySQL things like Microsoft SQL server or Oracle these would fall under um relational databases uh there's also kind of like a subcategory of this which isn't necessarily a database but the blind the lines are getting blurry these days uh which is like cache Solutions cach cach is being um temporary data right this is data that kind

of usually sits in memory and it's for applications that need it very very regularly but don't want to incur the cost of calling a a database and having to update the database um so there's a bunch of different cache solutions that are available as well whether or not it's considered a database that's kind of a a subjective discussion or subjective uh decision uh but it's something to be aware of that it exists okay let's move on to the next topic now and for this one I want to talk about very briefly availability and this one

is actually very closely related to the topic that's coming after this so when we say availability what we really mean is how often is our application up and running at at any given point in time right sometimes you see terms or numbers from AWS or gcp or aour like you see numbers like this this application has 99.99999 N9 n you know it goes on and on percentage of availability and what this essentially translates to like there's a mathematical formula where you can actually calculate this um what it translates to is on average per year or

month or time frame whatever you're looking at like some period of time of outages so maybe it's like 99.9 translates to 5 minutes of the year you can expect to have an outage in a service or an application and so this is what availability generally refers to now how do you increase availability how do you make it so your application is more prone to be available and more resilient to outages well it combines a lot of the different concepts that we already talked about right there's this concept of horizontal Al scaling right where we added

multiple different instances right and now we have a load balancer and then we can distribute traffic to them we already kind of learned about this and you know we know now that if this instance goes down doesn't really matter things can carry on as usual we can direct traffic over here over here over here this is one uh aspect of availability there's other things that you can do as well such as distribute these instances to different Geographic data centers um they call these availability zones availability T zones and these are like physically separate data centers

right so you can think of them as like there's a separate building building one building two uh and actually as I'm saying this I'm realizing that they're not necessarily always separate buildings this is kind of something that AWS hides from you it could be like a segregation in a building so like this can be considered building one and then two and then this could be three and four and what they do is that they guarant that there's separate power lines that go into each one um separate um internet lines SE basically separate everything that goes

into each one so they although they're the same building they're actually partitioned into separate groups um so this is another way that you can increase your availability for your application by hosting your application in these different availability zones right so maybe you put like you know this instance in this availability Zone uh this instance although it's down right now in this availability Zone this in instance in this one uh and this instance in this one right so this is one way that you can increase the availability of your application or your service okay so this

is cloud availability uh let's move on now to talk about kind of a related concept which is this concept of durability durability now durability is also a pretty simple one durability just essentially means is like when you store data on AWS like say you're storing like an MP3 file or something um doesn't really matter it could be something that's stored in a database too but let's just keep it simple and say we're storing a single file um what what AWS does on your behalf when you try to store it is that they store multiple copies

of it right so like there's copy one there's copy two there's copy three and and these copies aren't necessarily on the same machine or in the same data center or in the same country like they can be distributed all across the world and this is what we we typically call durability is our data safe from outages are we ever going to lose this data if we store it on ews right so say like worst case scenario this the data center that's hosting this goes down or maybe like literally the hard drive explodes like maybe this

thing goes nuclear and there's like a fire or something and you no longer have access to it it's gone right you still have other copies of it here uh so AWS would automatically recognize that this has happened and then maybe like provision and make another copy that goes onto a separate data center on a separate instance uh so this is this concept of durability like this could be useful for like uh data recovery or Disaster Recovery things like that so this is the concept of durability pretty simple to understand um okay the next one is

IAC which is a popular one also called infrastructure as code okay and infrastructure as code let's talk about the problem that it solves first before we actually get into it you can probably guess what it means by the name but let's just kind of chat about this briefly so in the old days uh before infrastructure as code was really popular and was really a thing like how would you provision let's say a database for example right you would log into the AWS console right you go to the the AWS console you would sign in you

go to like I don't know the mongodb or the Dynamo DB section of the console and you would like click a bunch of things you click like create table um then you would specify some settings right you would say okay this is my table name uh you may create some monitors that are as part of this you may start to like add data to it right so like add adding data um you maybe you come to add data uh maybe you come back to this later and modify the configuration there's a whole bunch of things

that you can do in the AWS console right with regards to a particular resource that you're trying to create so what are the problems with this right well problem number one is that it's easy to make a mistake so it's it's very easy to like fat finger something or oops I accidentally clicked the delete button whoopsies uh now my production application is down um so it's easy to make mistakes right another problem problem is that it's hard to replicate this setup if you need to deploy it to a new country or new geography so say

your application initially starts in North America and then you're like oh well my company is expanding and now we need to create this exact same table that I created 6 months ago with the same settings the same configuration the same everything but I need to go through the console and do this and it's going to take a long time so this is another problem with with having to do these things manually right and there's a whole bunch of other problems related to doing things manually but this these are kind of the main ones uh so

you can probably guess where I'm going with this infrastructure as code gen generally refers to like taking this configuration that you've done through the console and instead of doing it through the console you just write code right you write a a piece of code that you can specify all the different settings of this uh piece of infrastructure and then you can put this in Source control so you can put this in git uh you can have other people that are like reviewers to do code reviews to say like oh like Johnny is trying to add

a database or change a configuration is this a good thing should we do this or not think about how this would work in the previous world like someone could just be messing around in the console and doing stuff and you would not necessarily know um but essentially you define all this infrastructure through code and then you hand this code off to the different Cloud providers so Cloud uh providers and what they'll do is they'll read your piece of code and then go to the corresponding services and create that infrastructure as you specified right so you

can kind of think of this as like this template that you define and you create through code you hand it off to the cloud and they kind of go out to the separate services and make all this stuff for you this makes it a lot harder to make mistakes it's no longer like someone just doing stuff in the console it kind of has to go through code reviews and people looking at it you know assuming that you use the best practices um it's also very easy to replicate because now if you have this kind of

template that you just created um you can say oh I just want to add a new region right I want to like deploy this also in addition to to uh Us East one Us East one I also want to go to Europe right or EU West one or these different regions that exist and so it becomes very very easy to clone this stuff uh it also becomes very very easy to actually write this stuff once you actually get the hang of creating infrastructure as code it's very intuitive um a lot of them these days like

there's a declarative and an imperative version of this uh within AWS uh so there's cloud formation or CF cloud formation um this you you use a template language which is more declarative so you say exactly what you want uh and AWS will go out and create it for you and then there's another one which is called cdk Cloud development kit and with this one it's more like a programming language uh so you have access to things like for Loops if statements you can create conditions depending on what region you're in then you want to specify

some settings or depending on if you're in beta or production or Gamma or whatever it may be maybe you want to set up the infrastructure but with like a very low amount of resources so you don't incur crazy costs uh so things like cdk allow you to do this there's also uh third-party providers that aren't necessarily tied to a particular company so things like terraform um and terraform are um they actually allow you to use different Cloud providers using one programming language or using one solution uh so terraform can hook into aour uh can hook

into AWS it can hook into gcp uh this is why a lot of people like terraform yeah okay you guys can you'll see this great um gcp um so this is another popular solution as well however if you're using AWS I recommend cdk or cloud formation but cdk is definitely my number one choice um so this is uh infrastructure as code in general this is the the concept and the problem that it helps solve okay let's move on now to the last topic for discussion and for this one we're going to be talking about Cloud

networks Cloud Networks okay let's talk about a like traditional Network before we had Cloud networks uh just so I can show you a basis for comparison right um so in the old days when you had um a like a company that you joined what you would typically do is they would have a data center either a data center that they had physically in their building or they contracted it out to some company that would have their own data center let's go with the first example let's say like okay physically in the building we have this

like server room right and in this server room like we can put our instances in there right you know we can we can add all our stuff in here all our databases and everything and then we can create like subnets right we we can say okay these instances are going to host um application that's going to be outside world facing right so like people from the internet are going to be able to communicate with these instances in this application but these instances over here right these are are private so we're going to put these in

a private subnet you probably have things like databases uh things like sensitive data storage that would live over here right um so this is kind of like a traditional Network right and it usually revolves around these concepts of subnets right and then like security groups which you say like okay these different types of instances are allowed to communicate with other things um Social Security groups you would be able to say like okay this instance is allowed to talk to the database but an incoming request for example cannot go from the internet to the database right

you'd have rules that would specify that that is not allowed okay so this is is a a summary of the traditional model um so let's talk about Cloud networks and how this deviates right so Cloud networks don't really have this problem right well they have this problem but it's not really your problem in the sense there's AWS data centers right that exist and as we talked about like AWS data centers can exist like there could be many of them that you potentially integrate with right let's keep it simple and just say that there's one right

now but um you know when you create a a cloud Network so to speak this all exists within the context of AWS or gcp or zour or whatever right and essentially if you consider this like uh white square to be all of AWS there's many many different customers of AWS right there could be me which is like here it could be you there could be many different customers right and what a cloud Network allows you to do is it allows you to isolate yourselves from one another so maybe this is me right this is you

this is Jeff baser that has his own cloud Network this is I don't know um someone else right and what uh a cloud Network allows you to do is to isolate yourself so you can say okay I'm going to deploy my resources into my cloud Network right and you can deploy your resources into your Cloud Network also on ews but by default these things are not allowed to talk to each other so this is not allowed right unless you you specify you say the rules similarly these resources that you created are not allowed to receive

outbound traffic or inbound traffic excuse me from the internet right unless you say so right um so there's rules that you can specify on your resources that you deploy into your Cloud Network that basically determine what it's allowed to talk to within your Cloud Network and also outside of it right so you can say Okay um there's me and you maybe we're friends or you know we have a business relationship together um so we're going to connect our Cloud Network together and make it so that we can talk to one another right but I can

still have stuff in my network that you can't see right that's private to me and similarly you can have something in your network that I can't see that's private to you um so Cloud networks allow you to essentially isolate your resources within your cloud provider uh and it's an additional layer of security that you can rely on so that's it for the video if there's any Core Concepts for cloud computing you think I missed I would love to hear what you have to say in the comment section of the video and if you liked please

don't forget to like And subscribe and share the video with a friend uh if you enjoyed it and thanks so much for watching I'll see you in the next one