7 unique ways to deploy a server-side app to the cloud. Explore the tradeoffs between each node.js deployment option on Google Cloud Platform. https://fireship.io/tags/node/

#node #webdev #top7

This video is NOT sponsored.

🔗 Resources

Google Cloud https://cloud.google.com/gcp
Cloud Run Tutorial https://fireship.io/lessons/firebase-microservices-with-cloud-run/
Docker in 100 Seconds https://youtu.be/Gjnup-PuquQ
Node.js Docs https://nodejs.org/en/

📚 Chapters

00:00 Deployment ain't easy
00:42 Node.js App Tour
01:40 1. Server in your Garage
02:47 2. Cloud VM
04:06 3. App Engine Standard
05:45 4. App Engine Flex
06:23 5. Kubernetes
07:01 6. Cloud Functions
08:17 7. Cloud Run

🤓 Install the quiz app

iOS https://itunes.apple.com/us/app/fireship/id1462592372?mt=8
Android https://play.google.com/store/apps/details?id=io.fireship.quizapp

🔥 Watch more with Fireship PRO

Upgrade to Fireship PRO at https://fireship.io/pro
Use code lORhwXd2 for 25% off your first payment. 

🎨 My Editor Settings

- Atom One Dark 
- vscode-icons
- Fira Code Font
2024-02-04T05:48:20.658Z
nova-2
2-general-nova
2024-01-09.29447
30089e05-99d1-4376-b32e-c263170674af
53bc47ab-08d5-48bb-add0-7dbcfae39f55
76c91a43d54d17a6c1743a3e34521855608b5070ead41a1b8748f12fa7604af0
67875a7f-c9c4-48a0-aa55-5bdb8a91c34a
deprecated
In this video, we'll look at 7 different ways to deploy a server side application.
I built this API with Node.
Js, and now I'm ready to share it with the world.
But one does not simply deploy an app to production.
There's all kinds of different ways to get the job done with trade offs between cost, complexity, and scalability.
On the surface, deployment seems like it should be easy.
We just need a computer to host the app, which we connect to the Internet so it can handle requests from all of our users.
But resources are limited.
And that means we need to synchronize many computers all over the world just to keep things running fast.
By the end of this video, you'll be able to analyze the trade offs like a CTO to choose the best deployment strategy for your server side application.
If you're new here, like and subscribe, then let's jump right into it.
First of all, let's look at some of the features in this Node.
Js application.
It requires Node 16, which is the current bleeding edge version, and that means wherever we deploy needs to support that exact version of Node.
It provides a basic REST API built with the Express JS framework.
Nothing too special, but we want these endpoints to have extremely fast response times.
1 of the endpoints though creates a WebSocket connection with the client.
That means that the connection between the client and server needs to stay open for a long time.
That'll come into play later because not every deployment strategy supports long lived connections like that.
Now one other important feature of this server is that it's stateless.
That means it doesn't store any persistent data in memory or on the disk that's needed between different HTTP requests.
Anything related to the Application state would be stored in a dedicated database.
Now to run this app on our local machine, we use the npm start command made available in the and JSON file.
Now the question becomes, how do we do the same thing for a computer that's accessible to the greater Internet?
The first option is to use your own hardware.
You might have an old PC laying around, or maybe you want to invest in your own server rack, or you can even use a $100 Raspberry Pi like I showed in this video.
This was actually a common way to deploy web application 15 years ago, because back in those days, the cloud didn't exist yet.
Almost every startup today will use the cloud because it's convenient and expensive, but deploying to your own hardware has some unique advantages.
Most importantly, you own your infrastructure.
It's not owned by a tech company like Amazon or Google who can sync you at any moment if they don't like the cut of your JIP.
But managing your own hardware is a major pain.
Not only do you need to think about the server configuration itself, but you also have to worry about things like electricity, air conditioning, natural disasters, and things like that.
If the electricity or internet goes out, then your website goes down.
Another challenge is that if you're an individual working out of your garage, you'll need to request a static IP address from your Internet service provider.
If they don't give you one, then you're pretty much screwed.
Now as your app grows in popularity, the only way to scale is to buy more computers.
And ideally, those computers are located in different parts the world, which means you'll also want an international real estate portfolio.
Luckily, there is an easier way to deploy a Node.
Js application, and it's called the cloud.
I'm going to focus on Google Cloud Platform for this video, but keep in mind that there are many different cloud providers out there offering similar services.
One option for deploying to the cloud is to use compute engine to create a virtual machine, which is basically just a computer in the cloud that you pay for by the hour.
And every customer on Google Cloud gets one free micro instance per a month, so the cost to get started in the cloud is way lower than if you were to buy your own physical hardware.
After creating a new VM on Compute Engine, it'll take a few steps to get your and deployed.
1st, you'll need to SSH into it to interact with the operating system.
Install your preferred Node.
Js version, then clone your source code to the file system.
From there, you can start the application, then go to the firewall settings and open up port 8080 so it can be accessed on the Internet.
And now technically, your app is deployed, but there are a lot of things missing here.
For 1, you'll need to reserve a static IP address, then update your DNS settings to point a custom domain to it.
In addition, you'll need to manage your own SSL if I could to serve it over HTTPS, and another problem is that it's not going to scale automatically.
Once the CPU and memory has been fully utilized, the app will just stop working.
We could address that by bringing in Nginx or setting up load balancers, but it's a lot of extra configuration work that most people don't want to deal with.
So so the next option we'll look at is the app engine standard environment for Node.
Js, which is a platform as a service.
It makes it incredibly easy to get our local node app to a production server, and the cloud fully manages the virtual machines, which means your app scales automatically as more traffic comes in.
All that manual configuration we had to do in the virtual machine is unnecessary in App Engine because it's preconfigured to scale popular types of applications.
1st, we installed the Google Cloud SDK on our local system.
2nd, we create an app dot YAML file in the root of the project.
Inside the file, we specify the run I'm as node 14.
We can also use this file to customize the hosting behavior and set limits on how the infrastructure will scale.
Then the third step is to use gcloudapp deploy command, which will upload the local code to the cloud, then look for the npm start command in the package JSON to run the application.
Then it provides a URL where the actual hosted app can be accessed.
And notice how it's HTTP secure because Google manages the SSL certificate for you.
In addition, App Engine provides task queues, cron jobs, logging, and a bunch of other tools that you wouldn't have in a normal VM.
It's also important to point out that App Engine is a persistent server, which means it's capable of handling long lived connections like WebSockets, and it's way easier to get your app online compared to a regular m, but here's the catch.
The reason it's called the standard environment is because you have no control over the runtime itself.
That makes it easier for Google to scale, but but if you have custom runtime dependencies or a version of Node that's not supported, then you won't be able to use it on the free tier.
Now although app engine standard is free initially.
It becomes more and more expensive as you scale up, and there may be less expensive serverless options as we'll see later.
The next option though is the App Engine flexible environment.
The primary difference is that instead of a sandboxed environment, you have full control over the environment with Docker.
That means you can install any version of Node.
Js that you like along with any other low level system dependencies, but at the same time, the cloud will still automatically scale those VMs up or down based on the incoming traffic.
And again, this is called a platform as a service and is very similar to things like Heroku or Elastic Beanstalk on AWS.
All you have to do is change the runtime to flex in the app dot yaml file, then add a Docker file to the root of the project.
App Engine will automatically manage the Docker image and containers for you.
But in some cases, developers want more control to orchestrate exactly how their infrastructure scales, and that's where Kubernetes comes in.
I once once heard a wise quote about Kubernetes that went something like, you don't fucking need Kubernetes, and I think that's true for the vast majority of developers out there.
If you remember earlier, deploying to a Regular VM requires a lot of configuration.
Kubernetes also requires a lot of configuration, but provides a predictable framework for scaling your infrastructure.
It's popular for large teams who have have extreme demands on their infrastructure.
Apps like Robinhood and Pokemon Go use Kubernetes behind the scenes.
But if you're just deploying a little side project, then Kubernetes it's probably way too expensive and complicated.
But at the other end of the complexity and cost spectrum, we have serverless functions.
Just like the App Engine standard environment, Cloud Functions provide a set runtime and allow you to deploy your code without ever having to think about the underlying infrastructure.
In fact, you can just copy and paste your code directly into the UI to deploy it.
The primary difference here compared to something like App Engine is that our servers are or short lived, and that allows Google to bill us for the exact amount of resources that we use.
Instead of paying a fixed monthly price for server.
We pay a tiny amount each time a function is invoked.
In addition, you can trigger Cloud Functions based on many different events happened in the cloud, like when a record is updated in a database or when a file is uploaded to a storage bucket.
And that makes it much easier to background jobs compared to other approaches.
Cloud functions are a very easy and inexpensive way to deploy a node app, but there are a few caveats that you need to be aware of.
In our case, we have an endpoint that needs to support WebSockets.
However, because Cloud Functions are short lived, we can't really implement WebSockets in them.
Another issue you might run into is something called the cold start time.
When a function is first allocated in the cloud, it might take a little while to get things set up and produce a very high response time on the initial request.
Another drawback is the fact that you have no control over the run time when using a serverless function.
But there's actually one more deployment option we can use to get around this limitation called Cloud Run.
It works just like a serverless function, but instead of using a predefined runtime, you can customize it by containerizing your application with Docker, allowing us to specify the bleeding edge version of Node.
Js along with any other low level dependencies that we might need.
Once we're able to run this app with Docker, We can then upload the image to the container registry, then use the image to create a new Cloud Run deployment.
And now we have all the benefits of serverless, like automatic scaling, and pay as you go pricing, while also having a lot more control over the underlying server.
And as an added bonus, we can set a minimum number of instances to reduce the cold start time, although that comes at a higher cost.
And with that, we have 7 different ways to deploy a Node.
Js application.
If you wanna see some of these deployment options in action, consider becoming a pro member at FireShip.
Io to get access to my full courses.
Thanks for watching, and I will see you in the next one.

