00:00 - 00:03

so in this video I want to give a little

00:01 - 00:05

progression of like how you

00:03 - 00:07

traditionally deploy an application and

00:05 - 00:09

how we've kind of reached a point where

00:07 - 00:10

we are now where we have like cdns that

00:09 - 00:12

are hosting all your static files we

00:10 - 00:15

have like Edge Computing we have

00:12 - 00:16

serverless Computing and stuff but let's

00:15 - 00:18

just take it a step back to like the

00:16 - 00:20

beginning of how do we deploy

00:18 - 00:22

traditional applications right so

00:20 - 00:24

traditionally you have a VM

00:22 - 00:27

and this could be like an ec2 instance

00:24 - 00:30

or a digital ocean droplet where you as

00:27 - 00:32

a developer or a system admin or

00:30 - 00:35

whatever you SSH into the box or you run

00:32 - 00:38

some type of like puppet scripts or

00:35 - 00:41

ansible scripts to basically install a

00:38 - 00:43

service so this is like your service I

00:41 - 00:45

could say it's Express JS since we're

00:43 - 00:46

kind of doing node on this channel right

00:45 - 00:49

so you have a VM and you want to

00:46 - 00:51

basically run your Express web API here

00:49 - 00:53

maybe you have some static files that

00:51 - 00:55

are hosted here but this is

00:53 - 00:57

traditionally how like you would kind of

00:55 - 00:58

run stuff

00:57 - 01:00

and there's a lot of people who actually

00:58 - 01:02

do this they actually deploy Services

01:00 - 01:05

manually and kind of you know keep them

01:02 - 01:06

operational what you can also do is the

01:05 - 01:08

vm's big enough you can actually put a

01:06 - 01:11

database here too right you could put a

01:08 - 01:14

DB but this is like very very

01:11 - 01:15

manual work and a lot of people do not

01:14 - 01:18

have the expertise to actually like

01:15 - 01:20

exercise into a machine set up postgres

01:18 - 01:23

manually set up their service manually

01:20 - 01:26

have the you know the devops chops to

01:23 - 01:28

basically set up a pm2

01:26 - 01:30

um service so you don't know what pm2 is

01:28 - 01:31

basically it's a script you can use or

01:30 - 01:33

tool you can use to basically

01:31 - 01:35

continuously refresh and restart your

01:33 - 01:37

service if it were to crash for whatever

01:35 - 01:38

reason sometimes Services run out of

01:37 - 01:41

memory sometimes I throw exceptions they

01:38 - 01:42

have to be restarted but doing all this

01:41 - 01:45

and then managing this database by hand

01:42 - 01:46

it takes expertise right A lot of people

01:45 - 01:48

don't have the time to learn all this

01:46 - 01:50

but this is kind of how like we were at

01:48 - 01:51

for the longest time and this works for

01:50 - 01:52

a lot of

01:51 - 01:54

small scale companies right this can

01:52 - 01:56

handle a lot of traffic especially if

01:54 - 01:58

you're using like AWS because you can

01:56 - 02:00

vertically scale you can start off with

01:58 - 02:03

like a nano and then you can go to like

02:00 - 02:05

a a micro I think I have these backwards

02:03 - 02:07

so like you could start with a nano and

02:05 - 02:08

see how that works and if that's not

02:07 - 02:10

enough memory you can go to micro and

02:08 - 02:12

then you go to small you can go to

02:10 - 02:14

medium you can go to a large and at some

02:12 - 02:16

point like you have a VM that has like

02:14 - 02:18

16 gigs of memory and can handle a

02:16 - 02:20

decent amount of traffic right but

02:18 - 02:22

there's an issue with vertically scaling

02:20 - 02:24

at some point you're going to need more

02:22 - 02:27

memory or you're going to need to be

02:24 - 02:28

able to handle more requests and this is

02:27 - 02:31

just not going to cut it right but again

02:28 - 02:33

if you're running a small little startup

02:31 - 02:34

company this I think will work pretty

02:33 - 02:36

well for the most part but again there's

02:34 - 02:38

a lot of costs hidden costs with like

02:36 - 02:40

managing the stuff yourself you don't

02:38 - 02:42

want to be sshing into a machine and

02:40 - 02:44

then also I would recommend like unless

02:42 - 02:45

you're working at a huge Enterprise you

