What You'll Miss On AWS
& How To Find It Again
S3: Simple Storage Service
EC2: Elastic Compute Cloud
RDS: Relational Database Service
EBS: Elastic Block Store
EFS: Elastic File System
ELB: Elastic Load Balancer
Cheap file storage
No more my.cnf!
|What you'll miss||How we solve it|
|1||Your server actually being there||Launch servers in multiple availability zones|
|2||Domain mapping to an IP||Load balancing with a Route 53 alias|
|3||Users having consistent sessions||Enable sticky sessions|
|4||Making server config changes||Auto scaling groups & automated machine imaging|
|5||Using the file system||Elastic File System|
|6||SSH access to your server||Elastic IP and Lambda functions|
|7||Files uploading quickly||Multi-stage deployments|
|8||Sub 1s PHP execution times||Zend Opcache|
|9||Cron!||Scheduled Lambda functions|
Is this really the best way of doing things?
You'll miss: your server actually being available
eu-west-1 (Dublin) or eu-west-2 (London)
- Launch servers in multiple availability zones
- If using RDS, choose the "Multi AZ" option
- Use an "auto scaling group" to guarantee servers in a specified number of AZs
- No need to worry about S3, EFS or Lambda - synced across AZs automatically
You'll miss: domains mapping to IPs
- You don't need to worry about its AZ
- It can target a group of instances
- Even checks if an instance can receive HTTP connections
- Called a "balancer" but really just directs traffic randomly
- Because you obviously all use TLS, you'll need to give the Load Balancer your private key
You'll miss: users having consistent sessions
You'll miss: making server config changes on the fly
Behold the "master" instance!
Be lazy; use Lambda!
- Check for AMIs in our account with a specific "tag"
- If there are more than 1, delete all but the newest - helps keep our S3 costs down and our account tidy
- Get the current launch configuration of our autoscaling group - we can assume this works
- Replace the variables in the data for the AMI ID and snapshot ID
- Create a new launch configuration
- Apply the launch configuration to the autoscaling group
Next, hacks and magic!
Autoscaling lets us make scheduled actions
It also lets us choose how it terminates instances
- Edit your master server
- Switch off your master server
- Make an image of it
- Create a launch configuration with that image
- Set your autoscaling group to use the new launch configuration
- Cycle out your old instances
You'll miss: using the file system
How are there are no memes about file systems?
Connect from any AZ
Works as a network mount
EFS is also "limitless"
The "E" stands for exabyte:
You'll miss: SSH access to your server
You'll miss: files uploading quickly
EFS slow down means your app files might end up inconsistent
If your app can't tolerate this you need to use atomic deployments
- Deploy your application to a writable directory on whichever server you have an elastic IP attached to
- Trigger a process on the server to copy your files to a named release folder (e.g. timestamp) on EFS
- Repoint a symlink to which your web server config points as the application root
Many deployment programs that use a remote agent (e.g. capistrano) already use this technique. We rolled our own in bash
You'll miss: PHP scripts executing in less than a second
Seriously, can we not have cool logos for PHP mods?
You'll miss: crontab for scheduling jobs
Why did I commit to this meme thing?
Logging is fun...
Sounds like you'll miss a lot...
What do you gain?
- Ability to offer "always up" web services to your company or clients without building your own data centre(s)
- A growing standard for how distributed applications behave
- Stupidly cheap storage on S3 and processing on Lambda
- Bulletproof backups
- Multiple options for data sovereignty
AWS might appear hard, but it's easier than finding a relevant meme for each item in a list of infrastructure problems!
Liked this talk?
Let me know!
@m1ke on Twitter
Enjoy the rest of PHPNW17
Please leave feedback
What You'll Miss on AWS
By Mike Lehan