Developing solutions on Amazon Web Services since 2009
Background
In 2007 I got my feet wet with AWS using their Simple Storage Services (S3) to store and host large media files behind a 3rd party content delivery network service. This experience allowed the company to scale podcast hosting customers with no limit on podcast media storage. That first solution allowed Blubrry to take podcast media uploads to their own dedicated FTP and web servers to be stored with no limitation on storage.
Out of the necessity, in 2009 I moved Blubrry Podcasting’s workloads from dedicated servers to Amazon Web Services. The lateral move did 2 significant things: allowed the company to scale; saved over 80% on infrastructure costs.
Adapting to AWS was simple. When the company was founded in 2005, we started out using Fedora and later Ubuntu distributions for our server infrastructure. A precursor to infrastructure as code, we wrote bash scripts that setup and deployed code onto a newly purchased dedicated servers. We used command line tools including subversion –export option to deploy projects from our revision control system directly into production. We easily adapted our bash server setup scripts to the “user–data” portion of instance creation with EC2. The only challenging systems to migrate at the time were our MySQL databases (there was no RDS Aurora/MySQL services at that time).
Workloads migrated to AWS in 2009 included a podcast network and directory platform, podcast listening statistics reporting system, advertising campaign management system, and a commerce billing system. Most notable included company WordPress websites. It quickly became evident taht our WordPress sites on AWS EC2 instances provided better performance.
If you are familiar with “The 6 R’s” of migrating to AWS (rehosting, replatforming, repurchasing, refactoring, retire, retain), we deployed the “rehosting” strategy, except for 1 system we used the “retain” strategy, we decided to leave it on the current infrastructure for 18 more months (we were maximizing a remaining lease we had on 2 dedicated servers). By 2011 all workloads were migrated to AWS.
Once we had workloads migrated, we quickly started making changes to our projects and systems to utilize other AWS services such as RDS MySQL. For Amazon’s MySQL, we had to convert our databases from using MyISAM to INNODB tables. For most systems, this was quite easy and everything but the podcast listening statistics reporting system was migrated to AWS’s RDS service. In 2014 we finally migrated our statistics reporting system to RDS utilizing the new Aurora MySQL which promised 5 times faster performance, which from our tests was not only true, but perhaps more than 5 times faster.
In 2015 we started refactoring projects to utilize additional AWS features. The goals were:
- All uploaded files saved in S3
- All static files stored in S3 (dedicated servers would no longer store dynamically or user generated data)
- Static “asset” files stored in a shared project
- Migrate projects from SVN to GIT and use tools to deploy code (later replaced with Code Deploy)
- Config files stored outside of project folders to make deployments easily managed
I am a big proponent of making changes strategically. Some systems were updated early on, while others were only updated when the project was under development to include other value-add features. This meant that some systems took longer to to update. This is my management style, I prefer to roadmap infrastructure changes to correspond with other project improvements.
By 2020 all active projects are now in an optimal state to deploy and manage in AWS.
Converting traditional applications to fully utilize AWS can be a endless process. One example is user uploaded images. At first we handled uploads then promptly moved the uploaded image to S3. In more recent years we now upload images directly to S3 in a special bucket then once the upload is completed we move the image to its final destination in S3.
WordPress on AWS
Since 2009 I have managed thousands of WordPress websites hosted on AWS.