02:44 - 02:46

don't want to be messing with puppet

02:45 - 02:48

chef and ansible like it's just a lot of

02:46 - 02:50

overhead to understand like how to set

02:48 - 02:52

up those orchestration tools on your

02:50 - 02:54

your cluster of VMS

02:52 - 02:55

so if that's out of the question for

02:54 - 02:57

like a beginner

02:55 - 02:58

what are the next steps well in terms of

02:57 - 03:00

scaling what you could do is you can

02:58 - 03:03

move the database

03:00 - 03:04

off into its own VM okay again we're

03:03 - 03:07

we're trying to show you the progression

03:04 - 03:09

of like okay let's split this out into

03:07 - 03:13

two VMS now so that my express service

03:09 - 03:15

is running on one VM and it communicates

03:13 - 03:18

with a database that is running on

03:15 - 03:19

another VM okay and again you can

03:18 - 03:21

vertically scale both of these

03:19 - 03:24

independently

03:21 - 03:26

okay so if your database has more needs

03:24 - 03:28

you scale it up if your service has more

03:26 - 03:29

needs you scale that up but again like I

03:28 - 03:31

said at some point with all this

03:29 - 03:33

vertical scaling you will hit a

03:31 - 03:35

threshold and you don't want to be

03:33 - 03:38

managing databases by hand so what we

03:35 - 03:41

typically do is we offload the database

03:38 - 03:42

to a third-party service so let's just

03:41 - 03:45

go ahead and put one here I'll just say

03:42 - 03:49

like we're using um Railway I've used

03:45 - 03:50

Railway a couple times on my service so

03:49 - 03:52

like basically you're saying I don't

03:50 - 03:54

want to manage this myself although this

03:52 - 03:56

is probably like one of the cheaper

03:54 - 03:58

options in terms of operational costs if

03:56 - 04:00

you know how to like manage and monitor

03:58 - 04:02

a database

04:00 - 04:04

but for most of us we don't want to have

04:02 - 04:07

to do that stuff right so what we do is

04:04 - 04:09

we offload that responsibility to a

04:07 - 04:12

service who has experts that know how to

04:09 - 04:13

run a postgres database they know how to

04:12 - 04:15

monitor it and they know how to do

04:13 - 04:17

security patches and updates on it right

04:15 - 04:18

so you're going to pay a little bit more

04:17 - 04:22

money

04:18 - 04:24

typically because you're paying someone

04:22 - 04:26

for their expertise to take care of

04:24 - 04:28

managing this thing and then like you

04:26 - 04:30

know Amazon has a RDS instance you can

04:28 - 04:32

use you can use like Planet scale you

04:30 - 04:34

can use uh uh what's what's the other

04:32 - 04:36

one called you could use like super bass

04:34 - 04:37

Super Bass or whatever but the idea is

04:36 - 04:39

like

04:37 - 04:41

this allows you to scale better because

04:39 - 04:43

again typically this thing has the

04:41 - 04:45

ability to vertically scale as well and

04:43 - 04:47

it's usually like a one click a button

04:45 - 04:50

in the service to just scale it up to

04:47 - 04:52

accept more traffic but also remember as

04:50 - 04:53

you scale up they end up charging more

04:52 - 04:55

money right so keep that in mind that

04:53 - 04:57

these Services they work great in the

04:55 - 04:59

beginning but as you get more traffic

04:57 - 05:01

and as you have more data needs you need

04:59 - 05:03

to keep track of how much they're going

05:01 - 05:05

to end up charging you based on your

05:03 - 05:06

usage so that's one thing you split the

05:05 - 05:07

database out and you scale that

05:06 - 05:09

separately so what about the service

05:07 - 05:11

right what if your service ends up

05:09 - 05:14

needing to need more computational power

05:11 - 05:16

okay so what you can end up doing is you

05:14 - 05:18

can copy and paste all this stuff let's

05:16 - 05:20

just group it and copy and paste it and

05:18 - 05:22

you could make different instances of it

05:20 - 05:23

okay so this is called horizontally

05:22 - 05:26

scaling

05:23 - 05:28

horizontal scaling

05:26 - 05:31

where you just create copies of the same

05:28 - 05:33

service and so that when a user needs to

05:31 - 05:34

access this let's just go ahead and put

05:33 - 05:38

a user here

