How it works - all the techo details for AWS geeks
If you are already an AWS expert (Hi!), you might be interested in these tech details on how Idealstack works. If your an AWS novice then check out the less technical description.
What Idealstack does
AWS connects to your AWS account via the AWS API, and configures and manages a PHP hosting cluster that supports autoscaling, high availability, load balancing, and more.
The core design principle at idealstack is to provide a "normal" PHP hosting stack on AWS in the 'ideal' way (it's in the name!).
What we consider that to mean is that:
- it gives you what an expert AWS Consultant would build you if you were trying to run a sophisticated PHP hosting stack on AWS: Clustering, fault tolerance and autoscaling
- But at the same time we want to make it work like "normal" PHP hosting - where you can write code or install common CMS platforms without having to resort to practices like Devops, changing your development practices, configuring servers, and other hassles that are often involved in getting an "ideal" setup.
We don't 'cut corners' or 'dumb things down', while still providing an easy to use system that avoids you having to retrain all your staff or spend months setting up and learning AWS
How do we acheive that using AWS tools
- Idealstack connects to your own AWS account via the AWS API's. We don't resell and 'mark up' the cost of AWS resources - you pay AWS directly for that. Idealstack's Pricing is transparent
- Idealstack uses Cloudformation to create a 'Stack' to configure AWS. Cloudformation comes with a lot of benefits:
- It's 100% reproducable
- When updates fail they automatically rollback
- Updates generally apply in a 'high availability' fashion - ie when updating a site, the new configuration needs to be up and running before the old one is shutdown
- Sadly not everything can be done through cloudformation, so idealstack also integrates a number of other API's to do the things we can't do through cloudformation.
- Sites are run inside docker containers running on the Elastic Container Service (ECS).
- We use our own optimised docker images as a base for this, with options for different PHP versions.
- However we don't require users of idealstack to adopt docker as part of their workflow - in many ways docker is more suited to python/nodejs and other apps where you are likely to want a fully customised OS environment. Generally for PHP you don't need this as you assume the server conforms to certain norms (ie the 'LAMP Stack') - that need to 'not have to worry about this server' is key to PHP's success, and it seems like a shame to let it go. You just have to upload your site over SFTP like you would with any other hosting provider - we use docker so you don't have to.
- EC2 Instances (aka 'servers') are completely generic instances of the Amazon ECS optimised AMI. Sites run in docker containers, so the instance doesn't need to have anything installed on it.
- Very little customisation is done to the instance apart from configuring it for ECS
- Autoscaling is done by scaling the number of instances when sites get busy
- Instances are 'cattle, not pets', meaning they can be killed off and recreated when Amazon release an update to the AMI. There's no need to run updates on them manually provided you do this.
- Autoscaling - your instances are setup as an Auto Scaling Group.
- Idealstack monitors the load on your instances and when it exceeds certain thresholds, adds a new one.
- It then also updates your sites to ensure they scale out across this new instance (AWS provides no built-in way to do this).
- When load drops back to normal it'll 'scale in' to get rid of the excess capacity.
- A lambda function is setup to enable connection draining, so that there's no downtime when instances are shutdown
- AWS will only charge you for the time that the instance was running.
- Databases are provided by RDS
- Website code & data is stored on EFS
- EFS provides a fast and highly reliable NFS file store
- This means sites don't need to 'know' they are running in a cluster in the cloud, and you can run any PHP app
- PHP Sessions are stored in DynamoDB.
- We automatically configure the PHP session handler for this so your site doesn't need to know anything about it.
- This means that most apps will work without any mods
- Read & Write capacity of the DynamoDB table are auto-scaled
- An application load balancer (ALB) is created to route requests for each stack.
- Rules to route each domain name to the right docker container are maintained automatically.
- Free SSL certificates are automatically registered in Amazon's Certificate Manager (ACM)
- Webserver logs (eg access logs and error logs) are automatically streamed to Cloudwatch. That means you can search them, stream them to other services like ElasticSearch/Kibana and even create dashboards, metrics & notifications from them.
- To send email, idealstack can optionally configure the Simple Email Service, and configures a local forwarding mailserver on the docker image to make this transparent to your code
- IAM policies are carefully set to ensure minimal 'trust' between the different parts of the stack, which maximises security
How is this different from the alternatives?
PHP hosting consoles, eg Plesk, Cpanel, WHM
These typically install on a single AWS instance, and treat it like it were a physical server. ie they install Mysql on it, install apache & php and run as though the cloud were never even invented. While this works, we think it's pretty rubbish.
This is an easy to use starting point for AWS, and it provides templates for PHP. But what it creates you is a dumbed-down 'starter' AWS environment. It's not what you would design if you knew what you were doing
Lightsail is another 'dumbed down' AWS offering designed to compete with cheap clouds like Digital Ocean. It gives you a VPS (similar to the docker container that Idealstack will use) for a low price, but again it's only a dumbed-down 'starter' option. It doesn't do many of the things that are 'cool' about the cloud, like Autoscaling. You'll soon find yourself wanting to move to a 'full' AWS setup.
Build it yourself
The simple truth is it would take you years to build all this yourself and get it running stably. We know this because we've done it ourselves. The AWS world is complex, and it takes months of cobbling together different solutions to create something 'ideal'.