This article was written as a reply to @veekthur on the thread: Which Hosting company would you recommend for a music sharing/streaming website. The reply became too long so I decided to create a new topic for it so that others can easily discover it.
AWS is a behemoth of cloud services enabling millions of services around the world. These are my “personal” recommendations from my experience so far with AWS. First of all, let me say that I’m an AWS junkie. AWS offers more than I can even consume. I simply don’t have any reason to look elsewhere anymore.
I recommend AWS EC2. With EC2, you can spin off your own “free-for-a-year” web host within 2 minutes. EC2 comes with lots of preconfigured proprietary and community images which you may use to kickstart real quick. Or you may follow the long and tedious process of installing your own services on a fresh EC2 host - NOT recommended. Initially, I played around with Bitnami images. They are free to use, basic and compatible with AWS Free. Before, selecting an image, ensure that it contains your choice of web server, database server, backend cache server, etc.
For the server specifications, start with the free-tier server configuration (t1.micro instance). You may use the t1.micro instance/host for up 750 hours or one year free of charge while you are playing around with different images and doing your backend and front designs. When you launch your service, you can change the server configuration seamlessly to any compute-optimised or memory-optimised configuration to suit your hosting demands.
If you are Linux savvy or willing to learn Linux, I recommend that you use a Linux host, preferably RedHat or Ubuntu. Both have lots of support from their owners and the Linux community. DigitalOcean has lots of articles on Ubuntu which you may following while installing services on your EC2 host.
I recommend that you run your sharing service on an NGINX web server. NGINX is generally more faster in serving your contents than APACHE. Most of the world’s top websites run on NGINX.
MYSQL is the de-facto database engine. You may host your MYSQL on the localhost (EC2 host) or remotely. If you are working with AWS, I will recommend that you use a remotely-hosted MYSQL server. That means that the MYSQL server should not be hosted on the EC2 host. This gives you the freedom to commission and decommission your EC2 hosts without worrying about your database. AWS’ solution for remote MYSQL server is the Amazon RDS. As with EC2, you can spin off an RDS instance within minutes and use it free of charge of up to 750 hours or one year.
To connect your RDS-hosted database server to your EC2-hosted web application, what you need is the database server endpoint (host URL) which can be found on the RDS backend.
##HTTP ACCELERATOR/ CACHE REVERSE PROXY
I recommend that you use Varnish as an http accelerator in order to assist the web server (NGINX) in serving your dynamic contents super fast. According to varnish-cache.org:
Varnish Cache is a web application accelerator also known as a caching HTTP reverse proxy. You install it in front of any server that speaks HTTP and configure it to cache the contents. Varnish Cache is really, really fast. It typically speeds up delivery with a factor of 300 - 1000x, depending on your architecture.
Varnish is easy to install via the repositories of Linux distros but you will need to configure your NGINX and Varnish to allow the later to serve upstream of the former. If you need an already installed and configured Varnish cache, spin off an EC2 instance from an Amazon Machine Image (AMI) pre-configured with Varnish. Bitnami images with Varnish might need you to still configure Varnish after installation. Their documentation on Varnish is straightforward though.
A typical database server may receive the same query and return the same set of results over and over again. Database cache servers allows the storage of these similar sets of queries and results and directly serves them to the web server with little or no interaction with the database server. Memcached and Redis are the two most popular solutions for database caching. You may choose to host your database cache on your EC2 host or remotely via AWS Elasticache. On Elasticache, you can choose between Memcached and Redis and spin off a cache server using the t1.micro free-tier instance configuration.
- Database Caching
- Databae Caching (Wikipedia)
- Introduction to Redis
- How to take advantage of Redis just adding it to your stack
- 11 Common Web Use Cases Solved In Redis
- What is Redis and what do I use it for? [closed]
- About Memcached
- Memcached: What is it and what does it do? (PHP Version)
According to wiki.typo3.org:
An opcode cache is a system to cache the result of the PHP code compilation to bytecode. This allows to use the bytecode instead of compiling on every request. Different opcode cache systems are available, mostly depending on used PHP version.
Common solutions for Opcode Caching include:
- Eaccelerator (PHP <5.4)
- Zend OPCache (PHP >5.4).
These are usually installed on the localhost. Some AMIs come with preconfigured Opcode Cache Systems (commonly APC & Zend). Confirm before spinning off an EC2 instance with any particular AMI.
EDGE CACHING OR CONTENT CACHING
A typical web application might have static contents such as image, CSS, & JS, audio and video files. When requested, these files could be served directly from your web host or you could outsource that task to a Content Distribution Network (CDN) which will ensure that your static files are hosted on dedicated content servers around the world and that clients are served from the closest content server. These increases your site-load speed and decreases bandwidth usage on your web host.
Common CDNs include:
- Amazon CloudFront,
- Limelight, etc.
I recommend the use of CloudFront especially if you are using AWS S3. CloudFront is still compatible with any other third-party host.
AWS allows up to 30GB of storage for a free-tier (t1.micro) instance. Configuring more storage space for your instance is expensive. Instead of adding more storage space to your web host, it is recommended that you setup AWS S3 buckets and use the buckets to serve your static contents. AWS S3 is also covered the the AWS Free policy.
If you need to synchronise your S3 buckets with folders on your EC2 web host, consider using s3fs-fuse. You may also configure CloudFront to serve your S3 buckets.
Amazon Route53 can offer highly-available DNS service for your web host, application servers and load balancers. If you have an EC2 web host, then it’s logically that you make Route53 your DNS provider. Route53 can also be used for purchasing domain names. AWS makes configuring Route53 very simple and intuitive.
SCALABILITY & AVAILABILITY CONSIDERATIONS
The biggest advantage in using AWS services is their high availability and scalability. Most AWS services are hosted on clusters of servers called Regions and mini-clusters within Regions known as Availability Zones. You may be required to choose a region and an availability zone closest to where most of your user might be. In the case of a global company, you can host different instances of your web hosts on different regions or availability zones to provide safety nets in the case of unavailability of a particular region or availability zone (Amazon says this hardly happens though).
Scalability of web applications on EC2 is achieved using Auto Scaling Groups and Elastic Load Balancers. Auto Scaling allows your web server, database server, or cache server to scale up and down depending on the load from users (traffic). Load Balancers allow traffic to be spread across multiple running instances of your web server and application server (which could be in the same region or across multiple regions).
Below is a 3-tier architecture featuring a typical usage of AWS services
If there is anything I didn’t put well, kindly point out for the sake of readers. You may shed more light on other services which I might have missed. Thank you.