05:34 - 05:40

he needs to basically just randomly pick

05:38 - 05:43

one of these things to do its request

05:40 - 05:45

right so when he loads a browser up he

05:43 - 05:47

needs to hit something in front of all

05:45 - 05:50

this this is usually called a load

05:47 - 05:51

balancer you can use like nginx if you

05:50 - 05:54

want to kind of like set this up the

05:51 - 05:55

manual way which again not a fan of but

05:54 - 05:57

I do I do just want to kind of talk

05:55 - 05:59

about it so like you have some context

05:57 - 06:00

of how this all works what is a load

05:59 - 06:02

balancer a load balancer is basically

06:00 - 06:04

sitting in between your services and

06:02 - 06:08

your user so that the user says I need

06:04 - 06:09

to connect to your app.com right and

06:08 - 06:11

what the load balancer says is okay well

06:09 - 06:13

I have two different services that are

06:11 - 06:15

running and what I'm going to do is I'm

06:13 - 06:18

going to randomly pick one

06:15 - 06:19

to basically for that traffic to one or

06:18 - 06:21

the other

06:19 - 06:23

there's different ways you can kind of

06:21 - 06:25

implement this forwarding you could do

06:23 - 06:29

like round robin I believe there's one

06:25 - 06:31

called like sticky sessions where based

06:29 - 06:32

on your IP it'll basically send you to

06:31 - 06:34

the same service every single time

06:32 - 06:37

there's a lot of different strategies

06:34 - 06:40

for Distributing the load but again the

06:37 - 06:43

purpose of the load balancer is to fan

06:40 - 06:45

out every request so that one server is

06:43 - 06:47

not overloaded with too many requests

06:45 - 06:49

you can keep the memory down and the CPU

06:47 - 06:51

down on these machines so as you get

06:49 - 06:54

more and more scale you need to

06:51 - 06:56

basically keep on adding these things to

06:54 - 06:59

this right you'd have to keep adding

06:56 - 07:00

more and more and more because in order

06:59 - 07:03

to handle the amount of traffic you need

07:00 - 07:05

you have to basically keep scaling up so

07:03 - 07:07

that brings us to basically services

07:05 - 07:10

that provide something called Auto

07:07 - 07:11

scaling groups okay so you've used like

07:10 - 07:14

kubernetes

07:11 - 07:17

or have you used um anything Amazon with

07:14 - 07:20

like ec2 or manage instances basically

07:17 - 07:22

what you do is you give it a definition

07:20 - 07:24

like this I'm going to say give it a

07:22 - 07:25

definition I'm going to go ahead and

07:24 - 07:27

just put like Auto scaling group I know

07:25 - 07:29

that's kind of like a convention that I

07:27 - 07:31

think Amazon uses a lot but basically

07:29 - 07:33

depending on where you're hosting your

07:31 - 07:36

service if you're using like um again

07:33 - 07:38

like kubernetes or I think fargate is

07:36 - 07:40

another one on Amazon you can use you

07:38 - 07:42

can set some numbers and I want to say

07:40 - 07:44

you know Min is one server

07:42 - 07:47

men of one server

07:44 - 07:49

and Max of five servers and what this

07:47 - 07:51

Auto scaling group basically does and

07:49 - 07:52

typically I think this also includes

07:51 - 07:53

your load balancer

07:52 - 07:55

um

07:53 - 07:56

you can kind of fact check me on this if

07:55 - 07:59

you want

07:56 - 08:00

but now you have basically abstracted

07:59 - 08:02

away the need to manage all that stuff

08:00 - 08:04

yourself and instead you're saying hey

08:02 - 08:06

Amazon you get you take care of this for

08:04 - 08:08

me you basically inspect the traffic of

08:06 - 08:11

my load balancer and if you notice that

08:08 - 08:14

like I'm getting a lot of traffic Amazon

08:11 - 08:16

and other services will basically spin

08:14 - 08:17

up another instance for you

08:16 - 08:20

and do all that routing for you

08:17 - 08:22

automatically so let's talk about um how

08:20 - 08:24

do you actually like split up your API

08:22 - 08:25

from your front end because right now we

08:24 - 08:27

have like both of them bundled together

08:25 - 08:28

like this is your API in your front end

08:27 - 08:30

all being hosted from the same service

08:28 - 08:33

like again if this was like you manually

