I write a lot to help organize my thoughts. But most of my notes are either in a journal – there’s still something special about using a pen and paper, or in Word docs. This creates a couple of problems – it’s hard to search, and I’m the only one to benefit from this effort. Blogging is my way of sharing some of my ideas/thoughts that might help others, and to also make it searchable for my own needs.
Since this blog isn’t intended to be a revenue stream, I am not going to worry about site-optimization, pushing traffic, and all the other internet/ecommerce type stuff. My goal is to keep things simple and the costs manageable. The quick/easy would be to spin up a virtual machine, load it with a LAMP stack, install WordPress, and be done. That’s what the super-basic WP hosts offer. But then I was thinking what if something I write somehow really hits a cord with peeps? This solution would crumble with traffic, plus it would be fragile. Time to distribute it.
My goal was to keep costs low, eliminate operational support, and put this site on auto-pilot. I decided on the following design architecture:
- Route 53 – Cloud architectures are ephemeral. A load balancer’s IP can change, instances get scaled up/down, etc. Amazon’s DNS can use aliases for the load balancer, allows instances to register/deregister, etc. All I need to do is create a couple of properly configured DNS records and I’m done with it. All the dynamic mojo is taken care of by Route 53.
- Elastic Load Balancer – I’m terminating SSL at the edge (i.e. the load balancer). I am also using the layer 7 Application Load Balancer. It allows the containers to be dynamically added/removed from the target groups. Plus it has Big-IP F5 like functionality for url handling if needed in the future.
- Elastic Container Service (ECS) – I originally was going to drop WP on an EC2 instance in an auto-scaling group. However, using containers makes things so much easier. Plus, where I would only get a 1-to-1 WP-to-EC2 instance if I went the EC2/auto-scaling route, now I can have an N-to-EC2 instance model, for example running 2 WP containers per EC2 instance.
- RDS – Databases are a PITA to support and maintain. Using RDS removes a bunch of that pain. Whenever you think you want to run your own database, bang your head against a wall. Life’s too short and there’s a reason SQL guru’s are guru’s – you have to be a special type of crazy to like databases.
- Elasticache – Caches are a one of the make-stuff-go-fast tools for internet/ecommerce architectures, and WordPress can use Redis. Elasticache handles all the patching/operating/multi-az cluster replication, etc.
- Elastic File System (EFS) – WordPress uses /wp-content for all the user generated content, plugins, and other stuff. I’ve used yas3fs with an S3 bucket, but sometimes yas3fs gets “wanky.” EFS provides an NFS mount-point for the fleet of WP containers in the cluster, providing a consistent user experience.
I have a love/hate relationship with AWS. I know what I want to do, but figuring out how to get all the AWS bits to “play nice” together can be a pain. It’s the 80/20 rule – AWS documentation will get you 80% of the way there, but then that last 20% to figure out the undocumented or “it should work like this, but it really works like that” is the pain part. I had to work thru a few gotcha’s and I’ll share those in another post.