From 6c8f75bca0a846eb1406987a35092aaa7afec829 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Zsolt=20Sz=2E=20Sztup=C3=A1k?= Date: Sat, 27 Jan 2024 20:59:58 +0000 Subject: [PATCH 1/9] Add general notes for deployments For more info see https://github.com/CodeYourFuture/curriculum/pull/515 This is splitting out that PR into multiple parts. This is part 1 - the core description for deployments --- org-cyf/content/guides/deployment/_index.md | 15 +++++ .../guides/deployment/application_stack.md | 56 +++++++++++++++++++ .../deployment/deployment_strategies.md | 42 ++++++++++++++ .../guides/deployment/free_deployments.md | 45 +++++++++++++++ .../deployment/from_computers_to_services.md | 46 +++++++++++++++ 5 files changed, 204 insertions(+) create mode 100644 org-cyf/content/guides/deployment/_index.md create mode 100644 org-cyf/content/guides/deployment/application_stack.md create mode 100644 org-cyf/content/guides/deployment/deployment_strategies.md create mode 100644 org-cyf/content/guides/deployment/free_deployments.md create mode 100644 org-cyf/content/guides/deployment/from_computers_to_services.md diff --git a/org-cyf/content/guides/deployment/_index.md b/org-cyf/content/guides/deployment/_index.md new file mode 100644 index 000000000..dc495f577 --- /dev/null +++ b/org-cyf/content/guides/deployment/_index.md @@ -0,0 +1,15 @@ +--- +id: deployment +title: Deploying applications +emoji: 🖥️ +--- + +# What is deployment? + +Deploying in short is making sure the application you are developing is made available for the world wide web to see (or in case for internal systems it is at least visible to the intended audience). Without the ability to deploy the only way to show what you have done is ask others to come to your computer, and show them the work on it in person. + +{{}} +The CYF Curriculum team suggest [Netlify]({{< ref "/guides/deployment/netlify" >}}). as a free provider to use for both your frontend and backend applications, with Supabase as a free database layer for persistence. This is because among the free tier offerings they have the least amount of limitations. + +This suggestion assumes that you are interested in a fully free option, and you can accept the limitations. If you have a deployment budget for your work and/or the limitations are not acceptable you are free to look at other choices as well. +{{}} diff --git a/org-cyf/content/guides/deployment/application_stack.md b/org-cyf/content/guides/deployment/application_stack.md new file mode 100644 index 000000000..7b5ef9d83 --- /dev/null +++ b/org-cyf/content/guides/deployment/application_stack.md @@ -0,0 +1,56 @@ +--- +id: application_stack +title: The application stack +weight: 3 +emoji: 🖥️ +--- + +# The application stack + +In the previous section we talked about the fact that most full-stack web applications have multiple layers (generally at least a frontend and a backend component and some kind of persistence layer in form of a database). In this section we go through these layers and talk about how they are usually deployed. + +## Frontend + +In the curriculum we teach, frontend files are considered static. What this means is that once you deploy them, they will never change until the next deployment comes. Your `index.html`, `index.js` files, your CSS files and your image assets will always contain the same content regardless how many times they are downloaded and shown in browsers around the world. + +This makes them an ideal candidate to serve them through CDNs, Content Delivery Networks. These systems deploy your static files around the globe allowing people to access them quickly. Serving static files are fairly inexpensive, as you only need disk space and bandwidth, so a lot of companies provide this for free for small projects and you only need to pay once your user count becomes large enough. + +CloudFlare Pages and Netlify are some examples of CDN providers that have generous free tiers allowing you to host your static files with them. GitHub Pages, while not strictly considered a CDN, also allows you to host files from your repository in a simple way. + +{{}} +Do note that while the fact that frontend files are static is true for the frameworks we teach, it is not universally true for all frameworks. Web focused languages like PHP, and MVC frameworks like Ruby on Rails or Django, allow you to create dynamic frontend files. Some React frameworks also support server-side rendering which can make the frontend part of your application dynamic, and ineligible to be served through CDNs. Anything static, like CSS files or images however you can still serve through CDNs, and it is generally still a good idea to do so to improve your application's loading speed. +{{}} + +CDNs are however not the only way to deploy and serve your frontend. You can also add code to your backend server that will enable it to serve your static files. This allows you to use any of the backend providers (that support persistent deployments) to serve your frontend as well. Main benefit of this approach is that your frontend and backend parts remain closely tied together, you can for example easily deploy them at the same time making sure there are no version discrepancies between the two. However you would lose the benefits of CDNs, and although serving static files are not computationally too involved they still need to be handled, which will in turn slow down your backend. + +## Backend + +In contrast to the frontend, your backend systems are almost always considered dynamic. Every request they receive they need to generate a response on the fly based on the request and usually the contents of the database. This means deploying backends are much more involved, and this shows in free offerings as well - there are less options to host your backends for free, and the ones that are available have hefty limitations, forcing you to pay for an upgrade. + +To deploy your backend there are generally two wide categories of deployment mechanisms: persistent and serverless. + +### Persistent deployment + +In persistent deployment scenario you run your backend server all the time. This is very similar how you usually run your backend during development on your local computer. This allows you to fully utilize the features of your backend framework, including features like backend workers. Latency - the time needed for your server to respond - is usually quite low compared to serverless deployments. + +Biggest drawback is that running a server constantly is more expensive, therefore free tiers are in very limited supply. Glitch, Render and Fly.io are some providers that still offer this, but all of them have strict limitations: the first two will for example stop your server if it doesn't receive activity for a longer time. This will make your service be very-very slow whenever it needs to be restarted. + +Apart from the providers above persistent deployment is what people usually use VPS providers for, and the big players usually have a free tier available. AWS's EC2, Azure's Virtual Machines and Google's Compute Platform all have a one year time limited trial that allows you to use their slowest computer for free. However because neither of these services support automated deployments out of the box, and it is very easy to accidentally overshoot the trial package (for example by accidentally starting up a slightly larger computer than the slowest one) we don't recommend any of these options for the projects we do in the curriculum. + +### Serverless deployment + +Serverless, sometimes called on-demand, functional or lambda deployments mean that your server is not running constantly. Whenever there is a request the serverless provider will start up your backend, let it serve the request and then stop it immediately afterwards. + +Benefits of this approach is that your service doesn't consume resources unless it's used. It is usually aimed for systems that are either not used constantly, or where there are periods of high usage, which needs more resources to handle. Running your backend on-demand only is also less expensive, so there are more free options available to use. + +Drawbacks of this approach is that your server is getting started and stopped all the time, so it needs to be developed in a way to make this less of a problem. Unfortunately Express.JS is not designed with serverless operation in mind, bot there is a plugin to allow its core functions to operate. However anything that requires your system to run constantly, including global variables or backend workers will not work, and need to be replaced with an alternative. Also the constant starting and stopping is slow therefore serverless functions have a higher latency than persistent servers. + +Netlify Functions, Cloudflare Pages, Supabase Functions are some examples that have free tiers available, and big players like AWS's Lambda also provide support for this in their time limited free tier. + +## Database + +The final part of a full stack application is the persistence layer, which is usually a database, in our current curriculum likely a relational database, like Postgres. + +It's not the only kind of data store that you might need. For example if your application needs to support file uploads and you need to store those files somewhere you would need to opt in for some kind of file storage server as well, this is outside of the scope of this guide however. + +Free Postgres databases are offered by Supabase, Fly.io and Render with some limitations. Other kind of SQL databases are available from Cloudflare and are present inside the free tiers of AWS, Azure and GCP. These offerings do not follow Postgres' SQL standard we teach however, so are outside of the scope of this guide. diff --git a/org-cyf/content/guides/deployment/deployment_strategies.md b/org-cyf/content/guides/deployment/deployment_strategies.md new file mode 100644 index 000000000..f6b3a99f3 --- /dev/null +++ b/org-cyf/content/guides/deployment/deployment_strategies.md @@ -0,0 +1,42 @@ +--- +id: deployment_strategies +title: Deployment strategies +weight: 4 +emoji: 🖥️ +--- + +# Deployment strategies + +In the previous section we went through where you can deploy your application. In this guide we will go through how to do that. + +## Manual deployment + +Manual deployments are when you need to take an action yourself to get your application deployed. This can be anything from running a couple of commands to needing to press a button on a website. + +For example in the scenario where we imagined that you have both a development computer and a small server in your house, deploying your latest version manually could be following the steps below: + +1. Commit your changes and push them to the `main` branch on the development machine +2. Login onto your server computer +3. Go to the running application's directory +4. Stop the application +5. Pull the latest changes from the `main` branch +6. Run `npm i` +7. Start the application again + +Manual deployments done in a way above can be error-prone. For example if you forget to do step 7 your application will not be running at all at the end. If your provider does not support built-in automated deployments it is usually advised to create scripts that would do all of the steps above, so any time you wish the latest version to be deployed you would just need to run the script. Scripts can fail so you would still need to make sure to check the logs and see if everything went as expected. Trying to access your website after deployment is also a good way to check that everything is in order. + +## Automated deployment + +Automated deployment or Continuous deployment is whenever your code changes, the deployment flow is initiated automatically. For example any time your code ends up in the `main` branch of your GitHub repository deployment will commence automatically, and your code will end up on your servers. You can imagine this by someone automatically running the deployment script we've created above whenever your repository changes. + +Some frontend and backend providers have GitHub integration and will support automated deployments out of the box. For others, you either need to deploy manually by following a set of steps, or automate these manual steps by creating GitHub workflows manually. + +## Pull Request checks + +While automated deployments might sound scary, for example if you make a mistake in your code automated deployments would deploy that mistake automatically. There are ways to mitigate these risks by adding checks that run after each pull request is created, blocking merging if they fail. Common checks include linting, that would make sure that your code adheres to good coding conventions. Other checks that you can include are running unit, integration and end-to-end tests for each PR making sure that the code you've done passes these requirements. + +## Snapshot builds + +Another feature that helps make automated deployments less risky are snapshot builds. These are a feature of some providers where they not only deploy your `main` branch, but also deploy your other branches as well in a temporary fashion. For example if you create a new pull request from branch `new-awesome-feature` the provider will deploy this branch separately to your production environment. This will allows you, and anyone assessing your pull request to check how your changes would look like before actually merging them. + +Not all providers support snapshot builds. For the ones that do not, a common way to mitigate this is to set up two sets of servers, one called *production* while the other *staging* (other common names for this second set are *pre-production* or *sandbox*). You would then deploy to this environment first, and only after checking that it works as expected continue the deployment to *production* one. Do note that this usually requires you to set up your environment multiple times, and this will also increase the cost of your setup. diff --git a/org-cyf/content/guides/deployment/free_deployments.md b/org-cyf/content/guides/deployment/free_deployments.md new file mode 100644 index 000000000..25b6a9891 --- /dev/null +++ b/org-cyf/content/guides/deployment/free_deployments.md @@ -0,0 +1,45 @@ +--- +id: free_deployments +title: Free deployment offerings +weight: 5 +emoji: 🖥️ +--- + +# Free deployment offerings + +In this section we will showcase you some free options that allow you to deploy your application stack. We will also take note of any limitations each of the providers have. + +{{}} +The CYF Curriculum team suggest [Netlify]({{< ref "/guides/deployment/netlify" >}}). as a free provider to use for both your frontend and backend applications, with Supabase as a free database layer for persistence. This is because among the free tier offerings they have the least amount of limitations. You will need to check these however to make sure they are still suitable for your use case. + +If the limitations of Netlify and/or Supabase are not suitable, a good alternative is Fly.io. Do note it's free tier is limited to two computers, either one backend and one database, or two backends. If you have multiple projects that you want to deploy you'll need to either use a different provider, or need to pay for those. +{{}} + +## Frontend + +| Provider | Type | Deployment | Snasphots | Limitations | +|------------------|----------------------------|-----------------------|-------------------------|--------------------------------------------------------------------| +| Netlify | CDN | Automatic from GitHub | Supported, PRs | - | +| Cloudflare Pages | CDN | Automatic from GitHub | Supported, All branches | - | +| Render | CDN or Frontend served by backend | Automatic from GitHub | Supported, PRs | Backend is stopped after inactivity, startup time is slow | +| Fly.io | Frontend served by backend | Manual | None | Free tier limited to two backends, or one backend and one database | + + +## Backend + +| Provider | Type | Deployment | Snasphots | Limitations | +|----------|------------|-----------------------|----------------|-----------------------------------------------------------------------------------------------| +| Netlify | Serverless | Automatic from GitHub | Supported, PRs | Requires Express.JS serverless wrapper, does not support all Express.JS features | +| Render | Persistent | Automatic from GitHub | Supported, PRs | Backend is stopped after inactivity, startup time is slow | +| Fly.io | Persistent | Manual | None | Free tier limited to two backends, or one backend and one database. | +| Glitch | Persistent | Manual | None | Backend is stopped after inactivity, startup time is slow. Not designed for production system | +| Cloudflare Pages | Serverless | Automatic from GitHub | Supported, All branches | Does not support Express.JS serverless wrapper at all, backend needs to be written in a different framework, like Hono | + +## Database + +| Provider | Type | Integration | Limitations | +|---------------|------------------------|-----------------------------------------------------|---------------------------------------------------------------------| +| Supabase | Relational, PostgreSQL | None | Stops after one week of inactivity | +| Render | Relational, PostgreSQL | Integrates with Render based backends automatically | Gets deleted after 3 months without payment | +| Fly.io | Relational, PostgreSQL | Integrates with fly.io based backends automatically | Free tier limited to one backend and one database. Database can only be accessed from Fly.io backends. | +| Cloudflare D1 | Relational, SQLite | Integrates with Cloudflare Pages automatically | Not following the Postgres SQL standard | diff --git a/org-cyf/content/guides/deployment/from_computers_to_services.md b/org-cyf/content/guides/deployment/from_computers_to_services.md new file mode 100644 index 000000000..51dd4dd17 --- /dev/null +++ b/org-cyf/content/guides/deployment/from_computers_to_services.md @@ -0,0 +1,46 @@ +--- +id: deployment +title: From your computer to the world +weight: 2 +emoji: 🖥️ +--- + +# From your computer to the world + +While in this curriculum we are mainly going to concentrate on free deployment options to showcase your work it is important for you to understand what "making your work available for the world wide web to see" actually mean. In the following section we will go through a couple of scenarios that are building on each other to show you an idea on why deployments are done in a way they are done. + +## In-person demos + +The easiest, but least convenient way to show your work to others, is to invite them to your computer on which you have your application running. This would assume you know each of your users and trust them enough to give them access to your computer. Also this assumes your users are happy enough to come to your place physically. + +Unfortunately neither of these expectations are usually safe to make, so this option is only valid in a limited set of circumstances. Having the ability to demo your work on your computer is definitely useful in classroom settings to show others what you've done and if you have questions. This will remain a useful way during work as well, as pairing with others demoing them your work is a tried and tested way to showcase what you have done so far to your team. + +## Enabling DMZ on router + +In the previous scenario the biggest difficulty was that the users had to come to your machine physically in person to look at your website. We can avoid that if we keep your computer connected to your home broadband, and (among other updates that are outside of the scope of this guide) change the firewall settings on your router to allow connections from the outside world to reach your computer (this is usually called the DMZ option). You would then need to keep your machine turned on all the time, and make sure that the work that you have been doing is also running constantly. + +If everything goes well this makes your development computer visible to the world-wide-web and people would be able to see your website. However at any time you need to turn off or restart your machine, or you accidentally stop your running application, maybe to deliver updated to it, they would immediately lose access. Also they would always see the latest development version you are working on, which might not be something that you want to show the world yet. + +Home broadband systems are also usually not that stable, and if yours is not unlimited you would also need to check the cost of extra bandwidth. Speaking of extra costs, your electricity bill will also increase by keeping your machine running 24/7. And finally any misconfiguration in your router or computer firewall will enable keen hackers to access your internal network which can usually have serious consequences. + +## Home server + +The next idea is to outsource running your application and have a dedicated computer running your website. You could buy a second machine (this could be an inexpensive one like a Raspberry PI), and set up your router's DMZ settings to point to that instead of your development box. Let's call this second computer a **server** from now on. + +Once you install everything on it as well to mimic your desktop computer this server will then also be able to run your work the same way your development machine can run it. You would need to find a way to copy your work from the development machine to this server (we'll cover some of these in the *manual deployment* section), but at least you are free to turn off your main computer with the knowledge that your website remains up and visible to your users. + +Because your development machine and server are now running two separate versions of your codebase, you can now also always decide which version you want to run on your server, with the version running on it is usually called **production**. Your database will also be running separately, making it less likely to accidentally update something over there instead on your development one. + +## Co-location and VPS + +While this is a more valid scenario (and there are some production systems running like this), there are still a lot of security and privacy implications of running a server at your own home. The next step would be to use a so called co-location company, who are specialized in providing a place to store your server machines for a fee. This fee would, among others, cover the electricity, bandwidth and the security of the facility. Once you put your server over there you usually get remote access to your server to allow updates, but generally they will make sure that the computer is powered on 24/7 and is connected to the internet. + +The next idea is to avoid the big upfront cost of buying a full computer and just rent one. Most hosting companies have an option for you to rent a dedicated server for a monthly price. Dependent on budget this still has a hefty price tag, so after a while you might realize that your project isn't actually that resource intensive and doesn't really require a full server. + +That's where VPS (Virtual Private Server) providers come in. They allow you to rent *part* of a computer running in a virtual machine. There are lots of well known companies in this sector, like Amazon Web Services, Google Cloud Platform, Microsoft Azure, Digital Ocean, Linode or Ionos just to name a few. You might be able to get access to the slowest computer from these companies completely free on a time limited trial basis, or they can be as inexpensive as £1-2 a month. + +## As-a-service + +Running your application stack on a VPS is already a good deployment option, but not the only one. In the examples above we have been running the frontend, backend and database part of our application on the same computer. However these systems actually have different computational needs. Serving static frontend files for example need bandwidth and disk space but don't really require a fast computer or much memory. Databases on the other hand do need a lot of memory to operate efficiently. + +Therefore if you split out your work into separate layers you would be able to deploy each layer on a system that is designed for the needs of that particular layer. For example the database part can run on a dedicated DaaS (Database-as-a-service) instance, while the frontend can be served on fast CDNs (Content Delivery Networks). There are again plenty of companies providing these services, and fortunately some have free tiers available to trial them out. Some of these free tiers are generous enough that they can be used to deploy and host simple applications, and we will talk about them in more detail later. From e25d7a1787e1ecb3ff525c6a55fc7a5bb0091d90 Mon Sep 17 00:00:00 2001 From: MitchLloyd Date: Tue, 12 Mar 2024 14:14:07 +0000 Subject: [PATCH 2/9] Update _index.md --- org-cyf/content/guides/deployment/_index.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/org-cyf/content/guides/deployment/_index.md b/org-cyf/content/guides/deployment/_index.md index dc495f577..0462d701e 100644 --- a/org-cyf/content/guides/deployment/_index.md +++ b/org-cyf/content/guides/deployment/_index.md @@ -9,7 +9,7 @@ emoji: 🖥️ Deploying in short is making sure the application you are developing is made available for the world wide web to see (or in case for internal systems it is at least visible to the intended audience). Without the ability to deploy the only way to show what you have done is ask others to come to your computer, and show them the work on it in person. {{}} -The CYF Curriculum team suggest [Netlify]({{< ref "/guides/deployment/netlify" >}}). as a free provider to use for both your frontend and backend applications, with Supabase as a free database layer for persistence. This is because among the free tier offerings they have the least amount of limitations. +The CYF Curriculum team suggest [Netlify]({{< ref "/guides/deployment/deployment-netlify" >}}). as a free provider to use for both your frontend and backend applications, with Supabase as a free database layer for persistence. This is because among the free tier offerings they have the least amount of limitations. This suggestion assumes that you are interested in a fully free option, and you can accept the limitations. If you have a deployment budget for your work and/or the limitations are not acceptable you are free to look at other choices as well. {{}} From 1f345542781b87e5e70a0582165fbebe679ff211 Mon Sep 17 00:00:00 2001 From: MitchLloyd Date: Tue, 12 Mar 2024 14:15:01 +0000 Subject: [PATCH 3/9] Update free_deployments.md --- org-cyf/content/guides/deployment/free_deployments.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/org-cyf/content/guides/deployment/free_deployments.md b/org-cyf/content/guides/deployment/free_deployments.md index 25b6a9891..eea1f5cc1 100644 --- a/org-cyf/content/guides/deployment/free_deployments.md +++ b/org-cyf/content/guides/deployment/free_deployments.md @@ -10,7 +10,7 @@ emoji: 🖥️ In this section we will showcase you some free options that allow you to deploy your application stack. We will also take note of any limitations each of the providers have. {{}} -The CYF Curriculum team suggest [Netlify]({{< ref "/guides/deployment/netlify" >}}). as a free provider to use for both your frontend and backend applications, with Supabase as a free database layer for persistence. This is because among the free tier offerings they have the least amount of limitations. You will need to check these however to make sure they are still suitable for your use case. +The CYF Curriculum team suggest [Netlify]({{< ref "/guides/deployment/deployment-netlify" >}}). as a free provider to use for both your frontend and backend applications, with Supabase as a free database layer for persistence. This is because among the free tier offerings they have the least amount of limitations. You will need to check these however to make sure they are still suitable for your use case. If the limitations of Netlify and/or Supabase are not suitable, a good alternative is Fly.io. Do note it's free tier is limited to two computers, either one backend and one database, or two backends. If you have multiple projects that you want to deploy you'll need to either use a different provider, or need to pay for those. {{}} From 462336e763306efa444d360fd3185d4abbc282ba Mon Sep 17 00:00:00 2001 From: MitchLloyd Date: Tue, 12 Mar 2024 14:23:50 +0000 Subject: [PATCH 4/9] Update _index.md --- org-cyf/content/guides/deployment/_index.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/org-cyf/content/guides/deployment/_index.md b/org-cyf/content/guides/deployment/_index.md index 0462d701e..993919eca 100644 --- a/org-cyf/content/guides/deployment/_index.md +++ b/org-cyf/content/guides/deployment/_index.md @@ -9,7 +9,7 @@ emoji: 🖥️ Deploying in short is making sure the application you are developing is made available for the world wide web to see (or in case for internal systems it is at least visible to the intended audience). Without the ability to deploy the only way to show what you have done is ask others to come to your computer, and show them the work on it in person. {{}} -The CYF Curriculum team suggest [Netlify]({{< ref "/guides/deployment/deployment-netlify" >}}). as a free provider to use for both your frontend and backend applications, with Supabase as a free database layer for persistence. This is because among the free tier offerings they have the least amount of limitations. +The CYF Curriculum team suggest [Netlify Deployment guide](../deployment-netlify/index.md). as a free provider to use for both your frontend and backend applications, with Supabase as a free database layer for persistence. This is because among the free tier offerings they have the least amount of limitations. This suggestion assumes that you are interested in a fully free option, and you can accept the limitations. If you have a deployment budget for your work and/or the limitations are not acceptable you are free to look at other choices as well. {{}} From 487e844f100c356919b995ec678856d0bdd4b0cb Mon Sep 17 00:00:00 2001 From: MitchLloyd Date: Tue, 12 Mar 2024 14:24:36 +0000 Subject: [PATCH 5/9] correct link to the netlify deployment guide --- org-cyf/content/guides/deployment/free_deployments.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/org-cyf/content/guides/deployment/free_deployments.md b/org-cyf/content/guides/deployment/free_deployments.md index eea1f5cc1..385e2a2c4 100644 --- a/org-cyf/content/guides/deployment/free_deployments.md +++ b/org-cyf/content/guides/deployment/free_deployments.md @@ -10,7 +10,7 @@ emoji: 🖥️ In this section we will showcase you some free options that allow you to deploy your application stack. We will also take note of any limitations each of the providers have. {{}} -The CYF Curriculum team suggest [Netlify]({{< ref "/guides/deployment/deployment-netlify" >}}). as a free provider to use for both your frontend and backend applications, with Supabase as a free database layer for persistence. This is because among the free tier offerings they have the least amount of limitations. You will need to check these however to make sure they are still suitable for your use case. +The CYF Curriculum team suggest [Netlify Deployment guide](../deployment-netlify/index.md). as a free provider to use for both your frontend and backend applications, with Supabase as a free database layer for persistence. This is because among the free tier offerings they have the least amount of limitations. You will need to check these however to make sure they are still suitable for your use case. If the limitations of Netlify and/or Supabase are not suitable, a good alternative is Fly.io. Do note it's free tier is limited to two computers, either one backend and one database, or two backends. If you have multiple projects that you want to deploy you'll need to either use a different provider, or need to pay for those. {{}} From 759640a3a89d305a1c038869d90aef21511d1e08 Mon Sep 17 00:00:00 2001 From: MitchLloyd Date: Tue, 12 Mar 2024 14:49:42 +0000 Subject: [PATCH 6/9] Update application_stack.md --- .../guides/deployment/application_stack.md | 32 +++++++++---------- 1 file changed, 16 insertions(+), 16 deletions(-) diff --git a/org-cyf/content/guides/deployment/application_stack.md b/org-cyf/content/guides/deployment/application_stack.md index 7b5ef9d83..fcaaa8d2a 100644 --- a/org-cyf/content/guides/deployment/application_stack.md +++ b/org-cyf/content/guides/deployment/application_stack.md @@ -7,50 +7,50 @@ emoji: 🖥️ # The application stack -In the previous section we talked about the fact that most full-stack web applications have multiple layers (generally at least a frontend and a backend component and some kind of persistence layer in form of a database). In this section we go through these layers and talk about how they are usually deployed. +In the previous section, we talked about the fact that most full-stack web applications have multiple layers (generally at least a frontend and a backend component and some kind of persistence layer in the form of a database). In this section, we go through these layers and talk about how they are usually deployed. ## Frontend -In the curriculum we teach, frontend files are considered static. What this means is that once you deploy them, they will never change until the next deployment comes. Your `index.html`, `index.js` files, your CSS files and your image assets will always contain the same content regardless how many times they are downloaded and shown in browsers around the world. +In the curriculum we teach, frontend files are considered static. What this means is that once you deploy them, they will never change until the next deployment comes. Your `index.html`, `index.js` files, your CSS files and your image assets will always contain the same content regardless of how many times they are downloaded and shown in browsers around the world. -This makes them an ideal candidate to serve them through CDNs, Content Delivery Networks. These systems deploy your static files around the globe allowing people to access them quickly. Serving static files are fairly inexpensive, as you only need disk space and bandwidth, so a lot of companies provide this for free for small projects and you only need to pay once your user count becomes large enough. +This makes them an ideal candidate to serve them through CDNs, Content Delivery Networks. These systems deploy your static files around the globe allowing people to access them quickly. Serving static files is fairly inexpensive, as you only need disk space and bandwidth, so a lot of companies provide this for free for small projects and you only need to pay once your user count becomes large enough. -CloudFlare Pages and Netlify are some examples of CDN providers that have generous free tiers allowing you to host your static files with them. GitHub Pages, while not strictly considered a CDN, also allows you to host files from your repository in a simple way. +CloudFlare Pages and Netlify are some examples of CDN providers that have generous free tiers allowing you to host your static files with them. GitHub Pages, while not strictly considered a CDN, also allows you to host files from your repository simply. {{}} -Do note that while the fact that frontend files are static is true for the frameworks we teach, it is not universally true for all frameworks. Web focused languages like PHP, and MVC frameworks like Ruby on Rails or Django, allow you to create dynamic frontend files. Some React frameworks also support server-side rendering which can make the frontend part of your application dynamic, and ineligible to be served through CDNs. Anything static, like CSS files or images however you can still serve through CDNs, and it is generally still a good idea to do so to improve your application's loading speed. +Do note that while the fact that frontend files are static is true for the frameworks we teach, it is not universally true for all frameworks. Web-focused languages like PHP, and MVC frameworks like Ruby on Rails or Django, allow you to create dynamic frontend files. Some React frameworks also support server-side rendering which can make the frontend part of your application dynamic, and ineligible to be served through CDNs. Anything static, like CSS files or images however you can still serve through CDNs, and it is generally still a good idea to do so to improve your application's loading speed. {{}} -CDNs are however not the only way to deploy and serve your frontend. You can also add code to your backend server that will enable it to serve your static files. This allows you to use any of the backend providers (that support persistent deployments) to serve your frontend as well. Main benefit of this approach is that your frontend and backend parts remain closely tied together, you can for example easily deploy them at the same time making sure there are no version discrepancies between the two. However you would lose the benefits of CDNs, and although serving static files are not computationally too involved they still need to be handled, which will in turn slow down your backend. +CDNs are however not the only way to deploy and serve your frontend. You can also add code to your backend server that will enable it to serve your static files. This allows you to use any of the backend providers (that support persistent deployments) to serve your frontend as well. The main benefit of this approach is that your frontend and backend parts remain closely tied together, you can for example easily deploy them at the same time making sure there are no version discrepancies between the two. However you would lose the benefits of CDNs, and although serving static files are not computationally too involved they still need to be handled, which will in turn slow down your backend. ## Backend -In contrast to the frontend, your backend systems are almost always considered dynamic. Every request they receive they need to generate a response on the fly based on the request and usually the contents of the database. This means deploying backends are much more involved, and this shows in free offerings as well - there are less options to host your backends for free, and the ones that are available have hefty limitations, forcing you to pay for an upgrade. +In contrast to the frontend, your backend systems are almost always considered dynamic. Every request they receive they need to generate a response on the fly based on the request and usually the contents of the database. This means deploying backends are much more involved, and this shows in free offerings as well - there are fewer options to host your backends for free, and the available ones have hefty limitations, forcing you to pay for an upgrade. To deploy your backend there are generally two wide categories of deployment mechanisms: persistent and serverless. ### Persistent deployment -In persistent deployment scenario you run your backend server all the time. This is very similar how you usually run your backend during development on your local computer. This allows you to fully utilize the features of your backend framework, including features like backend workers. Latency - the time needed for your server to respond - is usually quite low compared to serverless deployments. +In a persistent deployment scenario, you run your backend server all the time. This is very similar to how you usually run your backend during development on your local computer. This allows you to fully utilize the features of your backend framework, including features like backend workers. Latency - the time needed for your server to respond - is usually quite low compared to serverless deployments. -Biggest drawback is that running a server constantly is more expensive, therefore free tiers are in very limited supply. Glitch, Render and Fly.io are some providers that still offer this, but all of them have strict limitations: the first two will for example stop your server if it doesn't receive activity for a longer time. This will make your service be very-very slow whenever it needs to be restarted. +The biggest drawback is that running a server constantly is more expensive, therefore free tiers are in very limited supply. Glitch, Render and Fly.io are some providers that still offer this, but all of them have strict limitations: the first two will for example stop your server if it doesn't receive activity for a longer time. This will make your service very slow whenever it needs to be restarted. -Apart from the providers above persistent deployment is what people usually use VPS providers for, and the big players usually have a free tier available. AWS's EC2, Azure's Virtual Machines and Google's Compute Platform all have a one year time limited trial that allows you to use their slowest computer for free. However because neither of these services support automated deployments out of the box, and it is very easy to accidentally overshoot the trial package (for example by accidentally starting up a slightly larger computer than the slowest one) we don't recommend any of these options for the projects we do in the curriculum. +Apart from the providers above persistent deployment is what people usually use VPS providers for, and the big players usually have a free tier available. AWS's EC2, Azure's Virtual Machines and Google's Compute Platform all have a one-year time-limited trial that allows you to use their slowest computer for free. However because neither of these services supports automated deployments out of the box, and it is very easy to accidentally overshoot the trial package (for example by accidentally starting up a slightly larger computer than the slowest one) we don't recommend any of these options for the projects we do in the curriculum. ### Serverless deployment -Serverless, sometimes called on-demand, functional or lambda deployments mean that your server is not running constantly. Whenever there is a request the serverless provider will start up your backend, let it serve the request and then stop it immediately afterwards. +Serverless, sometimes called on-demand, functional or lambda deployments means that your server is not running constantly. Whenever there is a request the serverless provider will start up your backend, let it serve the request and then stop it immediately afterward. -Benefits of this approach is that your service doesn't consume resources unless it's used. It is usually aimed for systems that are either not used constantly, or where there are periods of high usage, which needs more resources to handle. Running your backend on-demand only is also less expensive, so there are more free options available to use. +Benefits of this approach are that your service doesn't consume resources unless it's used. It is usually aimed for systems that are either not used constantly, or where there are periods of high usage, which needs more resources to handle. Running your backend on-demand only is also less expensive, so there are more free options available to use. -Drawbacks of this approach is that your server is getting started and stopped all the time, so it needs to be developed in a way to make this less of a problem. Unfortunately Express.JS is not designed with serverless operation in mind, bot there is a plugin to allow its core functions to operate. However anything that requires your system to run constantly, including global variables or backend workers will not work, and need to be replaced with an alternative. Also the constant starting and stopping is slow therefore serverless functions have a higher latency than persistent servers. +The drawback of this approach is that your server is getting started and stopped all the time, so it needs to be developed in a way to make this less of a problem. Unfortunately, Express.JS is not designed with serverless operation in mind, but there is a plugin to allow its core functions to operate. However anything that requires your system to run constantly, including global variables or backend workers will not work and need to be replaced with an alternative. The constant starting and stopping is slow; therefore serverless functions have a higher latency than persistent servers. -Netlify Functions, Cloudflare Pages, Supabase Functions are some examples that have free tiers available, and big players like AWS's Lambda also provide support for this in their time limited free tier. +Netlify Functions, Cloudflare Pages, Supabase Functions are some examples that have free tiers available, and big players like AWS's Lambda also provide support for this in their time-limited free tier. ## Database The final part of a full stack application is the persistence layer, which is usually a database, in our current curriculum likely a relational database, like Postgres. -It's not the only kind of data store that you might need. For example if your application needs to support file uploads and you need to store those files somewhere you would need to opt in for some kind of file storage server as well, this is outside of the scope of this guide however. +It's not the only kind of data store that you might need. For example, if your application needs to support file uploads and you need to store those files somewhere you would need to opt in for some kind of file storage server as well, this is outside of the scope of this guide however. -Free Postgres databases are offered by Supabase, Fly.io and Render with some limitations. Other kind of SQL databases are available from Cloudflare and are present inside the free tiers of AWS, Azure and GCP. These offerings do not follow Postgres' SQL standard we teach however, so are outside of the scope of this guide. +Free Postgres databases are offered by Supabase, Fly.io and Render with some limitations. Other kinds of SQL databases are available from Cloudflare and are present inside the free tiers of AWS, Azure and GCP. These offerings do not follow Postgres' SQL standard, however, so are outside of the scope of this guide. From 6de09964ede74b42f67c78c4c19851f34da0ab8f Mon Sep 17 00:00:00 2001 From: MitchLloyd Date: Tue, 12 Mar 2024 14:50:14 +0000 Subject: [PATCH 7/9] Fix grammar in deployment_strategies.md --- .../guides/deployment/deployment_strategies.md | 16 ++++++++-------- 1 file changed, 8 insertions(+), 8 deletions(-) diff --git a/org-cyf/content/guides/deployment/deployment_strategies.md b/org-cyf/content/guides/deployment/deployment_strategies.md index f6b3a99f3..90883add1 100644 --- a/org-cyf/content/guides/deployment/deployment_strategies.md +++ b/org-cyf/content/guides/deployment/deployment_strategies.md @@ -7,11 +7,11 @@ emoji: 🖥️ # Deployment strategies -In the previous section we went through where you can deploy your application. In this guide we will go through how to do that. +In the previous section, we went through where you can deploy your application. In this guide, we will go through how to do that. ## Manual deployment -Manual deployments are when you need to take an action yourself to get your application deployed. This can be anything from running a couple of commands to needing to press a button on a website. +Manual deployments are when you need to take action yourself to get your application deployed. This can be anything from running a couple of commands to needing to press a button on a website. For example in the scenario where we imagined that you have both a development computer and a small server in your house, deploying your latest version manually could be following the steps below: @@ -23,20 +23,20 @@ For example in the scenario where we imagined that you have both a development c 6. Run `npm i` 7. Start the application again -Manual deployments done in a way above can be error-prone. For example if you forget to do step 7 your application will not be running at all at the end. If your provider does not support built-in automated deployments it is usually advised to create scripts that would do all of the steps above, so any time you wish the latest version to be deployed you would just need to run the script. Scripts can fail so you would still need to make sure to check the logs and see if everything went as expected. Trying to access your website after deployment is also a good way to check that everything is in order. +Manual deployments done in the way above can be error-prone. For example, if you forget to do step 7 your application will not be running at all at the end. If your provider does not support built-in automated deployments it is usually advised to create scripts that would do all of the steps above, so any time you wish the latest version to be deployed you would just need to run the script. Scripts can fail so you would still need to make sure to check the logs and see if everything went as expected. Trying to access your website after deployment is also a good way to check that everything is in order. ## Automated deployment -Automated deployment or Continuous deployment is whenever your code changes, the deployment flow is initiated automatically. For example any time your code ends up in the `main` branch of your GitHub repository deployment will commence automatically, and your code will end up on your servers. You can imagine this by someone automatically running the deployment script we've created above whenever your repository changes. +Automated deployment or Continuous deployment is whenever your code changes, the deployment flow is initiated automatically. For example, any time your code ends up in the `main` branch of your GitHub repository deployment will commence automatically, and your code will end up on your servers. You can imagine this by someone automatically running the deployment script we've created above whenever your repository changes. -Some frontend and backend providers have GitHub integration and will support automated deployments out of the box. For others, you either need to deploy manually by following a set of steps, or automate these manual steps by creating GitHub workflows manually. +Some frontend and backend providers have GitHub integration and will support automated deployments out of the box. For others, you either need to deploy manually by following a set of steps or automate these manual steps by creating GitHub workflows manually. ## Pull Request checks -While automated deployments might sound scary, for example if you make a mistake in your code automated deployments would deploy that mistake automatically. There are ways to mitigate these risks by adding checks that run after each pull request is created, blocking merging if they fail. Common checks include linting, that would make sure that your code adheres to good coding conventions. Other checks that you can include are running unit, integration and end-to-end tests for each PR making sure that the code you've done passes these requirements. +While automated deployments might sound scary, for example if you make a mistake in your code automated deployments would deploy that mistake automatically. There are ways to mitigate these risks by adding checks that run after each pull request is created, blocking merging if they fail. Common checks include linting, which would make sure that your code adheres to good coding conventions. Other checks that you can include are running unit, integration and end-to-end tests for each PR making sure that the code you've done passes these requirements. ## Snapshot builds -Another feature that helps make automated deployments less risky are snapshot builds. These are a feature of some providers where they not only deploy your `main` branch, but also deploy your other branches as well in a temporary fashion. For example if you create a new pull request from branch `new-awesome-feature` the provider will deploy this branch separately to your production environment. This will allows you, and anyone assessing your pull request to check how your changes would look like before actually merging them. +Another feature that helps make automated deployments less risky is snapshot builds. These are a feature of some providers where they not only deploy your `main` branch but also deploy your other branches as well in a temporary fashion. For example, if you create a new pull request from branch `new-awesome-feature` the provider will deploy this branch separately to your production environment. This will allow you, and anyone assessing your pull request to check how your changes would look like before actually merging them. -Not all providers support snapshot builds. For the ones that do not, a common way to mitigate this is to set up two sets of servers, one called *production* while the other *staging* (other common names for this second set are *pre-production* or *sandbox*). You would then deploy to this environment first, and only after checking that it works as expected continue the deployment to *production* one. Do note that this usually requires you to set up your environment multiple times, and this will also increase the cost of your setup. +Not all providers support snapshot builds. For the ones that do not, a common way to mitigate this is to set up two sets of servers, one called _production_ and the other _staging_ (other common names for this second set are _pre-production_ or _sandbox_). You would then deploy to this environment first, and only after checking that it works as expected continue the deployment to _production_ one. Do note that this usually requires you to set up your environment multiple times, and this will also increase the cost of your setup. From 56462e025e0e50fbdfd5ad1a55cdd1cd68df5312 Mon Sep 17 00:00:00 2001 From: MitchLloyd Date: Tue, 12 Mar 2024 14:50:43 +0000 Subject: [PATCH 8/9] Fix grammar in free_deployments.md --- .../guides/deployment/free_deployments.md | 39 +++++++++---------- 1 file changed, 19 insertions(+), 20 deletions(-) diff --git a/org-cyf/content/guides/deployment/free_deployments.md b/org-cyf/content/guides/deployment/free_deployments.md index 385e2a2c4..066349724 100644 --- a/org-cyf/content/guides/deployment/free_deployments.md +++ b/org-cyf/content/guides/deployment/free_deployments.md @@ -7,39 +7,38 @@ emoji: 🖥️ # Free deployment offerings -In this section we will showcase you some free options that allow you to deploy your application stack. We will also take note of any limitations each of the providers have. +In this section, we will showcase some free options that allow you to deploy your application stack. We will also take note of any limitations each of the providers have. {{}} -The CYF Curriculum team suggest [Netlify Deployment guide](../deployment-netlify/index.md). as a free provider to use for both your frontend and backend applications, with Supabase as a free database layer for persistence. This is because among the free tier offerings they have the least amount of limitations. You will need to check these however to make sure they are still suitable for your use case. +The CYF Curriculum team suggests Netlify({{< ref "/guides/deployment/netlify" >}}). as a free provider to use for both your frontend and backend applications, with Supabase as a free database layer for persistence. This is because among the free tier offerings they have the least amount of limitations. You will need to check these however to make sure they are still suitable for your use case. -If the limitations of Netlify and/or Supabase are not suitable, a good alternative is Fly.io. Do note it's free tier is limited to two computers, either one backend and one database, or two backends. If you have multiple projects that you want to deploy you'll need to either use a different provider, or need to pay for those. +If the limitations of Netlify and/or Supabase are not suitable, a good alternative is Fly.io. Do note its free tier is limited to two computers, either one backend and one database, or two backends. If you have multiple projects that you want to deploy you'll need to either use a different provider or need to pay for those. {{}} ## Frontend -| Provider | Type | Deployment | Snasphots | Limitations | -|------------------|----------------------------|-----------------------|-------------------------|--------------------------------------------------------------------| -| Netlify | CDN | Automatic from GitHub | Supported, PRs | - | -| Cloudflare Pages | CDN | Automatic from GitHub | Supported, All branches | - | +| Provider | Type | Deployment | Snasphots | Limitations | +| ---------------- | --------------------------------- | --------------------- | ----------------------- | ------------------------------------------------------------------ | +| Netlify | CDN | Automatic from GitHub | Supported, PRs | - | +| Cloudflare Pages | CDN | Automatic from GitHub | Supported, All branches | - | | Render | CDN or Frontend served by backend | Automatic from GitHub | Supported, PRs | Backend is stopped after inactivity, startup time is slow | -| Fly.io | Frontend served by backend | Manual | None | Free tier limited to two backends, or one backend and one database | - +| Fly.io | Frontend served by backend | Manual | None | Free tier limited to two backends, or one backend and one database | ## Backend -| Provider | Type | Deployment | Snasphots | Limitations | -|----------|------------|-----------------------|----------------|-----------------------------------------------------------------------------------------------| -| Netlify | Serverless | Automatic from GitHub | Supported, PRs | Requires Express.JS serverless wrapper, does not support all Express.JS features | -| Render | Persistent | Automatic from GitHub | Supported, PRs | Backend is stopped after inactivity, startup time is slow | -| Fly.io | Persistent | Manual | None | Free tier limited to two backends, or one backend and one database. | -| Glitch | Persistent | Manual | None | Backend is stopped after inactivity, startup time is slow. Not designed for production system | +| Provider | Type | Deployment | Snasphots | Limitations | +| ---------------- | ---------- | --------------------- | ----------------------- | ---------------------------------------------------------------------------------------------------------------------- | +| Netlify | Serverless | Automatic from GitHub | Supported, PRs | Requires Express.JS serverless wrapper, does not support all Express.JS features | +| Render | Persistent | Automatic from GitHub | Supported, PRs | Backend is stopped after inactivity, startup time is slow | +| Fly.io | Persistent | Manual | None | Free tier limited to two backends, or one backend and one database. | +| Glitch | Persistent | Manual | None | Backend is stopped after inactivity, startup time is slow. Not designed for production system | | Cloudflare Pages | Serverless | Automatic from GitHub | Supported, All branches | Does not support Express.JS serverless wrapper at all, backend needs to be written in a different framework, like Hono | ## Database -| Provider | Type | Integration | Limitations | -|---------------|------------------------|-----------------------------------------------------|---------------------------------------------------------------------| -| Supabase | Relational, PostgreSQL | None | Stops after one week of inactivity | -| Render | Relational, PostgreSQL | Integrates with Render based backends automatically | Gets deleted after 3 months without payment | +| Provider | Type | Integration | Limitations | +| ------------- | ---------------------- | --------------------------------------------------- | ------------------------------------------------------------------------------------------------------ | +| Supabase | Relational, PostgreSQL | None | Stops after one week of inactivity | +| Render | Relational, PostgreSQL | Integrates with Render based backends automatically | Gets deleted after 3 months without payment | | Fly.io | Relational, PostgreSQL | Integrates with fly.io based backends automatically | Free tier limited to one backend and one database. Database can only be accessed from Fly.io backends. | -| Cloudflare D1 | Relational, SQLite | Integrates with Cloudflare Pages automatically | Not following the Postgres SQL standard | +| Cloudflare D1 | Relational, SQLite | Integrates with Cloudflare Pages automatically | Not following the Postgres SQL standard | From 91ba94d2388b70074bde1278d09175c92c98ca4d Mon Sep 17 00:00:00 2001 From: MitchLloyd Date: Tue, 12 Mar 2024 14:51:12 +0000 Subject: [PATCH 9/9] Fix grammar in from_computers_to_services.md --- .../deployment/from_computers_to_services.md | 26 +++++++++---------- 1 file changed, 13 insertions(+), 13 deletions(-) diff --git a/org-cyf/content/guides/deployment/from_computers_to_services.md b/org-cyf/content/guides/deployment/from_computers_to_services.md index 51dd4dd17..137fc93d4 100644 --- a/org-cyf/content/guides/deployment/from_computers_to_services.md +++ b/org-cyf/content/guides/deployment/from_computers_to_services.md @@ -7,40 +7,40 @@ emoji: 🖥️ # From your computer to the world -While in this curriculum we are mainly going to concentrate on free deployment options to showcase your work it is important for you to understand what "making your work available for the world wide web to see" actually mean. In the following section we will go through a couple of scenarios that are building on each other to show you an idea on why deployments are done in a way they are done. +While in this curriculum we are mainly going to concentrate on free deployment options to showcase your work you need to understand what "making your work available for the world wide web to see" actually means. In the following section, we will go through a couple of scenarios that are building on each other to show you an idea of why deployments are done in the way they are done. ## In-person demos -The easiest, but least convenient way to show your work to others, is to invite them to your computer on which you have your application running. This would assume you know each of your users and trust them enough to give them access to your computer. Also this assumes your users are happy enough to come to your place physically. +The easiest, but least convenient way to show your work to others, is to invite them to your computer on which you have your application running. This would assume you know each of your users and trust them enough to give them access to your computer. Also, this assumes your users are happy enough to come to your place physically. -Unfortunately neither of these expectations are usually safe to make, so this option is only valid in a limited set of circumstances. Having the ability to demo your work on your computer is definitely useful in classroom settings to show others what you've done and if you have questions. This will remain a useful way during work as well, as pairing with others demoing them your work is a tried and tested way to showcase what you have done so far to your team. +Unfortunately, neither of these expectations is usually safe to make, so this option is only valid in a limited set of circumstances. Having the ability to demo your work on your computer is useful in classroom settings to show others what you've done and if you have questions. This will remain a useful way during work as well, as pairing with others and demoing them your work is a tried and tested way to showcase what you have done so far to your team. ## Enabling DMZ on router -In the previous scenario the biggest difficulty was that the users had to come to your machine physically in person to look at your website. We can avoid that if we keep your computer connected to your home broadband, and (among other updates that are outside of the scope of this guide) change the firewall settings on your router to allow connections from the outside world to reach your computer (this is usually called the DMZ option). You would then need to keep your machine turned on all the time, and make sure that the work that you have been doing is also running constantly. +In the previous scenario, the biggest difficulty was that the users had to come to your machine physically in person to look at your website. We can avoid that if we keep your computer connected to your home broadband, and (among other updates that are outside of the scope of this guide) change the firewall settings on your router to allow connections from the outside world to reach your computer (this is usually called the DMZ option). You would then need to keep your machine turned on all the time, and make sure that the work that you have been doing is also running constantly. -If everything goes well this makes your development computer visible to the world-wide-web and people would be able to see your website. However at any time you need to turn off or restart your machine, or you accidentally stop your running application, maybe to deliver updated to it, they would immediately lose access. Also they would always see the latest development version you are working on, which might not be something that you want to show the world yet. +If everything goes well this makes your development computer visible to the world-wide-web and people would be able to see your website. However at any time you need to turn off or restart your machine, or you accidentally stop your running application, maybe to deliver updates to it, they would immediately lose access. Also, they would always see the latest development version you are working on, which might not be something that you want to show the world yet. -Home broadband systems are also usually not that stable, and if yours is not unlimited you would also need to check the cost of extra bandwidth. Speaking of extra costs, your electricity bill will also increase by keeping your machine running 24/7. And finally any misconfiguration in your router or computer firewall will enable keen hackers to access your internal network which can usually have serious consequences. +Home broadband systems are also usually not that stable, and if yours is not unlimited you would also need to check the cost of extra bandwidth. Speaking of extra costs, your electricity bill will also increase by keeping your machine running 24/7. And finally, any misconfiguration in your router or computer firewall will enable keen hackers to access your internal network which can usually have serious consequences. ## Home server The next idea is to outsource running your application and have a dedicated computer running your website. You could buy a second machine (this could be an inexpensive one like a Raspberry PI), and set up your router's DMZ settings to point to that instead of your development box. Let's call this second computer a **server** from now on. -Once you install everything on it as well to mimic your desktop computer this server will then also be able to run your work the same way your development machine can run it. You would need to find a way to copy your work from the development machine to this server (we'll cover some of these in the *manual deployment* section), but at least you are free to turn off your main computer with the knowledge that your website remains up and visible to your users. +Once you install everything on it as well to mimic your desktop computer this server will then also be able to run your work the same way your development machine can run it. You would need to find a way to copy your work from the development machine to this server (we'll cover some of these in the _manual deployment_ section), but at least you are free to turn off your main computer with the knowledge that your website remains up and visible to your users. -Because your development machine and server are now running two separate versions of your codebase, you can now also always decide which version you want to run on your server, with the version running on it is usually called **production**. Your database will also be running separately, making it less likely to accidentally update something over there instead on your development one. +Because your development machine and server are now running two separate versions of your codebase, you can now also always decide which version you want to run on your server, with the version running on it is usually called **production**. Your database will also be running separately, making it less likely to accidentally update something over there instead of on your development one. ## Co-location and VPS -While this is a more valid scenario (and there are some production systems running like this), there are still a lot of security and privacy implications of running a server at your own home. The next step would be to use a so called co-location company, who are specialized in providing a place to store your server machines for a fee. This fee would, among others, cover the electricity, bandwidth and the security of the facility. Once you put your server over there you usually get remote access to your server to allow updates, but generally they will make sure that the computer is powered on 24/7 and is connected to the internet. +While this is a more valid scenario (and some production systems are running like this), there are still a lot of security and privacy implications of running a server at your own home. The next step would be to use a so-called co-location company, who are specializes in providing a place to store your server machines for a fee. This fee would, among others, cover the electricity, bandwidth and the security of the facility. Once you put your server over there you usually get remote access to your server to allow updates, but generally, they will make sure that the computer is powered on 24/7 and is connected to the internet. -The next idea is to avoid the big upfront cost of buying a full computer and just rent one. Most hosting companies have an option for you to rent a dedicated server for a monthly price. Dependent on budget this still has a hefty price tag, so after a while you might realize that your project isn't actually that resource intensive and doesn't really require a full server. +The next idea is to avoid the big upfront cost of buying a full computer and just rent one. Most hosting companies have an option for you to rent a dedicated server for a monthly price. Depending on budget this still has a hefty price tag, so after a while, you might realize that your project isn't actually that resource intensive and doesn't require a full server. -That's where VPS (Virtual Private Server) providers come in. They allow you to rent *part* of a computer running in a virtual machine. There are lots of well known companies in this sector, like Amazon Web Services, Google Cloud Platform, Microsoft Azure, Digital Ocean, Linode or Ionos just to name a few. You might be able to get access to the slowest computer from these companies completely free on a time limited trial basis, or they can be as inexpensive as £1-2 a month. +That's where VPS (Virtual Private Server) providers come in. They allow you to rent _part_ of a computer running in a virtual machine. There are lots of well-known companies in this sector, like Amazon Web Services, Google Cloud Platform, Microsoft Azure, Digital Ocean, Linode or Ionos just to name a few. You might be able to get access to the slowest computer from these companies completely free on a time-limited trial basis, or they can be as inexpensive as £1-2 a month. ## As-a-service -Running your application stack on a VPS is already a good deployment option, but not the only one. In the examples above we have been running the frontend, backend and database part of our application on the same computer. However these systems actually have different computational needs. Serving static frontend files for example need bandwidth and disk space but don't really require a fast computer or much memory. Databases on the other hand do need a lot of memory to operate efficiently. +Running your application stack on a VPS is already a good deployment option, but not the only one. In the examples above we have been running the frontend, backend and database part of our application on the same computer. However, these systems actually have different computational needs. Serving static frontend files for example needs bandwidth and disk space but doesn't really require a fast computer or much memory. Databases on the other hand do need a lot of memory to operate efficiently. -Therefore if you split out your work into separate layers you would be able to deploy each layer on a system that is designed for the needs of that particular layer. For example the database part can run on a dedicated DaaS (Database-as-a-service) instance, while the frontend can be served on fast CDNs (Content Delivery Networks). There are again plenty of companies providing these services, and fortunately some have free tiers available to trial them out. Some of these free tiers are generous enough that they can be used to deploy and host simple applications, and we will talk about them in more detail later. +Therefore if you split out your work into separate layers you would be able to deploy each layer on a system that is designed for the needs of that particular layer. For example, the database part can run on a dedicated DaaS (Database-as-a-service) instance, while the frontend can be served on fast CDNs (Content Delivery Networks). There are again plenty of companies providing these services, and fortunately, some have free tiers available to trial them out. Some of these free tiers are generous enough that they can be used to deploy and host simple applications, and we will talk about them in more detail later.