Infrastructure Overview

Before thinking about code of any sort, creating a website bigger than "Hello World!" requires a lot of infrastructure: it involves much more than simply a webserver. It will effectively have an entire network of systems and servers that work with each other to deliver the website.

This overview is to give you an idea of the infrastructure that is involved in running a website like this.

Flowchart Diagram

The flowchart below shows Deserted Chateau's infrastructure, which mostly resides in Amazon Web Services. This gives you an idea of the complexity of a website of this nature, but also shows many of the things you will need to set up and be familiar with (no matter which provider you use, the general concepts are going to be the same).

Diagram Notes

• The "Webserver"  items are AWS Lightsail instances. In Deserted Chateau's case, the webservers are using Bitnami LAMP stacks to serve webpages.
  
  
• SNS and SQS are used for monitoring failed email deliveries, spam notifications and so on.
  
  
• Parameter Store holds credentials for webservers and Lambda functions to use for accessing services, not e.g. user login credentials.

Webservers and Load Balancers

Starting with the obvious, you will need webservers. Usually this will mean having more than one webserver, in case one goes down for some reason, and also because past a certain amount of traffic, one webserver will no longer be enough to serve all your visitors.

Once you have more than one webserver, a load balancer is required. Unless you have a particular reason not to, it is usually worth having a load balancer set up to start with, even if it's only serving one webserver; this way, you don't have to worry about avoiding configuration pitfalls later when you do need more than one webserver, as it involves a fair bit of extra configuration to make sure traffic is routed and received correctly.

Database Servers

Storing data is something specialist servers and software are best at. You will need a database server that is designed to store and search information efficiently; your webservers, and some of your other servers, will connect to this database server to store and use information there. In particular, you will be using some form of relational SQL database (e.g. MySQL, MariaDB, PostgreSQL). 

NoSQL is VERY different from SQL!

Using non-SQL data storage (Firestore, DynamoDB, etc) will result in nightmares later: those types of databases are designed for very different use cases than normal databases, and they're not easy to query or use.

Cache servers

A cache server is critical, both for storing user sessions efficiently, and also for storing data that is commonly requested but rarely updated. For example, if your users love to search for "big juicy anime tiddies" (truly cultured users), constantly asking your database server to perform an exhaustive search of potentially millions of data records can cause a huge amount of strain on it, when the results both don't need to be exactly up-to-date and are also likely to be the same or similar.

In cases like that, a cache server is excellent for storing a copy of an operation's result for some period of time, then deleting the copy when it is too old. 

Redis is a commonly-used application which runs on cache servers.

Content Delivery Networks (CDNs)

There are two main use cases for CDNs that you will need, which are:

CDNs for static content

A content delivery network is, in simple terms, a bunch of servers around the world that you use to deliver static content to users, since it is much more efficient and fast than doing it from your webservers. 

Static content means content that doesn't need to be evaluated by a server; images, videos, and code or scripts that are only evaluated by a user's browser (such as CSS and frontend JavaScript files) are all static content. 

Your webservers are there to serve webpages, not perform complex processing tasks or serve large files. A CDN both removes this strain from your webservers, and also makes the loading of static content much faster for a user, especially on smaller websites. A user might be half a world away from your webserver, but the CDN is going to have a server much closer to their location, reducing the time taken for them to download images or other content and see them in their browser.

Depending on your website's use case, you might have several CDNs for static content. Each CDN will generally have one "origin" (the cloud storage or other place it is going to retrieve and cache information from), such as a cloud storage bucket. If you have multiple buckets for multiple purposes, you will have one CDN for each, with a different subdomain, such as cdn1.yoursite.com, cdn2.yoursite.com, or any other names you decide on.

CDNs as a website entry point

The other use of a CDN is as a main entry point for all traffic visiting your website. The purpose of this CDN is for security: by making the CDN the first point of contact for all traffic, you can use a Web Application Firewall (WAF) to screen all content reaching your CDN and thus protect your website from many common threats.

Web Application Firewall (WAF)

A WAF is essential for strengthening the security of your website. No single security system can protect against anything - in computer security, defence in depth is the prevailing view, like in most security areas: the more layers there are, the less likely something is to get past all of them.

The advantage of a WAF is that it's maintained and updated without you having to know about new security threats, and is easily configurable to quickly react to real-time events when required. 

Cloud Storage

When a user uploads content to your website (e.g. an image), you can't store it on the webserver unless you only have one webserver. Otherwise, the user would navigate to the URL for that image, and unless it was stored on every webserver you have, they might not find it there.

Instead, you will need to store images and other content in cloud storage, where it can be accessed by all of your webservers. This is also necessary to use a CDN and some other infrastructure, since otherwise they will not have one single point of access to that data.

"Serverless" Code

This doesn't actually mean the code runs without a server. What it means is that many infrastructure providers offer a service where you can run some code function you made "on demand", without having to provision a dedicated server 24/7 to sit around waiting for you to request running that code.

For various tasks, this is pretty much mandatory - keeping your own dedicated servers up 24/7 for tasks you might need to perform at any time of day is extremely inefficient, as you're paying for them even when you're not using them. Operations like resizing images, which are too computationally expensive to do on your webservers (it would slow your website to a crawl) need to be done using serverless code, for instance.

Automated Email Service

This doesn't mean it just 'sends automated emails', but rather a service that can send emails programmatically, rather than by you going to an inbox and manually composing an email.

You'll need one of these for sending things like activation emails when users sign up, and any other use case where you need to send emails to users automatically, like on particular things they signed up to get emails about. Be aware that email providers, as well as automated email service providers, require you to adhere to strict rules on how you use these services to prevent spam and dodgy emails - make sure to pay attention to what you need to do in terms of authenticating your emails and monitoring spam complaints.

Email Provider

For actual email inboxes, you will need an email provider, who may or may not be the same company that provides the automated email service above. Having an email provider will let you use email addresses with your own domain name, rather than e.g. some gmail or other address, which is good for making a website look professional.

Collaboration Tools

If you are not working alone, then collaboration tools are going to be a necessity. Here are the important ones to keep in mind.

Workspace Provider

Your workspace provider may be the same as your normal email provider for your website, but could be different. It's a distinct entry here, because even if you're working alone, some form of email provider is needed (to have emails with your own domain name for contact, queries, etc).

Most offer functions like video calls and video conferencing, calendars and scheduling etc, and it's important to have a proper paid option than relying on a free service with less functionality.

Support Provider (optional)

Depending on your use case, you might want a support provider - software that gives you the ability to have support tickets and the like in one place, and make it easier to deal with support queries when you have more than one person on a team.

It is of course possible to implement this yourself, which can come with the benefit of more consistent styling and presentation and some more customisation ability, but it's not likely to be worth the hassle in most cases.

Credentials Manager (mandatory for teams, optional for individuals)

This is not referring to internal system credentials, but user credentials - for example, managing support staff logins and the like. If you are managing any kind of team, this is a necessary security measure, to minimise the chance of a staff member's credentials being compromised and misused.