A common development API backend might be using the following architecture:

1. An EC2 server hosting both the backend server and the database.
2. EC2 server exposed to the interet.

How to move from this architecture to a production architecture ?

It might be tempting to directly replicate this architecture for your production environment. But, it is essential to also think of the following best practises:

1. Database backups - Production database contains business critical data and losing them will be catastrophic. Therefore, having regular backups of production data is helpful to migitate any data losses.

2. Availability of Production environment - To make sure production is highly available, we have to ensure that there are redundancies for both backend server and database. We should also ensure that the redundancies are in different availability zones.

3. Server auto-scaling - Auto Scaling ensures that production environment scales up or down when traffic increases or decreases. This ensures that servers are never overloaded and the applciation is always available.

4. Logging & Monitoring - Logging is essential to debug and troubleshoot issues in production. It is also essential to monitor the health of your servers and database. AWS provides CloudWatch for monitoring and logging. One can setup alarms to get notified when something goes wrong.

5. Security - Using VPC for your production servers and database, ensures that they are not directly accessible from the internet. Users should also have least privilege when accessing any infrastructure. (Eg. Developers not having direct access to production database)

Let’s discuss on how to think of changing your development environment into your production environment

Managed Database setup

So far, your development server is hosting your database. It is not ideal, as it becomes difficult to:

1. Manage database backups
2. Scale backend server or database server independently of the other
3. Ensuring that database environment is highly secure
4. Redundancy and scaling of database

Therefore, it is essential to use a managed database like AWS RDS that automatically does the following things for you:

1. Schedule and manage backups
2. Makesure database is up to date and has the latest security patches
3. Administration of database is easy
4. Scaling database should be straight-forward
5. Database can be easily configured to have redundancy

In this above picture, I am using a Single availability zone. This just means that there is only one database instance and it is therefore not set to be redundant.

If you want to ensure redundancy, you can setup your database to replicated across multiple availability zones (Multi A-Z)

Other things in the architecture

1. VPC - Your server and database are located in a private cloud called VPC and they can only be accessed through the API Gateway from the internet. This ensures that there is very minimal latency between your server and database. It also keeps the database and your servers secure as they cannot be accessed directly from the internet.

2. Application Load Balancer - This is the primary entry point for your servers. It distributes traffic to the two (or more) servers you have setup.

3. Amazon Route 53 - is a DNS service that sets up your DNS policies and routes users to your Application Load Balancer. This also ensures that your API users directly talks to your APIs with a domain name and not with any IP address.

Let me know what you think about the above architecture.

This blog is Part 1 of the series of blogs on moving your backend to production. Do read Part 2 to continue the series!