Speaker 0: In this video, we'll look at 7 different ways to deploy a server side application. I built this API with Node. Js, and now I'm ready to share it with the world. But one does not simply deploy an app to production. There's all kinds of different ways to get the job done with trade offs between cost, complexity, and scalability.

On the surface, deployment seems like it should be easy. We just need a computer to host the app, which we connect to the Internet so it can handle requests from all of our users. But resources are limited. And that means we need to synchronize many computers all over the world just to keep things running fast. By the end of this video, you'll be able to analyze the trade offs like a CTO to choose the best deployment strategy for your server side application.

If you're new here, like and subscribe, then let's jump right into it. First of all, let's look at some of the features in this Node. Js application. It requires Node 16, which is the current bleeding edge version, and that means wherever we deploy needs to support that exact version of Node. It provides a basic REST API built with the Express JS framework.

Nothing too special, but we want these endpoints to have extremely fast response times. 1 of the endpoints though creates a WebSocket connection with the client. That means that the connection between the client and server needs to stay open for a long time. That'll come into play later because not every deployment strategy supports long lived connections like that. Now one other important feature of this server is that it's stateless.

That means it doesn't store any persistent data in memory or on the disk that's needed between different HTTP requests. Anything related to the Application state would be stored in a dedicated database. Now to run this app on our local machine, we use the npm start command made available in the and JSON file. Now the question becomes, how do we do the same thing for a computer that's accessible to the greater Internet? The first option is to use your own hardware.

You might have an old PC laying around, or maybe you want to invest in your own server rack, or you can even use a $100 Raspberry Pi like I showed in this video. This was actually a common way to deploy web application 15 years ago, because back in those days, the cloud didn't exist yet. Almost every startup today will use the cloud because it's convenient and expensive, but deploying to your own hardware has some unique advantages. Most importantly, you own your infrastructure. It's not owned by a tech company like Amazon or Google who can sync you at any moment if they don't like the cut of your JIP.

But managing your own hardware is a major pain. Not only do you need to think about the server configuration itself, but you also have to worry about things like electricity, air conditioning, natural disasters, and things like that. If the electricity or internet goes out, then your website goes down. Another challenge is that if you're an individual working out of your garage, you'll need to request a static IP address from your Internet service provider. If they don't give you one, then you're pretty much screwed.

Now as your app grows in popularity, the only way to scale is to buy more computers. And ideally, those computers are located in different parts the world, which means you'll also want an international real estate portfolio. Luckily, there is an easier way to deploy a Node. Js application, and it's called the cloud. I'm going to focus on Google Cloud Platform for this video, but keep in mind that there are many different cloud providers out there offering similar services.

One option for deploying to the cloud is to use compute engine to create a virtual machine, which is basically just a computer in the cloud that you pay for by the hour. And every customer on Google Cloud gets one free micro instance per a month, so the cost to get started in the cloud is way lower than if you were to buy your own physical hardware. After creating a new VM on Compute Engine, it'll take a few steps to get your and deployed. 1st, you'll need to SSH into it to interact with the operating system. Install your preferred Node.

Js version, then clone your source code to the file system. From there, you can start the application, then go to the firewall settings and open up port 8080 so it can be accessed on the Internet. And now technically, your app is deployed, but there are a lot of things missing here. For 1, you'll need to reserve a static IP address, then update your DNS settings to point a custom domain to it. In addition, you'll need to manage your own SSL if I could to serve it over HTTPS, and another problem is that it's not going to scale automatically.

Once the CPU and memory has been fully utilized, the app will just stop working. We could address that by bringing in Nginx or setting up load balancers, but it's a lot of extra configuration work that most people don't want to deal with. So so the next option we'll look at is the app engine standard environment for Node. Js, which is a platform as a service. It makes it incredibly easy to get our local node app to a production server, and the cloud fully manages the virtual machines, which means your app scales automatically as more traffic comes in.

All that manual configuration we had to do in the virtual machine is unnecessary in App Engine because it's preconfigured to scale popular types of applications. 1st, we installed the Google Cloud SDK on our local system. 2nd, we create an app dot YAML file in the root of the project. Inside the file, we specify the run I'm as node 14. We can also use this file to customize the hosting behavior and set limits on how the infrastructure will scale.

Then the third step is to use gcloudapp deploy command, which will upload the local code to the cloud, then look for the npm start command in the package JSON to run the application. Then it provides a URL where the actual hosted app can be accessed. And notice how it's HTTP secure because Google manages the SSL certificate for you. In addition, App Engine provides task queues, cron jobs, logging, and a bunch of other tools that you wouldn't have in a normal VM. It's also important to point out that App Engine is a persistent server, which means it's capable of handling long lived connections like WebSockets, and it's way easier to get your app online compared to a regular m, but here's the catch.

The reason it's called the standard environment is because you have no control over the runtime itself. That makes it easier for Google to scale, but but if you have custom runtime dependencies or a version of Node that's not supported, then you won't be able to use it on the free tier. Now although app engine standard is free initially. It becomes more and more expensive as you scale up, and there may be less expensive serverless options as we'll see later. The next option though is the App Engine flexible environment.

The primary difference is that instead of a sandboxed environment, you have full control over the environment with Docker. That means you can install any version of Node. Js that you like along with any other low level system dependencies, but at the same time, the cloud will still automatically scale those VMs up or down based on the incoming traffic. And again, this is called a platform as a service and is very similar to things like Heroku or Elastic Beanstalk on AWS. All you have to do is change the runtime to flex in the app dot yaml file, then add a Docker file to the root of the project.

App Engine will automatically manage the Docker image and containers for you. But in some cases, developers want more control to orchestrate exactly how their infrastructure scales, and that's where Kubernetes comes in. I once once heard a wise quote about Kubernetes that went something like, you don't fucking need Kubernetes, and I think that's true for the vast majority of developers out there. If you remember earlier, deploying to a Regular VM requires a lot of configuration. Kubernetes also requires a lot of configuration, but provides a predictable framework for scaling your infrastructure.

It's popular for large teams who have have extreme demands on their infrastructure. Apps like Robinhood and Pokemon Go use Kubernetes behind the scenes. But if you're just deploying a little side project, then Kubernetes it's probably way too expensive and complicated. But at the other end of the complexity and cost spectrum, we have serverless functions. Just like the App Engine standard environment, Cloud Functions provide a set runtime and allow you to deploy your code without ever having to think about the underlying infrastructure.

In fact, you can just copy and paste your code directly into the UI to deploy it. The primary difference here compared to something like App Engine is that our servers are or short lived, and that allows Google to bill us for the exact amount of resources that we use. Instead of paying a fixed monthly price for server. We pay a tiny amount each time a function is invoked. In addition, you can trigger Cloud Functions based on many different events happened in the cloud, like when a record is updated in a database or when a file is uploaded to a storage bucket.

And that makes it much easier to background jobs compared to other approaches. Cloud functions are a very easy and inexpensive way to deploy a node app, but there are a few caveats that you need to be aware of. In our case, we have an endpoint that needs to support WebSockets. However, because Cloud Functions are short lived, we can't really implement WebSockets in them. Another issue you might run into is something called the cold start time.

When a function is first allocated in the cloud, it might take a little while to get things set up and produce a very high response time on the initial request. Another drawback is the fact that you have no control over the run time when using a serverless function. But there's actually one more deployment option we can use to get around this limitation called Cloud Run. It works just like a serverless function, but instead of using a predefined runtime, you can customize it by containerizing your application with Docker, allowing us to specify the bleeding edge version of Node. Js along with any other low level dependencies that we might need.

Once we're able to run this app with Docker, We can then upload the image to the container registry, then use the image to create a new Cloud Run deployment. And now we have all the benefits of serverless, like automatic scaling, and pay as you go pricing, while also having a lot more control over the underlying server. And as an added bonus, we can set a minimum number of instances to reduce the cold start time, although that comes at a higher cost. And with that, we have 7 different ways to deploy a Node. Js application.