08:30 - 08:35

hosting a next application it would be

08:33 - 08:37

hosting your UI and your API right but

08:35 - 08:39

at some point depending on the size of

08:37 - 08:42

the project and the scale in the team

08:39 - 08:46

you might actually want to deploy your

08:42 - 08:48

API as a separate Standalone service and

08:46 - 08:49

because apis typically end up having

08:48 - 08:51

different needs

08:49 - 08:53

um you might have more complexity you

08:51 - 08:55

might need more computation and the UI

08:53 - 08:57

might not have as many needs as well

08:55 - 08:58

right so like the UI could be really

08:57 - 09:00

simple

08:58 - 09:02

you might just need like one or two

09:00 - 09:05

servers in your auto scaling group but

09:02 - 09:07

the API let's say you do a lot of heavy

09:05 - 09:08

computation its Auto scaling group might

09:07 - 09:10

need to be a lot higher you might need

09:08 - 09:14

to say I need a Min of three servers and

09:10 - 09:16

a Max of 10 servers or you know

09:14 - 09:18

whatever and so the idea is you would

09:16 - 09:21

set this all up kind of separately and

09:18 - 09:23

deploy this separately you have probably

09:21 - 09:25

it could be in the same repo or a

09:23 - 09:28

different repo where when the user tries

09:25 - 09:32

to load the UI it's going to first fetch

09:28 - 09:34

the UI from this setup and then when the

09:32 - 09:36

user browser needs to fetch some data it

09:34 - 09:38

would basically hit this other load

09:36 - 09:40

balancer which should go over here

09:38 - 09:41

okay so just looking at this like you

09:40 - 09:44

can just tell the complexity is starting

09:41 - 09:45

to increase right this is not easy stuff

09:44 - 09:47

to figure out and it takes a lot of

09:45 - 09:48

expertise to like get good at it but

09:47 - 09:50

what we've seen at least with single

09:48 - 09:52

page applications is that hey you know

09:50 - 09:55

the UI doesn't really change that often

09:52 - 09:59

what we can actually do is we can deploy

09:55 - 10:01

our UI to a CDN so a CDN is basically a

09:59 - 10:04

way to take a bunch of static files

10:01 - 10:06

and let's just pretend this is like the

10:04 - 10:08

globe this is going to be a bad diagram

10:06 - 10:10

okay this is the globe let's just move

10:08 - 10:13

our database like back over here

10:10 - 10:15

like this let's just pretend our API is

10:13 - 10:17

connecting to this

10:15 - 10:19

okay

10:17 - 10:22

so this is like a CDN and this is like

10:19 - 10:24

my example of like a the globe right

10:22 - 10:26

let's just put the world I'll just put

10:24 - 10:28

regions here the CDN basically is a

10:26 - 10:29

network of different machines across the

10:28 - 10:31

globe

10:29 - 10:34

and every machine has its own like

10:31 - 10:36

caching system which is going to

10:34 - 10:39

basically take your UI and distribute it

10:36 - 10:40

to all of these different nodes now

10:39 - 10:42

typically there is something called An

10:40 - 10:44

Origin server

10:42 - 10:46

I'll just put like a square here and put

10:44 - 10:48

like origin and that could be like an S3

10:46 - 10:50

bucket which is holding your files so

10:48 - 10:55

like that's your compiled

10:50 - 10:57

HTML CSS and JS and the origin server

10:55 - 10:59

basically when a user makes a request to

10:57 - 11:01

your the CDN

10:59 - 11:02

there's some magic going on where

11:01 - 11:05

basically it's going to Route them to

11:02 - 11:08

the closest server based on geographical

11:05 - 11:09

location right so if I'm on if I'm in

11:08 - 11:11

Florida it's probably going to route me

11:09 - 11:13

to an East Coast node

11:11 - 11:15

and that node is basically going to

11:13 - 11:17

check hey do I have the files necessary

11:15 - 11:20

to host this UI if not I'm going to go

11:17 - 11:21

ahead and just make a request to this

11:20 - 11:23

origin server and I'm going to pull

11:21 - 11:25

those files over and then I'm going to

11:23 - 11:27

Cache them for some amount of time right

11:25 - 11:29

so this is how we basically scale up all

11:27 - 11:31

the static assets like all the images

11:29 - 11:34

all the front-end JavaScript the HTML

11:31 - 11:36

that stuff gets distributed to a CDN and

11:34 - 11:37

this stuff will live here for a certain

11:36 - 11:39

amount of time

11:37 - 11:42

based on whatever policies you have you

11:39 - 11:44

have set up so if the user decides to

11:42 - 11:46

hit this thing again this whole trip

11:44 - 11:48

here is basically not needed because the

11:46 - 11:50

files are already going to be cached so

11:48 - 11:53

that's the idea at least recently how

11:50 - 11:56

the front end has been kind of scaled up

11:53 - 11:57

and sped up we have a CDN which hosts

11:56 - 11:58

all the front-end files and I believe

11:57 - 12:01

that's how like versel and other

11:58 - 12:04

companies work they have like the same

12:01 - 12:05

concepts of your your static HTML now

12:04 - 12:07

what you can actually do as well if

12:05 - 12:11

you're doing like server-side rendering

12:07 - 12:13

is you can actually put your API behind

12:11 - 12:15

the CDN as well right so the user would

12:13 - 12:17

make a request to the CDN

12:15 - 12:19

the CDM will figure out what region you

12:17 - 12:21

need to hit and based on different

12:19 - 12:24

routing rules you could have a route

12:21 - 12:26

that goes to your API and again the same

12:24 - 12:28

concept is you can have different types

12:26 - 12:31

of um

12:28 - 12:32

cash policies where if your API request

12:31 - 12:34

returns some data you can have a cached

12:32 - 12:36

for five minutes on data that doesn't

12:34 - 12:37

change that often but again this is how

12:36 - 12:39

we get more and more into like how do we

12:37 - 12:41

how do we handle more traffic how do we

12:39 - 12:43

handle more scale and again it's we're

12:41 - 12:45

just trying to reduce the load on the

12:43 - 12:48

servers that we can handle more traffic

12:45 - 12:49

this has trade-offs caching always has

12:48 - 12:51

um trade-offs because sometimes we need

12:49 - 12:53

cache data it's going to be stale and

12:51 - 12:55

depending on the type of application

12:53 - 12:58

your users might need 100 live data

12:55 - 13:00

other times they can work off of cache

12:58 - 13:02

data so you have to kind of keep that in

13:00 - 13:04

mind and figure out those trade-offs

13:02 - 13:06

but that's how we scale up the front end

13:04 - 13:09

typically

13:06 - 13:11

we use a CDN and the back end this is

13:09 - 13:14

typically how we do it now we can take

13:11 - 13:16

this a step further because

13:14 - 13:19

even the database this is like a single

13:16 - 13:20

point of failure now right so we have to

13:19 - 13:23

be able to scale up the database and

13:20 - 13:25

what we typically end up doing are

13:23 - 13:27

Services end up doing for you is that

13:25 - 13:30

again kind of similar to the CDN they

13:27 - 13:32

will scale up your databases and

13:30 - 13:34

distribute them to various regions right

13:32 - 13:36

so for example you might have a primary

13:34 - 13:39

database here that's like in Us East one

13:36 - 13:42

but you may have replicas that are in

13:39 - 13:44

West one

13:42 - 13:46

or I don't know the European Union or

13:44 - 13:49

something and what happens is that all

13:46 - 13:52

of the rights typically need to go to

13:49 - 13:53

like a primary database and then once

13:52 - 13:56

you write to that database it

13:53 - 13:57

distributes that data to other servers

13:56 - 13:59

in different regions so depending on

13:57 - 14:01

where the user made the request from

13:59 - 14:03

your API can actually fetch data from

14:01 - 14:05

the closest region to you and kind of

14:03 - 14:07

speed that up as well

14:05 - 14:10

now this is not a simple concept either

14:07 - 14:11

right so there's a lot of services that

14:10 - 14:12

do this for you I believe playing that

14:11 - 14:14

scale will do this stuff for you out of

14:12 - 14:17

the box like RDS will do this Auto

14:14 - 14:18

scaling replica stuff out of the box

14:17 - 14:21

um you could use something like dynamodb

14:18 - 14:24

that kind of takes care of this type of

14:21 - 14:26

large-scale needs out of the box but

14:24 - 14:27

keep in mind that this stuff is not easy

14:26 - 14:29

to do

14:27 - 14:30

which is why you usually just end up