If you wanna see some of these deployment options in action, consider becoming a pro member at FireShip. Io to get access to my full courses. Thanks for watching, and I will see you in the next one.
In this video, we'll look at 7 different ways to deploy a server side application. I built this API with Node. Js, and now I'm ready to share it with the world.
But one does not simply deploy an app to production. There's all kinds of different ways to get the job done with trade offs between cost, complexity, and scalability. On the surface, deployment seems like it should be easy. We just need a computer to host the app, which we connect to the Internet so it can handle requests from all of our users. But resources are limited. And that means we need to synchronize many computers all over the world just to keep things running fast. By the end of this video, you'll be able to analyze the trade offs like a CTO to choose the best deployment strategy for your server side application.
computers
networking
infrastructure
software
software development
technology
data management
multimedia
internet
If you're new here, like and subscribe, then let's jump right into it. First of all, let's look at some of the features in this Node. Js application. It requires Node 16, which is the current bleeding edge version, and that means wherever we deploy needs to support that exact version of Node. It provides a basic REST API built with the Express JS framework. Nothing too special, but we want these endpoints to have extremely fast response times.
1 of the endpoints though creates a WebSocket connection with the client. That means that the connection between the client and server needs to stay open for a long time. That'll come into play later because not every deployment strategy supports long lived connections like that. Now one other important feature of this server is that it's stateless.
networking
That means it doesn't store any persistent data in memory or on the disk that's needed between different HTTP requests. Anything related to the Application state would be stored in a dedicated database. Now to run this app on our local machine, we use the npm start command made available in the and JSON file. Now the question becomes, how do we do the same thing for a computer that's accessible to the greater Internet?
The first option is to use your own hardware. You might have an old PC laying around, or maybe you want to invest in your own server rack, or you can even use a $100 Raspberry Pi like I showed in this video. This was actually a common way to deploy web application 15 years ago, because back in those days, the cloud didn't exist yet.
computers
ibm
Almost every startup today will use the cloud because it's convenient and expensive, but deploying to your own hardware has some unique advantages.
Most importantly, you own your infrastructure. It's not owned by a tech company like Amazon or Google who can sync you at any moment if they don't like the cut of your JIP. But managing your own hardware is a major pain. Not only do you need to think about the server configuration itself, but you also have to worry about things like electricity, air conditioning, natural disasters, and things like that. If the electricity or internet goes out, then your website goes down. Another challenge is that if you're an individual working out of your garage, you'll need to request a static IP address from your Internet service provider. If they don't give you one, then you're pretty much screwed. Now as your app grows in popularity, the only way to scale is to buy more computers. And ideally, those computers are located in different parts the world, which means you'll also want an international real estate portfolio. Luckily, there is an easier way to deploy a Node. Js application, and it's called the cloud. I'm going to focus on Google Cloud Platform for this video, but keep in mind that there are many different cloud providers out there offering similar services.
internet
real estate
telecommunications
infrastructure
networking
computers
ibm
One option for deploying to the cloud is to use compute engine to create a virtual machine, which is basically just a computer in the cloud that you pay for by the hour. And every customer on Google Cloud gets one free micro instance per a month, so the cost to get started in the cloud is way lower than if you were to buy your own physical hardware. After creating a new VM on Compute Engine, it'll take a few steps to get your and deployed. 1st, you'll need to SSH into it to interact with the operating system. Install your preferred Node. Js version, then clone your source code to the file system. From there, you can start the application, then go to the firewall settings and open up port 8080 so it can be accessed on the Internet. And now technically, your app is deployed, but there are a lot of things missing here. For 1, you'll need to reserve a static IP address, then update your DNS settings to point a custom domain to it. In addition, you'll need to manage your own SSL if I could to serve it over HTTPS, and another problem is that it's not going to scale automatically. Once the CPU and memory has been fully utilized, the app will just stop working. We could address that by bringing in Nginx or setting up load balancers, but it's a lot of extra configuration work that most people don't want to deal with.
So so the next option we'll look at is the app engine standard environment for Node. Js, which is a platform as a service. It makes it incredibly easy to get our local node app to a production server, and the cloud fully manages the virtual machines, which means your app scales automatically as more traffic comes in. All that manual configuration we had to do in the virtual machine is unnecessary in App Engine because it's preconfigured to scale popular types of applications. 1st, we installed the Google Cloud SDK on our local system. 2nd, we create an app dot YAML file in the root of the project. Inside the file, we specify the run I'm as node 14. We can also use this file to customize the hosting behavior and set limits on how the infrastructure will scale.
software development
infrastructure
google
software
Then the third step is to use gcloudapp deploy command, which will upload the local code to the cloud, then look for the npm start command in the package JSON to run the application.
Then it provides a URL where the actual hosted app can be accessed. And notice how it's HTTP secure because Google manages the SSL certificate for you. In addition, App Engine provides task queues, cron jobs, logging, and a bunch of other tools that you wouldn't have in a normal VM. It's also important to point out that App Engine is a persistent server, which means it's capable of handling long lived connections like WebSockets, and it's way easier to get your app online compared to a regular m, but here's the catch.
google
software
The reason it's called the standard environment is because you have no control over the runtime itself. That makes it easier for Google to scale, but but if you have custom runtime dependencies or a version of Node that's not supported, then you won't be able to use it on the free tier. Now although app engine standard is free initially. It becomes more and more expensive as you scale up, and there may be less expensive serverless options as we'll see later. The next option though is the App Engine flexible environment. The primary difference is that instead of a sandboxed environment, you have full control over the environment with Docker. That means you can install any version of Node. Js that you like along with any other low level system dependencies, but at the same time, the cloud will still automatically scale those VMs up or down based on the incoming traffic.
And again, this is called a platform as a service and is very similar to things like Heroku or Elastic Beanstalk on AWS. All you have to do is change the runtime to flex in the app dot yaml file, then add a Docker file to the root of the project. App Engine will automatically manage the Docker image and containers for you. But in some cases, developers want more control to orchestrate exactly how their infrastructure scales, and that's where Kubernetes comes in. I once once heard a wise quote about Kubernetes that went something like, you don't fucking need Kubernetes, and I think that's true for the vast majority of developers out there.
software
software development
infrastructure
If you remember earlier, deploying to a Regular VM requires a lot of configuration. Kubernetes also requires a lot of configuration, but provides a predictable framework for scaling your infrastructure. It's popular for large teams who have have extreme demands on their infrastructure. Apps like Robinhood and Pokemon Go use Kubernetes behind the scenes. But if you're just deploying a little side project, then Kubernetes it's probably way too expensive and complicated. But at the other end of the complexity and cost spectrum, we have serverless functions.
networking
podcasts
Just like the App Engine standard environment, Cloud Functions provide a set runtime and allow you to deploy your code without ever having to think about the underlying infrastructure.
In fact, you can just copy and paste your code directly into the UI to deploy it. The primary difference here compared to something like App Engine is that our servers are or short lived, and that allows Google to bill us for the exact amount of resources that we use.
google
software
Instead of paying a fixed monthly price for server. We pay a tiny amount each time a function is invoked. In addition, you can trigger Cloud Functions based on many different events happened in the cloud, like when a record is updated in a database or when a file is uploaded to a storage bucket. And that makes it much easier to background jobs compared to other approaches. Cloud functions are a very easy and inexpensive way to deploy a node app, but there are a few caveats that you need to be aware of. In our case, we have an endpoint that needs to support WebSockets. However, because Cloud Functions are short lived, we can't really implement WebSockets in them. Another issue you might run into is something called the cold start time. When a function is first allocated in the cloud, it might take a little while to get things set up and produce a very high response time on the initial request. Another drawback is the fact that you have no control over the run time when using a serverless function. But there's actually one more deployment option we can use to get around this limitation called Cloud Run. It works just like a serverless function, but instead of using a predefined runtime, you can customize it by containerizing your application with Docker, allowing us to specify the bleeding edge version of Node. Js along with any other low level dependencies that we might need. Once we're able to run this app with Docker, We can then upload the image to the container registry, then use the image to create a new Cloud Run deployment. And now we have all the benefits of serverless, like automatic scaling, and pay as you go pricing, while also having a lot more control over the underlying server. And as an added bonus, we can set a minimum number of instances to reduce the cold start time, although that comes at a higher cost. And with that, we have 7 different ways to deploy a Node. Js application. If you wanna see some of these deployment options in action, consider becoming a pro member at FireShip.
Io to get access to my full courses. Thanks for watching, and I will see you in the next one.
In this video, we'll look at 7 different ways to deploy a server side application. I built this API with Node. Js, and now I'm ready to share it with the world. But one does not simply deploy an app to production. There's all kinds of different ways to get the job done with trade offs between cost, complexity, and scalability. On the surface, deployment seems like it should be easy. We just need a computer to host the app, which we connect to the Internet so it can handle requests from all of our users. But resources are limited. And that means we need to synchronize many computers all over the world just to keep things running fast. By the end of this video, you'll be able to analyze the trade offs like a CTO to choose the best deployment strategy for your server side application. If you're new here, like and subscribe, then let's jump right into it. First of all, let's look at some of the features in this Node. Js application. It requires Node 16, which is the current bleeding edge version, and that means wherever we deploy needs to support that exact version of Node. It provides a basic REST API built with the Express JS framework. Nothing too special, but we want these endpoints to have extremely fast response times. 1 of the endpoints though creates a WebSocket connection with the client. That means that the connection between the client and server needs to stay open for a long time. That'll come into play later because not every deployment strategy supports long lived connections like that. Now one other important feature of this server is that it's stateless. That means it doesn't store any persistent data in memory or on the disk that's needed between different HTTP requests. Anything related to the Application state would be stored in a dedicated database. Now to run this app on our local machine, we use the npm start command made available in the and JSON file. Now the question becomes, how do we do the same thing for a computer that's accessible to the greater Internet? The first option is to use your own hardware. You might have an old PC laying around, or maybe you want to invest in your own server rack, or you can even use a $100 Raspberry Pi like I showed in this video. This was actually a common way to deploy web application 15 years ago, because back in those days, the cloud didn't exist yet. Almost every startup today will use the cloud because it's convenient and expensive, but deploying to your own hardware has some unique advantages. Most importantly, you own your infrastructure. It's not owned by a tech company like Amazon or Google who can sync you at any moment if they don't like the cut of your JIP. But managing your own hardware is a major pain. Not only do you need to think about the server configuration itself, but you also have to worry about things like electricity, air conditioning, natural disasters, and things like that. If the electricity or internet goes out, then your website goes down. Another challenge is that if you're an individual working out of your garage, you'll need to request a static IP address from your Internet service provider. If they don't give you one, then you're pretty much screwed. Now as your app grows in popularity, the only way to scale is to buy more computers. And ideally, those computers are located in different parts the world, which means you'll also want an international real estate portfolio. Luckily, there is an easier way to deploy a Node. Js application, and it's called the cloud. I'm going to focus on Google Cloud Platform for this video, but keep in mind that there are many different cloud providers out there offering similar services. One option for deploying to the cloud is to use compute engine to create a virtual machine, which is basically just a computer in the cloud that you pay for by the hour. And every customer on Google Cloud gets one free micro instance per a month, so the cost to get started in the cloud is way lower than if you were to buy your own physical hardware. After creating a new VM on Compute Engine, it'll take a few steps to get your and deployed. 1st, you'll need to SSH into it to interact with the operating system. Install your preferred Node. Js version, then clone your source code to the file system. From there, you can start the application, then go to the firewall settings and open up port 8080 so it can be accessed on the Internet. And now technically, your app is deployed, but there are a lot of things missing here. For 1, you'll need to reserve a static IP address, then update your DNS settings to point a custom domain to it. In addition, you'll need to manage your own SSL if I could to serve it over HTTPS, and another problem is that it's not going to scale automatically. Once the CPU and memory has been fully utilized, the app will just stop working. We could address that by bringing in Nginx or setting up load balancers, but it's a lot of extra configuration work that most people don't want to deal with. So so the next option we'll look at is the app engine standard environment for Node. Js, which is a platform as a service. It makes it incredibly easy to get our local node app to a production server, and the cloud fully manages the virtual machines, which means your app scales automatically as more traffic comes in. All that manual configuration we had to do in the virtual machine is unnecessary in App Engine because it's preconfigured to scale popular types of applications. 1st, we installed the Google Cloud SDK on our local system. 2nd, we create an app dot YAML file in the root of the project. Inside the file, we specify the run I'm as node 14. We can also use this file to customize the hosting behavior and set limits on how the infrastructure will scale. Then the third step is to use gcloudapp deploy command, which will upload the local code to the cloud, then look for the npm start command in the package JSON to run the application. Then it provides a URL where the actual hosted app can be accessed. And notice how it's HTTP secure because Google manages the SSL certificate for you. In addition, App Engine provides task queues, cron jobs, logging, and a bunch of other tools that you wouldn't have in a normal VM. It's also important to point out that App Engine is a persistent server, which means it's capable of handling long lived connections like WebSockets, and it's way easier to get your app online compared to a regular m, but here's the catch. The reason it's called the standard environment is because you have no control over the runtime itself. That makes it easier for Google to scale, but but if you have custom runtime dependencies or a version of Node that's not supported, then you won't be able to use it on the free tier. Now although app engine standard is free initially. It becomes more and more expensive as you scale up, and there may be less expensive serverless options as we'll see later. The next option though is the App Engine flexible environment. The primary difference is that instead of a sandboxed environment, you have full control over the environment with Docker. That means you can install any version of Node. Js that you like along with any other low level system dependencies, but at the same time, the cloud will still automatically scale those VMs up or down based on the incoming traffic. And again, this is called a platform as a service and is very similar to things like Heroku or Elastic Beanstalk on AWS. All you have to do is change the runtime to flex in the app dot yaml file, then add a Docker file to the root of the project. App Engine will automatically manage the Docker image and containers for you. But in some cases, developers want more control to orchestrate exactly how their infrastructure scales, and that's where Kubernetes comes in. I once once heard a wise quote about Kubernetes that went something like, you don't fucking need Kubernetes, and I think that's true for the vast majority of developers out there. If you remember earlier, deploying to a Regular VM requires a lot of configuration. Kubernetes also requires a lot of configuration, but provides a predictable framework for scaling your infrastructure. It's popular for large teams who have have extreme demands on their infrastructure. Apps like Robinhood and Pokemon Go use Kubernetes behind the scenes. But if you're just deploying a little side project, then Kubernetes it's probably way too expensive and complicated. But at the other end of the complexity and cost spectrum, we have serverless functions. Just like the App Engine standard environment, Cloud Functions provide a set runtime and allow you to deploy your code without ever having to think about the underlying infrastructure. In fact, you can just copy and paste your code directly into the UI to deploy it. The primary difference here compared to something like App Engine is that our servers are or short lived, and that allows Google to bill us for the exact amount of resources that we use. Instead of paying a fixed monthly price for server. We pay a tiny amount each time a function is invoked. In addition, you can trigger Cloud Functions based on many different events happened in the cloud, like when a record is updated in a database or when a file is uploaded to a storage bucket. And that makes it much easier to background jobs compared to other approaches. Cloud functions are a very easy and inexpensive way to deploy a node app, but there are a few caveats that you need to be aware of. In our case, we have an endpoint that needs to support WebSockets. However, because Cloud Functions are short lived, we can't really implement WebSockets in them. Another issue you might run into is something called the cold start time. When a function is first allocated in the cloud, it might take a little while to get things set up and produce a very high response time on the initial request. Another drawback is the fact that you have no control over the run time when using a serverless function. But there's actually one more deployment option we can use to get around this limitation called Cloud Run. It works just like a serverless function, but instead of using a predefined runtime, you can customize it by containerizing your application with Docker, allowing us to specify the bleeding edge version of Node. Js along with any other low level dependencies that we might need. Once we're able to run this app with Docker, We can then upload the image to the container registry, then use the image to create a new Cloud Run deployment. And now we have all the benefits of serverless, like automatic scaling, and pay as you go pricing, while also having a lot more control over the underlying server. And as an added bonus, we can set a minimum number of instances to reduce the cold start time, although that comes at a higher cost. And with that, we have 7 different ways to deploy a Node. Js application. If you wanna see some of these deployment options in action, consider becoming a pro member at FireShip. Io to get access to my full courses. Thanks for watching, and I will see you in the next one.
In
in
this
this
video,
video
we'll
we'll
look
look
at
at
7
7
different
different
ways
ways
to
to
deploy
deploy
a
a
server
server
side
side
application.
application
I
i
built
built
this
this
API
api
with
with
Node.
node
Js,
js
and
and
now
now
I'm
i'm
ready
ready
to
to
share
share
it
it
with
with
the
the
world.
world
But
but
one
one
does
does
not
not
simply
simply
deploy
deploy
an
an
app
app
to
to
production.
production
There's
there's
all
all
kinds
kinds
of
of
different
different
ways
ways
to
to
get
get
the
the
job
job
done
done
with
with
trade
trade
offs
offs
between
between
cost,
cost
complexity,
complexity
and
and
scalability.
scalability
On
on
the
the
surface,
surface
deployment
deployment
seems
seems
like
like
it
it
should
should
be
be
easy.
easy
We
we
just
just
need
need
a
a
computer
computer
to
to
host
host
the
the
app,
app
which
which
we
we
connect
connect
to
to
the
the
Internet
internet
so
so
it
it
can
can
handle
handle
requests
requests
from
from
all
all
of
of
our
our
users.
users
But
but
resources
resources
are
are
limited.
limited
And
and
that
that
means
means
we
we
need
need
to
to
synchronize
synchronize
many
many
computers
computers
all
all
over
over
the
the
world
world
just
just
to
to
keep
keep
things
things
running
running
fast.
fast
By
by
the
the
end
end
of
of
this
this
video,
video
you'll
you'll
be
be
able
able
to
to
analyze
analyze
the
the
trade
trade
offs
offs
like
like
a
a
CTO
cto
to
to
choose
choose
the
the
best
best
deployment
deployment
strategy
strategy
for
for
your
your
server
server
side
side
application.
application
If
if
you're
you're
new
new
here,
here
like
like
and
and
subscribe,
subscribe
then
then
let's
let's
jump
jump
right
right
into
into
it.
it
First
first
of
of
all,
all
let's
let's
look
look
at
at
some
some
of
of
the
the
features
features
in
in
this
this
Node.
node
Js
js
application.
application
It
it
requires
requires
Node
node
16,
16
which
which
is
is
the
the
current
current
bleeding
bleeding
edge
edge
version,
version
and
and
that
that
means
means
wherever
wherever
we
we
deploy
deploy
needs
needs
to
to
support
support
that
that
exact
exact
version
version
of
of
Node.
node
It
it
provides
provides
a
a
basic
basic
REST
rest
API
api
built
built
with
with
the
the
Express
express
JS
js
framework.
framework
Nothing
nothing
too
too
special,
special
but
but
we
we
want
want
these
these
endpoints
endpoints
to
to
have
have
extremely
extremely
fast
fast
response
response
times.
times
1
1
of
of
the
the
endpoints
endpoints
though
though
creates
creates
a
a
WebSocket
websocket
connection
connection
with
with
the
the
client.
client
That
that
means
means
that
that
the
the
connection
connection
between
between
the
the
client
client
and
and
server
server
needs
needs
to
to
stay
stay
open
open
for
for
a
a
long
long
time.
time
That'll
that'll
come
come
into
into
play
play
later
later
because
because
not
not
every
every
deployment
deployment
strategy
strategy
supports
supports
long
long
lived
lived
connections
connections
like
like
that.
that
Now
now
one
one
other
other
important
important
feature
feature
of
of
this
this
server
server
is
is
that
that
it's
it's
stateless.
stateless
That
that
means
means
it
it
doesn't
doesn't
store
store
any
any
persistent
persistent
data
data
in
in
memory
memory
or
or
on
on
the
the
disk
disk
that's
that's
needed
needed
between
between
different
different
HTTP
http
requests.
requests
Anything
anything
related
related
to
to
the
the
Application
application
state
state
would
would
be
be
stored
stored
in
in
a
a
dedicated
dedicated
database.
database
Now
now
to
to
run
run
this
this
app
app
on
on
our
our
local
local
machine,
machine
we
we
use
use
the
the
npm
npm
start
start
command
command
made
made
available
available
in
in
the
the
and
and
JSON
json
file.
file
Now
now
the
the
question
question
becomes,
becomes
how
how
do
do
we
we
do
do
the
the
same
same
thing
thing
for
for
a
a
computer
computer
that's
that's
accessible
accessible
to
to
the
the
greater
greater
Internet?
internet
The
the
first
first
option
option
is
is
to
to
use
use
your
your
own
own
hardware.
hardware
You
you
might
might
have
have
an
an
old
old
PC
pc
laying
laying
around,
around
or
or
maybe
maybe
you
you
want
want
to
to
invest
invest
in
in
your
your
own
own
server
server
rack,
rack
or
or
you
you
can
can
even
even
use
use
a
a
$100
$100
Raspberry
raspberry
Pi
pi
like
like
I
i
showed
showed
in
in
this
this
video.
video
This
this
was
was
actually
actually
a
a
common
common
way
way
to
to
deploy
deploy
web
web
application
application
15
15
years
years
ago,
ago
because
because
back
back
in
in
those
those
days,
days
the
the
cloud
cloud
didn't
didn't
exist
exist
yet.
yet
Almost
almost
every
every
startup
startup
today
today
will
will
use
use
the
the
cloud
cloud
because
because
it's
it's
convenient
convenient
and
and
expensive,
expensive
but
but
deploying
deploying
to
to
your
your
own
own
hardware
hardware
has
has
some
some
unique
unique
advantages.
advantages
Most
most
importantly,
importantly
you
you
own
own
your
your
infrastructure.
infrastructure
It's
it's
not
not
owned
owned
by
by
a
a
tech
tech
company
company
like
like
Amazon
amazon
or
or
Google
google
who
who
can
can
sync
sync
you
you
at
at
any
any
moment
moment
if
if
they
they
don't
don't
like
like
the
the
cut
cut
of
of
your
your
JIP.
jip
But
but
managing
managing
your
your
own
own
hardware
hardware
is
is
a
a
major
major
pain.
pain
Not
not
only
only
do
do
you
you
need
need
to
to
think
think
about
about
the
the
server
server
configuration
configuration
itself,
itself
but
but
you
you
also
also
have
have
to
to
worry
worry
about
about
things
things
like
like
electricity,
electricity
air
air
conditioning,
conditioning
natural
natural
disasters,
disasters
and
and
things
things
like
like
that.
that
If
if
the
the
electricity
electricity
or
or
internet
internet
goes
goes
out,
out
then
then
your
your
website
website
goes
goes
down.
down
Another
another
challenge
challenge
is
is
that
that
if
if
you're
you're
an
an
individual
individual
working
working
out
out
of
of
your
your
garage,
garage
you'll
you'll
need
need
to
to
request
request
a
a
static
static
IP
ip
address
address
from
from
your
your
Internet
internet
service
service
provider.
provider
If
if
they
they
don't
don't
give
give
you
you
one,
one
then
then
you're
you're
pretty
pretty
much
much
screwed.
screwed
Now
now
as
as
your
your
app
app
grows
grows
in
in
popularity,
popularity
the
the
only
only
way
way
to
to
scale
scale
is
is
to
to
buy
buy
more
more
computers.
computers
And
and
ideally,
ideally
those
those
computers
computers
are
are
located
located
in
in
different
different
parts
parts
the
the
world,
world
which
which
means
means
you'll
you'll
also
also
want
want
an
an
international
international
real
real
estate
estate
portfolio.
portfolio
Luckily,
luckily
there
there
is
is
an
an
easier
easier
way
way
to
to
deploy
deploy
a
a
Node.
node
Js
js
application,
application
and
and
it's
it's
called
called
the
the
cloud.
cloud
I'm
i'm
going
going
to
to
focus
focus
on
on
Google
google
Cloud
cloud
Platform
platform
for
for
this
this
video,
video
but
but
keep
keep
in
in
mind
mind
that
that
there
there
are
are
many
many
different
different
cloud
cloud
providers
providers
out
out
there
there
offering
offering
similar
similar
services.
services
One
one
option
option
for
for
deploying
deploying
to
to
the
the
cloud
cloud
is
is
to
to
use
use
compute
compute
engine
engine
to
to
create
create
a
a
virtual
virtual
machine,
machine
which
which
is
is
basically
basically
just
just
a
a
computer
computer
in
in
the
the
cloud
cloud
that
that
you
you
pay
pay
for
for
by
by
the
the
hour.
hour
And
and
every
every
customer
customer
on
on
Google
google
Cloud
cloud
gets
gets
one
one
free
free
micro
micro
instance
instance
per
per
a
a
month,
month
so
so
the
the
cost
cost
to
to
get
get
started
started
in
in
the
the
cloud
cloud
is
is
way
way
lower
lower
than
than
if
if
you
you
were
were
to
to
buy
buy
your
your
own
own
physical
physical
hardware.
hardware
After
after
creating
creating
a
a
new
new
VM
vm
on
on
Compute
compute
Engine,
engine
it'll
it'll
take
take
a
a
few
few
steps
steps
to
to
get
get
your
your
and
and
deployed.
deployed
1st,
1st
you'll
you'll
need
need
to
to
SSH
ssh
into
into
it
it
to
to
interact
interact
with
with
the
the
operating
operating
system.
system
Install
install
your
your
preferred
preferred
Node.
node
Js
js
version,
version
then
then
clone
clone
your
your
source
source
code
code
to
to
the
the
file
file
system.
system
From
from
there,
there
you
you
can
can
start
start
the
the
application,
application
then
then
go
go
to
to
the
the
firewall
firewall
settings
settings
and
and
open
open
up
up
port
port
8080
8080
so
so
it
it
can
can
be
be
accessed
accessed
on
on
the
the
Internet.
internet
And
and
now
now
technically,
technically
your
your
app
app
is
is
deployed,
deployed
but
but
there
there
are
are
a
a
lot
lot
of
of
things
things
missing
missing
here.
here
For
for
1,
1
you'll
you'll
need
need
to
to
reserve
reserve
a
a
static
static
IP
ip
address,
address
then
then
update
update
your
your
DNS
dns
settings
settings
to
to
point
point
a
a
custom
custom
domain
domain
to
to
it.
it
In
in
addition,
addition
you'll
you'll
need
need
to
to
manage
manage
your
your
own
own
SSL
ssl
if
if
I
i
could
could
to
to
serve
serve
it
it
over
over
HTTPS,
https
and
and
another
another
problem
problem
is
is
that
that
it's
it's
not
not
going
going
to
to
scale
scale
automatically.
automatically
Once
once
the
the
CPU
cpu
and
and
memory
memory
has
has
been
been
fully
fully
utilized,
utilized
the
the
app
app
will
will
just
just
stop
stop
working.
working
We
we
could
could
address
address
that
that
by
by
bringing
bringing
in
in
Nginx
nginx
or
or
setting
setting
up
up
load
load
balancers,
balancers
but
but
it's
it's
a
a
lot
lot
of
of
extra
extra
configuration
configuration
work
work
that
that
most
most
people
people
don't
don't
want
want
to
to
deal
deal
with.
with
So
so
so
so
the
the
next
next
option
option
we'll
we'll
look
look
at
at
is
is
the
the
app
app
engine
engine
standard
standard
environment
environment
for
for
Node.
node
Js,
js
which
which
is
is
a
a
platform
platform
as
as
a
a
service.
service
It
it
makes
makes
it
it
incredibly
incredibly
easy
easy
to
to
get
get
our
our
local
local
node
node
app
app
to
to
a
a
production
production
server,
server
and
and
the
the
cloud
cloud
fully
fully
manages
manages
the
the
virtual
virtual
machines,
machines
which
which
means
means
your
your
app
app
scales
scales
automatically
automatically
as
as
more
more
traffic
traffic
comes
comes
in.
in
All
all
that
that
manual
manual
configuration
configuration
we
we
had
had
to
to
do
do
in
in
the
the
virtual
virtual
machine
machine
is
is
unnecessary
unnecessary
in
in
App
app
Engine
engine
because
because
it's
it's
preconfigured
preconfigured
to
to
scale
scale
popular
popular
types
types
of
of
applications.
applications
1st,
1st
we
we
installed
installed
the
the
Google
google
Cloud
cloud
SDK
sdk
on
on
our
our
local
local
system.
system
2nd,
2nd
we
we
create
create
an
an
app
app
dot
dot
YAML
yaml
file
file
in
in
the
the
root
root
of
of
the
the
project.
project
Inside
inside
the
the
file,
file
we
we
specify
specify
the
the
run
run
I'm
i'm
as
as
node
node
14.
14
We
we
can
can
also
also
use
use
this
this
file
file
to
to
customize
customize
the
the
hosting
hosting
behavior
behavior
and
and
set
set
limits
limits
on
on
how
how
the
the
infrastructure
infrastructure
will
will
scale.
scale
Then
then
the
the
third
third
step
step
is
is
to
to
use
use
gcloudapp
gcloudapp
deploy
deploy
command,
command
which
which
will
will
upload
upload
the
the
local
local
code
code
to
to
the
the
cloud,
cloud
then
then
look
look
for
for
the
the
npm
npm
start
start
command
command
in
in
the
the
package
package
JSON
json
to
to
run
run
the
the
application.
application
Then
then
it
it
provides
provides
a
a
URL
url
where
where
the
the
actual
actual
hosted
hosted
app
app
can
can
be
be
accessed.
accessed
And
and
notice
notice
how
how
it's
it's
HTTP
http
secure
secure
because
because
Google
google
manages
manages
the
the
SSL
ssl
certificate
certificate
for
for
you.
you
In
in
addition,
addition
App
app
Engine
engine
provides
provides
task
task
queues,
queues
cron
cron
jobs,
jobs
logging,
logging
and
and
a
a
bunch
bunch
of
of
other
other
tools
tools
that
that
you
you
wouldn't
wouldn't
have
have
in
in
a
a
normal
normal
VM.
vm
It's
it's
also
also
important
important
to
to
point
point
out
out
that
that
App
app
Engine
engine
is
is
a
a
persistent
persistent
server,
server
which
which
means
means
it's
it's
capable
capable
of
of
handling
handling
long
long
lived
lived
connections
connections
like
like
WebSockets,
websockets
and
and
it's
it's
way
way
easier
easier
to
to
get
get
your
your
app
app
online
online
compared
compared
to
to
a
a
regular
regular
m,
m
but
but
here's
here's
the
the
catch.
catch
The
the
reason
reason
it's
it's
called
called
the
the
standard
standard
environment
environment
is
is
because
because
you
you
have
have
no
no
control
control
over
over
the
the
runtime
runtime
itself.
itself
That
that
makes
makes
it
it
easier
easier
for
for
Google
google
to
to
scale,
scale
but
but
but
but
if
if
you
you
have
have
custom
custom
runtime
runtime
dependencies
dependencies
or
or
a
a
version
version
of
of
Node
node
that's
that's
not
not
supported,
supported
then
then
you
you
won't
won't
be
be
able
able
to
to
use
use
it
it
on
on
the
the
free
free
tier.
tier
Now
now
although
although
app
app
engine
engine
standard
standard
is
is
free
free
initially.
initially
It
it
becomes
becomes
more
more
and
and
more
more
expensive
expensive
as
as
you
you
scale
scale
up,
up
and
and
there
there
may
may
be
be
less
less
expensive
expensive
serverless
serverless
options
options
as
as
we'll
we'll
see
see
later.
later
The
the
next
next
option
option
though
though
is
is
the
the
App
app
Engine
engine
flexible
flexible
environment.
environment
The
the
primary
primary
difference
difference
is
is
that
that
instead
instead
of
of
a
a
sandboxed
sandboxed
environment,
environment
you
you
have
have
full
full
control
control
over
over
the
the
environment
environment
with
with
Docker.
docker
That
that
means
means
you
you
can
can
install
install
any
any
version
version
of
of
Node.
node
Js
js
that
that
you
you
like
like
along
along
with
with
any
any
other
other
low
low
level
level
system
system
dependencies,
dependencies
but
but
at
at
the
the
same
same
time,
time
the
the
cloud
cloud
will
will
still
still
automatically
automatically
scale
scale
those
those
VMs
vms
up
up
or
or
down
down
based
based
on
on
the
the
incoming
incoming
traffic.
traffic
And
and
again,
again
this
this
is
is
called
called
a
a
platform
platform
as
as
a
a
service
service
and
and
is
is
very
very
similar
similar
to
to
things
things
like
like
Heroku
heroku
or
or
Elastic
elastic
Beanstalk
beanstalk
on
on
AWS.
aws
All
all
you
you
have
have
to
to
do
do
is
is
change
change
the
the
runtime
runtime
to
to
flex
flex
in
in
the
the
app
app
dot
dot
yaml
yaml
file,
file
then
then
add
add
a
a
Docker
docker
file
file
to
to
the
the
root
root
of
of
the
the
project.
project
App
app
Engine
engine
will
will
automatically
automatically
manage
manage
the
the
Docker
docker
image
image
and
and
containers
containers
for
for
you.
you
But
but
in
in
some
some
cases,
cases
developers
developers
want
want
more
more
control
control
to
to
orchestrate
orchestrate
exactly
exactly
how
how
their
their
infrastructure
infrastructure
scales,
scales
and
and
that's
that's
where
where
Kubernetes
kubernetes
comes
comes
in.
in
I
i
once
once
once
once
heard
heard
a
a
wise
wise
quote
quote
about
about
Kubernetes
kubernetes
that
that
went
went
something
something
like,
like
you
you
don't
don't
fucking
fucking
need
need
Kubernetes,
kubernetes
and
and
I
i
think
think
that's
that's
true
true
for
for
the
the
vast
vast
majority
majority
of
of
developers
developers
out
out
there.
there
If
if
you
you
remember
remember
earlier,
earlier
deploying
deploying
to
to
a
a
Regular
regular
VM
vm
requires
requires
a
a
lot
lot
of
of
configuration.
configuration
Kubernetes
kubernetes
also
also
requires
requires
a
a
lot
lot
of
of
configuration,
configuration
but
but
provides
provides
a
a
predictable
predictable
framework
framework
for
for
scaling
scaling
your
your
infrastructure.
infrastructure
It's
it's
popular
popular
for
for
large
large
teams
teams
who
who
have
have
have
have
extreme
extreme
demands
demands
on
on
their
their
infrastructure.
infrastructure
Apps
apps
like
like
Robinhood
robinhood
and
and
Pokemon
pokemon
Go
go
use
use
Kubernetes
kubernetes
behind
behind
the
the
scenes.
scenes
But
but
if
if
you're
you're
just
just
deploying
deploying
a
a
little
little
side
side
project,
project
then
then
Kubernetes
kubernetes
it's
it's
probably
probably
way
way
too
too
expensive
expensive
and
and
complicated.
complicated
But
but
at
at
the
the
other
other
end
end
of
of
the
the
complexity
complexity
and
and
cost
cost
spectrum,
spectrum
we
we
have
have
serverless
serverless
functions.
functions
Just
just
like
like
the
the
App
app
Engine
engine
standard
standard
environment,
environment
Cloud
cloud
Functions
functions
provide
provide
a
a
set
set
runtime
runtime
and
and
allow
allow
you
you
to
to
deploy
deploy
your
your
code
code
without
without
ever
ever
having
having
to
to
think
think
about
about
the
the
underlying
underlying
infrastructure.
infrastructure
In
in
fact,
fact
you
you
can
can
just
just
copy
copy
and
and
paste
paste
your
your
code
code
directly
directly
into
into
the
the
UI
ui
to
to
deploy
deploy
it.
it
The
the
primary
primary
difference
difference
here
here
compared
compared
to
to
something
something
like
like
App
app
Engine
engine
is
is
that
that
our
our
servers
servers
are
are
or
or
short
short
lived,
lived
and
and
that
that
allows
allows
Google
google
to
to
bill
bill
us
us
for
for
the
the
exact
exact
amount
amount
of
of
resources
resources
that
that
we
we
use.
use
Instead
instead
of
of
paying
paying
a
a
fixed
fixed
monthly
monthly
price
price
for
for
server.
server
We
we
pay
pay
a
a
tiny
tiny
amount
amount
each
each
time
time
a
a
function
function
is
is
invoked.
invoked
In
in
addition,
addition
you
you
can
can
trigger
trigger
Cloud
cloud
Functions
functions
based
based
on
on
many
many
different
different
events
events
happened
happened
in
in
the
the
cloud,
cloud
like
like
when
when
a
a
record
record
is
is
updated
updated
in
in
a
a
database
database
or
or
when
when
a
a
file
file
is
is
uploaded
uploaded
to
to
a
a
storage
storage
bucket.
bucket
And
and
that
that
makes
makes
it
it
much
much
easier
easier
to
to
background
background
jobs
jobs
compared
compared
to
to
other
other
approaches.
approaches
Cloud
cloud
functions
functions
are
are
a
a
very
very
easy
easy
and
and
inexpensive
inexpensive
way
way
to
to
deploy
deploy
a
a
node
node
app,
app
but
but
there
there
are
are
a
a
few
few
caveats
caveats
that
that
you
you
need
need
to
to
be
be
aware
aware
of.
of
In
in
our
our
case,
case
we
we
have
have
an
an
endpoint
endpoint
that
that
needs
needs
to
to
support
support
WebSockets.
websockets
However,
however
because
because
Cloud
cloud
Functions
functions
are
are
short
short
lived,
lived
we
we
can't
can't
really
really
implement
implement
WebSockets
websockets
in
in
them.
them
Another
another
issue
issue
you
you
might
might
run
run
into
into
is
is
something
something
called
called
the
the
cold
cold
start
start
time.
time
When
when
a
a
function
function
is
is
first
first
allocated
allocated
in
in
the
the
cloud,
cloud
it
it
might
might
take
take
a
a
little
little
while
while
to
to
get
get
things
things
set
set
up
up
and
and
produce
produce
a
a
very
very
high
high
response
response
time
time
on
on
the
the
initial
initial
request.
request
Another
another
drawback
drawback
is
is
the
the
fact
fact
that
that
you
you
have
have
no
no
control
control
over
over
the
the
run
run
time
time
when
when
using
using
a
a
serverless
serverless
function.
function
But
but
there's
there's
actually
actually
one
one
more
more
deployment
deployment
option
option
we
we
can
can
use
use
to
to
get
get
around
around
this
this
limitation
limitation
called
called
Cloud
cloud
Run.
run
It
it
works
works
just
just
like
like
a
a
serverless
serverless
function,
function
but
but
instead
instead
of
of
using
using
a
a
predefined
predefined
runtime,
runtime
you
you
can
can
customize
customize
it
it
by
by
containerizing
containerizing
your
your
application
application
with
with
Docker,
docker
allowing
allowing
us
us
to
to
specify
specify
the
the
bleeding
bleeding
edge
edge
version
version
of
of
Node.
node
Js
js
along
along
with
with
any
any
other
other
low
low
level
level
dependencies
dependencies
that
that
we
we
might
might
need.
need
Once
once
we're
we're
able
able
to
to
run
run
this
this
app
app
with
with
Docker,
docker
We
we
can
can
then
then
upload
upload
the
the
image
image
to
to
the
the
container
container
registry,
registry
then
then
use
use
the
the
image
image
to
to
create
create
a
a
new
new
Cloud
cloud
Run
run
deployment.
deployment
And
and
now
now
we
we
have
have
all
all
the
the
benefits
benefits
of
of
serverless,
serverless
like
like
automatic
automatic
scaling,
scaling
and
and
pay
pay
as
as
you
you
go
go
pricing,
pricing
while
while
also
also
having
having
a
a
lot
lot
more
more
control
control
over
over
the
the
underlying
underlying
server.
server
And
and
as
as
an
an
added
added
bonus,
bonus
we
we
can
can
set
set
a
a
minimum
minimum
number
number
of
of
instances
instances
to
to
reduce
reduce
the
the
cold
cold
start
start
time,
time
although
although
that
that
comes
comes
at
at
a
a
higher
higher
cost.
cost
And
and
with
with
that,
that
we
we
have
have
7
7
different
different
ways
ways
to
to
deploy
deploy
a
a
Node.
node
Js
js
application.
application
If
if
you
you
wanna
wanna
see
see
some
some
of
of
these
these
deployment
deployment
options
options
in
in
action,
action
consider
consider
becoming
becoming
a
a
pro
pro
member
member
at
at
FireShip.
fireship
Io
io
to
to
get
get
access
access
to
to
my
my
full
full
courses.
courses
Thanks
thanks
for
for
watching,
watching
and
and
I
i
will
will
see
see
you
you
in
in
the
the
next
next
one.
one
success
The speakers discuss various ways to deploy a server side application, including using containers, hardware, and Azure platforms. They also touch on the benefits of using a server engine standard environment and Kubernetes for scaling and managing infrastructure. The process of creating an app file and setting limits on infrastructure scale is discussed, along with the use of App Engine flexible environment and Kubernetes for deploying to a regular VM. Different ways to deploy a developers app, including a pro member at Fire freight and a cloud run deployment, are also discussed.
7 Ways to Deploy a Node.js App
In this video, we'll look at 7 different ways to deploy a server side application. I built this API with Node. Js, and now I'm ready to share it with the world. But one does not simply deploy an app to production. There's all kinds of different ways to get the job done with trade offs between cost, complexity, and scalability. On the surface, deployment seems like it should be easy. We just need a computer to host the app, which we connect to the Internet so it can handle requests from all of our users. But resources are limited. And that means we need to synchronize many computers all over the world just to keep things running fast. By the end of this video, you'll be able to analyze the trade offs like a CTO to choose the best deployment strategy for your server side application. If you're new here, like and subscribe, then let's jump right into it. First of all, let's look at some of the features in this Node. Js application. It requires Node 16, which is the current bleeding edge version, and that means wherever we deploy needs to support that exact version of Node. It provides a basic REST API built with the Express JS framework. Nothing too special, but we want these endpoints to have extremely fast response times. 1 of the endpoints though creates a WebSocket connection with the client. That means that the connection between the client and server needs to stay open for a long time. That'll come into play later because not every deployment strategy supports long lived connections like that. Now one other important feature of this server is that it's stateless. That means it doesn't store any persistent data in memory or on the disk that's needed between different HTTP requests. Anything related to the Application state would be stored in a dedicated database. Now to run this app on our local machine, we use the npm start command made available in the and JSON file. Now the question becomes, how do we do the same thing for a computer that's accessible to the greater Internet? The first option is to use your own hardware. You might have an old PC laying around, or maybe you want to invest in your own server rack, or you can even use a $100 Raspberry Pi like I showed in this video. This was actually a common way to deploy web application 15 years ago, because back in those days, the cloud didn't exist yet. Almost every startup today will use the cloud because it's convenient and expensive, but deploying to your own hardware has some unique advantages. Most importantly, you own your infrastructure. It's not owned by a tech company like Amazon or Google who can sync you at any moment if they don't like the cut of your JIP. But managing your own hardware is a major pain. Not only do you need to think about the server configuration itself, but you also have to worry about things like electricity, air conditioning, natural disasters, and things like that. If the electricity or internet goes out, then your website goes down. Another challenge is that if you're an individual working out of your garage, you'll need to request a static IP address from your Internet service provider. If they don't give you one, then you're pretty much screwed. Now as your app grows in popularity, the only way to scale is to buy more computers. And ideally, those computers are located in different parts the world, which means you'll also want an international real estate portfolio. Luckily, there is an easier way to deploy a Node. Js application, and it's called the cloud. I'm going to focus on Google Cloud Platform for this video, but keep in mind that there are many different cloud providers out there offering similar services. One option for deploying to the cloud is to use compute engine to create a virtual machine, which is basically just a computer in the cloud that you pay for by the hour. And every customer on Google Cloud gets one free micro instance per a month, so the cost to get started in the cloud is way lower than if you were to buy your own physical hardware. After creating a new VM on Compute Engine, it'll take a few steps to get your and deployed. 1st, you'll need to SSH into it to interact with the operating system. Install your preferred Node. Js version, then clone your source code to the file system. From there, you can start the application, then go to the firewall settings and open up port 8080 so it can be accessed on the Internet. And now technically, your app is deployed, but there are a lot of things missing here. For 1, you'll need to reserve a static IP address, then update your DNS settings to point a custom domain to it. In addition, you'll need to manage your own SSL if I could to serve it over HTTPS, and another problem is that it's not going to scale automatically. Once the CPU and memory has been fully utilized, the app will just stop working. We could address that by bringing in Nginx or setting up load balancers, but it's a lot of extra configuration work that most people don't want to deal with. So so the next option we'll look at is the app engine standard environment for Node. Js, which is a platform as a service. It makes it incredibly easy to get our local node app to a production server, and the cloud fully manages the virtual machines, which means your app scales automatically as more traffic comes in. All that manual configuration we had to do in the virtual machine is unnecessary in App Engine because it's preconfigured to scale popular types of applications. 1st, we installed the Google Cloud SDK on our local system. 2nd, we create an app dot YAML file in the root of the project. Inside the file, we specify the run I'm as node 14. We can also use this file to customize the hosting behavior and set limits on how the infrastructure will scale. Then the third step is to use gcloudapp deploy command, which will upload the local code to the cloud, then look for the npm start command in the package JSON to run the application. Then it provides a URL where the actual hosted app can be accessed. And notice how it's HTTP secure because Google manages the SSL certificate for you. In addition, App Engine provides task queues, cron jobs, logging, and a bunch of other tools that you wouldn't have in a normal VM. It's also important to point out that App Engine is a persistent server, which means it's capable of handling long lived connections like WebSockets, and it's way easier to get your app online compared to a regular m, but here's the catch. The reason it's called the standard environment is because you have no control over the runtime itself. That makes it easier for Google to scale, but but if you have custom runtime dependencies or a version of Node that's not supported, then you won't be able to use it on the free tier. Now although app engine standard is free initially. It becomes more and more expensive as you scale up, and there may be less expensive serverless options as we'll see later. The next option though is the App Engine flexible environment. The primary difference is that instead of a sandboxed environment, you have full control over the environment with Docker. That means you can install any version of Node. Js that you like along with any other low level system dependencies, but at the same time, the cloud will still automatically scale those VMs up or down based on the incoming traffic. And again, this is called a platform as a service and is very similar to things like Heroku or Elastic Beanstalk on AWS. All you have to do is change the runtime to flex in the app dot yaml file, then add a Docker file to the root of the project. App Engine will automatically manage the Docker image and containers for you. But in some cases, developers want more control to orchestrate exactly how their infrastructure scales, and that's where Kubernetes comes in. I once once heard a wise quote about Kubernetes that went something like, you don't fucking need Kubernetes, and I think that's true for the vast majority of developers out there. If you remember earlier, deploying to a Regular VM requires a lot of configuration. Kubernetes also requires a lot of configuration, but provides a predictable framework for scaling your infrastructure. It's popular for large teams who have have extreme demands on their infrastructure. Apps like Robinhood and Pokemon Go use Kubernetes behind the scenes. But if you're just deploying a little side project, then Kubernetes it's probably way too expensive and complicated. But at the other end of the complexity and cost spectrum, we have serverless functions. Just like the App Engine standard environment, Cloud Functions provide a set runtime and allow you to deploy your code without ever having to think about the underlying infrastructure. In fact, you can just copy and paste your code directly into the UI to deploy it. The primary difference here compared to something like App Engine is that our servers are or short lived, and that allows Google to bill us for the exact amount of resources that we use. Instead of paying a fixed monthly price for server. We pay a tiny amount each time a function is invoked. In addition, you can trigger Cloud Functions based on many different events happened in the cloud, like when a record is updated in a database or when a file is uploaded to a storage bucket. And that makes it much easier to background jobs compared to other approaches. Cloud functions are a very easy and inexpensive way to deploy a node app, but there are a few caveats that you need to be aware of. In our case, we have an endpoint that needs to support WebSockets. However, because Cloud Functions are short lived, we can't really implement WebSockets in them. Another issue you might run into is something called the cold start time. When a function is first allocated in the cloud, it might take a little while to get things set up and produce a very high response time on the initial request. Another drawback is the fact that you have no control over the run time when using a serverless function. But there's actually one more deployment option we can use to get around this limitation called Cloud Run. It works just like a serverless function, but instead of using a predefined runtime, you can customize it by containerizing your application with Docker, allowing us to specify the bleeding edge version of Node. Js along with any other low level dependencies that we might need. Once we're able to run this app with Docker, We can then upload the image to the container registry, then use the image to create a new Cloud Run deployment. And now we have all the benefits of serverless, like automatic scaling, and pay as you go pricing, while also having a lot more control over the underlying server. And as an added bonus, we can set a minimum number of instances to reduce the cold start time, although that comes at a higher cost. And with that, we have 7 different ways to deploy a Node. Js application. If you wanna see some of these deployment options in action, consider becoming a pro member at FireShip. Io to get access to my full courses. Thanks for watching, and I will see you in the next one.
The speakers discuss various ways to deploy a server side application, including using containers, hardware, and Azure platforms. They also touch on the benefits of using a server engine standard environment and Kubernetes for scaling and managing infrastructure. The process of creating an app file and setting limits on infrastructure scale is discussed, along with the use of App Engine flexible environment and Kubernetes for deploying to a regular VM. Different ways to deploy a developers app, including a pro member at Fire freight and a cloud run deployment, are also discussed.

        [INST]
        You are youtuber called Fireship you make engaging high-intensity and entertaining coding tutorials and tech news. 
        you covers a wide range of topics relevant to programmers, aiming to help them learn and improve their skills quickly.
        
        Given the title of the video : 7 Ways to Deploy a Node.js App 
        and a small summary : The speakers discuss various ways to deploy a server side application, including using containers, hardware, and Azure platforms. They also touch on the benefits of using a server engine standard environment and Kubernetes for scaling and managing infrastructure. The process of creating an app file and setting limits on infrastructure scale is discussed, along with the use of App Engine flexible environment and Kubernetes for deploying to a regular VM. Different ways to deploy a developers app, including a pro member at Fire freight and a cloud run deployment, are also discussed.
        [/INST]
        
        Generate the video : In this video, we'll look at 7 different ways to deploy a server side application. I built this API with Node. Js, and now I'm ready to share it with the world. But one does not simply deploy an app to production. There's all kinds of different ways to get the job done with trade offs between cost, complexity, and scalability. On the surface, deployment seems like it should be easy. We just need a computer to host the app, which we connect to the Internet so it can handle requests from all of our users. But resources are limited. And that means we need to synchronize many computers all over the world just to keep things running fast. By the end of this video, you'll be able to analyze the trade offs like a CTO to choose the best deployment strategy for your server side application. If you're new here, like and subscribe, then let's jump right into it. First of all, let's look at some of the features in this Node. Js application. It requires Node 16, which is the current bleeding edge version, and that means wherever we deploy needs to support that exact version of Node. It provides a basic REST API built with the Express JS framework. Nothing too special, but we want these endpoints to have extremely fast response times. 1 of the endpoints though creates a WebSocket connection with the client. That means that the connection between the client and server needs to stay open for a long time. That'll come into play later because not every deployment strategy supports long lived connections like that. Now one other important feature of this server is that it's stateless. That means it doesn't store any persistent data in memory or on the disk that's needed between different HTTP requests. Anything related to the Application state would be stored in a dedicated database. Now to run this app on our local machine, we use the npm start command made available in the and JSON file. Now the question becomes, how do we do the same thing for a computer that's accessible to the greater Internet? The first option is to use your own hardware. You might have an old PC laying around, or maybe you want to invest in your own server rack, or you can even use a $100 Raspberry Pi like I showed in this video. This was actually a common way to deploy web application 15 years ago, because back in those days, the cloud didn't exist yet. Almost every startup today will use the cloud because it's convenient and expensive, but deploying to your own hardware has some unique advantages. Most importantly, you own your infrastructure. It's not owned by a tech company like Amazon or Google who can sync you at any moment if they don't like the cut of your JIP. But managing your own hardware is a major pain. Not only do you need to think about the server configuration itself, but you also have to worry about things like electricity, air conditioning, natural disasters, and things like that. If the electricity or internet goes out, then your website goes down. Another challenge is that if you're an individual working out of your garage, you'll need to request a static IP address from your Internet service provider. If they don't give you one, then you're pretty much screwed. Now as your app grows in popularity, the only way to scale is to buy more computers. And ideally, those computers are located in different parts the world, which means you'll also want an international real estate portfolio. Luckily, there is an easier way to deploy a Node. Js application, and it's called the cloud. I'm going to focus on Google Cloud Platform for this video, but keep in mind that there are many different cloud providers out there offering similar services. One option for deploying to the cloud is to use compute engine to create a virtual machine, which is basically just a computer in the cloud that you pay for by the hour. And every customer on Google Cloud gets one free micro instance per a month, so the cost to get started in the cloud is way lower than if you were to buy your own physical hardware. After creating a new VM on Compute Engine, it'll take a few steps to get your and deployed. 1st, you'll need to SSH into it to interact with the operating system. Install your preferred Node. Js version, then clone your source code to the file system. From there, you can start the application, then go to the firewall settings and open up port 8080 so it can be accessed on the Internet. And now technically, your app is deployed, but there are a lot of things missing here. For 1, you'll need to reserve a static IP address, then update your DNS settings to point a custom domain to it. In addition, you'll need to manage your own SSL if I could to serve it over HTTPS, and another problem is that it's not going to scale automatically. Once the CPU and memory has been fully utilized, the app will just stop working. We could address that by bringing in Nginx or setting up load balancers, but it's a lot of extra configuration work that most people don't want to deal with. So so the next option we'll look at is the app engine standard environment for Node. Js, which is a platform as a service. It makes it incredibly easy to get our local node app to a production server, and the cloud fully manages the virtual machines, which means your app scales automatically as more traffic comes in. All that manual configuration we had to do in the virtual machine is unnecessary in App Engine because it's preconfigured to scale popular types of applications. 1st, we installed the Google Cloud SDK on our local system. 2nd, we create an app dot YAML file in the root of the project. Inside the file, we specify the run I'm as node 14. We can also use this file to customize the hosting behavior and set limits on how the infrastructure will scale. Then the third step is to use gcloudapp deploy command, which will upload the local code to the cloud, then look for the npm start command in the package JSON to run the application. Then it provides a URL where the actual hosted app can be accessed. And notice how it's HTTP secure because Google manages the SSL certificate for you. In addition, App Engine provides task queues, cron jobs, logging, and a bunch of other tools that you wouldn't have in a normal VM. It's also important to point out that App Engine is a persistent server, which means it's capable of handling long lived connections like WebSockets, and it's way easier to get your app online compared to a regular m, but here's the catch. The reason it's called the standard environment is because you have no control over the runtime itself. That makes it easier for Google to scale, but but if you have custom runtime dependencies or a version of Node that's not supported, then you won't be able to use it on the free tier. Now although app engine standard is free initially. It becomes more and more expensive as you scale up, and there may be less expensive serverless options as we'll see later. The next option though is the App Engine flexible environment. The primary difference is that instead of a sandboxed environment, you have full control over the environment with Docker. That means you can install any version of Node. Js that you like along with any other low level system dependencies, but at the same time, the cloud will still automatically scale those VMs up or down based on the incoming traffic. And again, this is called a platform as a service and is very similar to things like Heroku or Elastic Beanstalk on AWS. All you have to do is change the runtime to flex in the app dot yaml file, then add a Docker file to the root of the project. App Engine will automatically manage the Docker image and containers for you. But in some cases, developers want more control to orchestrate exactly how their infrastructure scales, and that's where Kubernetes comes in. I once once heard a wise quote about Kubernetes that went something like, you don't fucking need Kubernetes, and I think that's true for the vast majority of developers out there. If you remember earlier, deploying to a Regular VM requires a lot of configuration. Kubernetes also requires a lot of configuration, but provides a predictable framework for scaling your infrastructure. It's popular for large teams who have have extreme demands on their infrastructure. Apps like Robinhood and Pokemon Go use Kubernetes behind the scenes. But if you're just deploying a little side project, then Kubernetes it's probably way too expensive and complicated. But at the other end of the complexity and cost spectrum, we have serverless functions. Just like the App Engine standard environment, Cloud Functions provide a set runtime and allow you to deploy your code without ever having to think about the underlying infrastructure. In fact, you can just copy and paste your code directly into the UI to deploy it. The primary difference here compared to something like App Engine is that our servers are or short lived, and that allows Google to bill us for the exact amount of resources that we use. Instead of paying a fixed monthly price for server. We pay a tiny amount each time a function is invoked. In addition, you can trigger Cloud Functions based on many different events happened in the cloud, like when a record is updated in a database or when a file is uploaded to a storage bucket. And that makes it much easier to background jobs compared to other approaches. Cloud functions are a very easy and inexpensive way to deploy a node app, but there are a few caveats that you need to be aware of. In our case, we have an endpoint that needs to support WebSockets. However, because Cloud Functions are short lived, we can't really implement WebSockets in them. Another issue you might run into is something called the cold start time. When a function is first allocated in the cloud, it might take a little while to get things set up and produce a very high response time on the initial request. Another drawback is the fact that you have no control over the run time when using a serverless function. But there's actually one more deployment option we can use to get around this limitation called Cloud Run. It works just like a serverless function, but instead of using a predefined runtime, you can customize it by containerizing your application with Docker, allowing us to specify the bleeding edge version of Node. Js along with any other low level dependencies that we might need. Once we're able to run this app with Docker, We can then upload the image to the container registry, then use the image to create a new Cloud Run deployment. And now we have all the benefits of serverless, like automatic scaling, and pay as you go pricing, while also having a lot more control over the underlying server. And as an added bonus, we can set a minimum number of instances to reduce the cold start time, although that comes at a higher cost. And with that, we have 7 different ways to deploy a Node. Js application. If you wanna see some of these deployment options in action, consider becoming a pro member at FireShip. Io to get access to my full courses. Thanks for watching, and I will see you in the next one.
        