14:29 - 14:33

paying a service that takes care of this

14:30 - 14:34

if you need this type of scaling let's

14:33 - 14:37

progress this even more right now we're

14:34 - 14:38

just doing like hard-coded deployed

14:37 - 14:40

servers and again these could be like

14:38 - 14:42

Docker containers or these could all be

14:40 - 14:43

running on their own VMS

14:42 - 14:46

it doesn't really matter those those are

14:43 - 14:48

implementation details but a movement

14:46 - 14:50

that I think a lot of companies are

14:48 - 14:52

doing now is instead of having like your

14:50 - 14:55

Express server running on a dedicated

14:52 - 14:57

machine we're actually moving over to

14:55 - 14:59

serverless computations let's talk about

14:57 - 15:01

serverless so that's also another thing

14:59 - 15:03

that's like helping with scale where

15:01 - 15:05

instead of you having like multiple

15:03 - 15:08

Express applications

15:05 - 15:10

you know behind a load balancer you

15:08 - 15:12

actually have a function that function

15:10 - 15:15

is basically scaled up based on your

15:12 - 15:17

needs right so like Amazon has AWS

15:15 - 15:19

Lambda

15:17 - 15:21

um I'm sure Google has one I'm sure

15:19 - 15:23

Azure has one

15:21 - 15:24

but basically you have a function and

15:23 - 15:26

that thing's going to scale up based on

15:24 - 15:28

your data needs the cool thing about AWS

15:26 - 15:31

Lambda is that like these things can

15:28 - 15:33

scale up super easily like if you have a

15:31 - 15:34

a burst of traffic where you have like

15:33 - 15:36

thousands of requests that come in

15:34 - 15:38

you'll see your Lambda functions just

15:36 - 15:40

scale up like instantly and handle all

15:38 - 15:43

that load so instead of you having to

15:40 - 15:44

like wait for this Auto scaling stuff to

15:43 - 15:46

provision a VM

15:44 - 15:48

set up your service or if you're using

15:46 - 15:50

kubernetes provision a new container and

15:48 - 15:52

let that load

15:50 - 15:54

which takes a little bit of overhead

15:52 - 15:55

this stuff is like almost pretty

15:54 - 15:57

instantaneous right it takes like a

15:55 - 16:00

second or two seconds based on the cold

15:57 - 16:02

star so these land is coming up and that

16:00 - 16:04

is how you achieve another aspect of

16:02 - 16:06

scale right it's just Auto scaling all

16:04 - 16:08

of these functions and the cool thing

16:06 - 16:10

about this is that every function is

16:08 - 16:12

basically ran in isolation so the issue

16:10 - 16:14

I had before with like running an

16:12 - 16:16

Express server

16:14 - 16:18

if you have like 100 requests going to

16:16 - 16:20

the express server and it crashes you

16:18 - 16:22

basically have 100 people who just like

16:20 - 16:25

lost all of their their request data

16:22 - 16:28

versus on Lambda every function is

16:25 - 16:30

basically ran in isolation so if one

16:28 - 16:32

function throws an exception the other

16:30 - 16:33

100 will not crash because they're all

16:32 - 16:35

ran in isolation

16:33 - 16:37

in their own kind of like execution

16:35 - 16:39

context or whatever

16:37 - 16:41

so this is scaling on another level

16:39 - 16:43

which is also cool to understand we have

16:41 - 16:45

the CDN still for the front end stuff

16:43 - 16:48

that could potentially be in front of

16:45 - 16:51

your Lambda functions that's caching

16:48 - 16:53

responses as needed and this is again

16:51 - 16:54

like however cell kind of works like it

16:53 - 16:56

they have a bunch of API Lambda

16:54 - 16:58

functions so how do you scale this up

16:56 - 17:00

even more I think we should talk about

16:58 - 17:02

Edge functions now we have this ability

17:00 - 17:03

to basically take execution like take

17:02 - 17:06

JavaScript code or take whatever type of

17:03 - 17:08

code and you can run it inside of an

17:06 - 17:11

edge Network and again the edge is going

17:08 - 17:14

to basically take a user's request

17:11 - 17:16

and run the code as close as possible to

17:14 - 17:18

the user so this is for scaling and

17:16 - 17:20

performance reasons again the way you

17:18 - 17:21

scale is reducing the amount of traffic

17:20 - 17:23

and load to your services so you can

17:21 - 17:25

handle more requests per second and if

17:23 - 17:27

one way you can do that is actually have

17:25 - 17:29

the computation lift closer to the user

17:27 - 17:31

and not have them need to go to the data

17:29 - 17:32

center to like do this computation

17:31 - 17:34

because

17:32 - 17:35

if you imagine this thing is going to be

17:34 - 17:38

a little bit further away in terms of

17:35 - 17:39

like distance from hopefully these

17:38 - 17:40

things right there's different servers

17:39 - 17:42

around the world and you're trying to

17:40 - 17:43

connect the user to the closest one

17:42 - 17:46

possible so these two are probably going

17:43 - 17:47

to be close in proximity and this one's

17:46 - 17:48

going to be a little bit further away so

17:47 - 17:50

this has a lot of benefits because you

17:48 - 17:52

can like reduce the amount of traffic

17:50 - 17:54

that needs to go to your API which again

17:52 - 17:56

will reduce the amount of traffic that

17:54 - 17:58

needs to go to your databases and reduce

17:56 - 17:59

your load on your servers so this

17:58 - 18:00

solution isn't perfect either because at

17:59 - 18:03

some point your Edge function probably

18:00 - 18:05

needs to talk to a database and right

18:03 - 18:07

now you could either have the edge

18:05 - 18:09

function talk directly to a database

18:07 - 18:10

which unfortunately some Edge providers

18:09 - 18:13

don't even allow you to run like binary

18:10 - 18:14

so like running something like Prisma on

18:13 - 18:16

your Edge function might not even work

18:14 - 18:17

so you basically have to just make sure

18:16 - 18:19

you do an API request from your Edge

18:17 - 18:21

function to your database if your

18:19 - 18:22

database supports like those type of

18:21 - 18:23

requests

18:22 - 18:25

um and that can sometimes shave off some

18:23 - 18:27

latency so that you don't have to go

18:25 - 18:29

through the API but I think it's worth

18:27 - 18:31

mentioning that usually the API is

18:29 - 18:34

actually super close to your servers

18:31 - 18:36

right so the latency between the server

18:34 - 18:36

and the database is going to be really

18:36 - 18:39

low

18:36 - 18:42

versus the latency between

18:39 - 18:44

your Edge function in the database will

18:42 - 18:46

be a lot higher so again I think the

18:44 - 18:48

main benefit of the edge function is if

18:46 - 18:52

you can kind of filter out data and

18:48 - 18:54

reduce the need to go to the the

18:52 - 18:56

database you're going to speed up your

18:54 - 18:58

your system I think we're also seeing

18:56 - 19:00

the industry go is we're having

18:58 - 19:02

basically this need to have Edge

19:00 - 19:05

databases so instead of having these

19:02 - 19:07

like primary replicated databases we're

19:05 - 19:10

trying to find ways to get databases to

19:07 - 19:15

be scaled inside the edge as well

19:10 - 19:17

so if every region has its own you know

19:15 - 19:19

front-end static files it has its

19:17 - 19:22

functions and it has its databases right

19:19 - 19:25

here this basically reduces a lot of the

19:22 - 19:27

overhead of connecting to a data center

19:25 - 19:29

and I would say probably this is a lot

19:27 - 19:31

more for like performance reasons and

19:29 - 19:33

not necessarily scaling but as you can

19:31 - 19:37

tell like all this stuff

19:33 - 19:39

is complex right like this this is all

19:37 - 19:42

being figured out in maintain and

19:39 - 19:44

managed by expert devops engineers and

19:42 - 19:46

system level engineers and database

19:44 - 19:47

engineers and it's not a problem that

19:46 - 19:49

you really want to spend a lot of time

19:47 - 19:51

trying to figure out yourself so I think

19:49 - 19:53

the the benefit of all this is that if

19:51 - 19:54

you are at a small company and all of a

19:53 - 19:57

sudden you get a ton of traffic and your

19:54 - 19:58

like startup is blowing up

19:57 - 20:01

um because it just can't handle the

19:58 - 20:03

traffic if you use something like versel

20:01 - 20:04

or these other services that kind of

20:03 - 20:06

provide the scaling out of the box for

20:04 - 20:07

you you're going to be good all right

20:06 - 20:09

you don't have to worry too much about

20:07 - 20:10

what happens if my server gets too many

20:09 - 20:12

requests is it going to crash and then

20:10 - 20:14

my entire company's

20:12 - 20:16

um you know servers are going to be 404

20:14 - 20:18

errors so using existing services will

20:16 - 20:20

kind of take the responsibility of

20:18 - 20:22

scaling everything manually out of your

20:20 - 20:23

hands and just leaves it in their hands

20:22 - 20:25

and all that for good reasons right

20:23 - 20:27

they've had years of experience doing it

20:25 - 20:29

and that is why you're paying them the

20:27 - 20:33

decent amount of money for them to kind

20:29 - 20:34

of take control of that type of stuff so

20:33 - 20:36

I think that's all I want to talk about

20:34 - 20:37

I don't know if this was a good talk

20:36 - 20:40

um I feel like at some point I just

20:37 - 20:41

started rambling and drawing circles and

20:40 - 20:43

lines everywhere but if you guys enjoyed

20:41 - 20:46

at least listening to me ramble about

20:43 - 20:48

this and how we've kind of went from a

20:46 - 20:50

single simple VM deployment to something

20:48 - 20:52

like super complex like we have here

20:50 - 20:53

give me a thumbs up also I have a

20:52 - 20:55

Discord Channel you're welcome to join

20:53 - 20:56

if you want to talk to me directly or

20:55 - 20:58

just find a place to hang out with some

20:56 - 21:00

other Developers it's in the description

20:58 - 21:02

of the video in below as a link other

21:00 - 21:04

than that yeah leave me a comment if you

21:02 - 21:05

think I completely messed up this

21:04 - 21:08

explanation or there's something I left

21:05 - 21:11

out I'm always eager for feedback all

21:08 - 21:11

right have a good day happy coding

Evolution of Application Deployment: From Traditional to Advanced Strategies

In the world of software development, the deployment of applications has come a long way, evolving from traditional methods to advanced strategies. Initially, deploying an application involved setting up a Virtual Machine (VM) like an EC2 instance or a Digital Ocean droplet. Developers or system admins would SSH into the box and manually install services like Express JS to run web APIs and host static files. Vertical scaling was the norm, starting small and gradually increasing server capacity as needed. However, as traffic grew, the limitations of this approach became evident.

To address scalability issues, the next step involved splitting out the database into a separate VM while vertically scaling both VMs independently. Offloading the database management to third-party services like Amazon RDS or PlanetScale reduced operational overhead and provided expertise in managing databases efficiently. This separation allowed for better vertical scaling of individual components.

Furthermore, to handle increased computational needs, horizontal scaling was introduced. Creating multiple instances of services and using load balancers distributed traffic evenly across these instances. Auto scaling groups like AWS Auto Scaling simplified the process by dynamically provisioning resources based on traffic demands.

As applications grew more complex, separating the API from the front end became crucial. APIs requiring more computational power were scaled independently from the front end. Deploying the front end to Content Delivery Networks (CDNs) improved performance by caching static assets globally and reducing latency for end-users.

Moreover, to enhance scaling further, the concept of serverless computing emerged. Platforms like AWS Lambda enabled functions to scale based on demand, providing instant scalability and isolating each function's execution environment. This approach minimized the risk of failures affecting entire services, improving reliability.

To optimize performance, edge computing technologies were leveraged, executing code closer to users to reduce latency and enhance speed. Edge databases started to emerge, decentralizing data storage and processing to regional nodes, further improving performance for globally distributed applications.

The industry's trend towards managed services and automated scaling solutions has made scaling applications more accessible for small companies experiencing rapid growth. By leveraging existing services that offer scalability out of the box, companies can focus on innovation and growth without worrying about infrastructure management issues.

In conclusion, the evolution of application deployment showcases the transition from manual setups to sophisticated, scalable architectures. Embracing modern deployment strategies and leveraging managed services provide businesses with the agility and scalability needed to thrive in today's competitive landscape.

Let's continue to embrace these advancements in application deployment and empower developers to build robust, scalable solutions effortlessly.


In this content-rich discussion, we explored the transformation of application deployment strategies, from traditional VM setups to advanced serverless computing and edge technologies. From manual configurations to automated scaling solutions, the journey highlights the evolution towards efficient, scalable, and reliable deployment practices.