A couple of months ago I took and passed the Amazon Web Services Certified Solutions Architect Associate (AWS CSAA for those not in the mood to be verbose) exam.

It’s a Long Way to the Top (If You Wanna Pass the Test)

It took about 10 months to prepare for this exam, although most of that calendar time was taken up by work, with the lion’s share of studying and cramming happening a week-plus before the exam (we were also leaving for UK/Norway a few days after that, so let’s say it was a bit of a hectic week-plus).

With that said and with the benefit of hindsight, here are the things I used or did on the way to the CSAA exam.

Udemyou? Udemy!

I purchased and completed three CSAA courses, and while there were understandably overlap in content among the three, I found Linux Academy’s offering to have the most focused in terms of lab work (although in order to take full advantage of their hands-on labs one should probably sign up with their “all-you-can-eat” course subscription).

The acloud.guru course, when purchased from Udemy, can be transferred to their proper site where its contents get updated fairly regularly to reflect changes and new features in AWS.

The third course was okay, but I think acloud.guru and Linux Academy were much better. With that said, I purchased all three during Udemy’s frequent sales, so not a huge hit to the wallet (between the study material and the exam cost, I’d probably spent around $200 getting this certification).

Don’t Book ’em, Danno

Of the books I’d read and referred to during all this, I’d guardedly recommend this study guide. It covers the exam materials, but some of the details and what one might regard “minutiae” have changed since the publication date (I found that out through practice tests, FAQ’s, and updated acloud.guru lessons).

I guess it doesn’t help that a new version of the CSAA exam came out since the study guide’s publication. It looks like there is a newer book that covers the 2018 exam, but I haven’t had the time or need to look into it.

GTFO: Get the FAQ’s Out

The one constant of AWS is that it is constantly changing. New features are added, existing features are changed (or sometimes deprecated), and their own documentation, especially their FAQ’s, do keep up with these changes pretty well.

Not that this particular tidbit showed up in the exam, but recently we were looking at FedRAMP compliance of AWS services for a project, and in the span of two weekly meetings, the Elasticache managed service got approved (we noticed the status changing in the middle of the second meeting).

There are better examples of how quickly and constantly things change with the AWS service portfolio, but the time-honored adage of “Read The Fine Manual” (the adage in question masterfully sanitized by George Takei in one of the Starfleet Command game tutorials) definitely applies.

Practice, Practice, Practice

As a coworker so rightly advocates, build your muscle memory. Following along with the videos to provision an EC2, VPC, etc. is great for being introduced to those concepts, but doing these exercises without guidance, repeatedly, and preferably for “real world” projects is critical for internalizing AWS knowledge.

I’m fortunate in that I get to work with AWS for work, and in the months leading up to the exam, I had an opportunity to migrate a million-plus user WordPress site to AWS, launch an ECS Fargate-backed analytics dashboard application, and set up a multi-environment AWS infrastructure. As well as launching regular old EC2 instances that host CMS sites.

While it’s awesome to be able to do this sort of “learn by doing,” one can still do quite a bit of exploring and building with the AWS free tier account (although be prepared to pay a few bucks at least – there is a price for knowledge after all).

Taking Tests to Practice Taking Tests To…

To follow through on another adage about cutting bait or fishing, I booked an appointment to take the CSAA exam, and started hitting the Whiz Labs practice tests. While not as compact as flash cards (nor 100% accurately reflect actual exam questions), the practice tests are a great resource to assess what you think you know and to focus on the bits that you now know you don’t know.

The Big Day

While it is possible to take the certification exam at home, I decided to do what most folks do and scheduled an appointment with PSI, who administer proctored exams for all sorts of things, from aspiring cloud architects to realtors and whoever needs a-testin’ to be a-certified.

The local PSI facility is in a rather unremarkable office building a few minutes from our house, and it is remarkably busy with exam-takers who show up by the half-dozen-plus, sign in, pack away everything (e.g., wallet, keys, and especially phones) in a locked zipper bag, and shuffle away to a room full of booths, each with a workstation ready to test your worthiness to be whatever you’re looking to call yourself.

A couple of hours after checking in for my appointment, I shuffled out of the unremarkable office building with a vague recollection of having passed the exam. Once you submit all your answers, you’re presented with the test results, but you don’t get any actual hard copy of said results. I remembered seeing the word “Congratulations!” on that final screen which would at least imply that I passed, but even the email that arrived immediately after the exam simply stated that I “completed” the test.

The actual results arrived via email the following day, and hey, just as I kinda recalled, I passed!

While I may have taken a lot of calendar time studying, doing, watching, and eventually cramming, I do think that if you do need to take that time to really use AWS in order to learn it. A part of the curriculum does involve a “trivial pursuit” type of memorizing the details of specific AWS services and features, but the exam does require you to understand how the alphabet soup of Amazon cloud offerings (EC2, VPC, ECS, ECR, ELB, ALB, S3, RDS, and on and on) work together, especially in “hybrid” deployments where part of the IT infrastructure remains on-site, while other bits get boosted into the cloud.

And For My Next Trick

What is that they say about potato chips and certifications – that you can’t just have one? I’ll be looking into the Certified Developer Associate exam next, and while once upon a time the CSAA and CDA exams were so similar that you could ace one and pass the other, that “feature” has been nerfed/fixed. So, time to start hitting the videos, clouds, and books again!

An all-volunteer-run, low power FM community radio station in north Portland, Freeform Portland (90.3 FM in the immediate vicinity near The Radio Room where the transmitter resides – the studio is near PCC on Killingsworth) runs its website on WordPress.

As co-chair of the station's Web Committee, I've been leading the effort to refresh, enhance, and maintain the Freeform website, which now includes a community-contributed blog and integration with a React/Node playlist logging/show scheduling app (to which I've contributed some code).

As part of the ongoing effort to provide the Freeform community with a set of applications that balance resiliency, availability, and a sub-shoestring budget, I've been working to migrate and centralize servers and services on AWS, using EC2, S3/Glacier, Application Load Balancers, IAM, Route 53, certificate management, CloudWatch, Elastic Container Service, etc.

Using a VPN used to be the sort of badge of honor indicating that you did something important enough for your corporate overlords to grant you access to the company network through the magick Cisco tunnel (yeah, so you’re having to sling pivot tables off the office file server over the weekend, but hey, you dontcha feel special?!). Now, especially with the net neutrality repeal, everyone’s getting a VPN, and it’s not just to stream BBC’s iPlayer from the States.

Choices, Choices

There are a gazillion VPN vendors out there, and even more blog space devoted to the explanation, virtues, necessity, and comparisons of VPNs, and being the curious soul I am, I’d pondered “Hmm, would it be possible to set up your own VPN tunnel using the various cloud server services out there?” And yes, it is, and you’ve got your choice of tutorials to dig that encrypted tunnel under/through your ISP (or simply through that open coffeeshop hotspot).

You could…

• Set up a $5/month Digital Ocean Droplet and install OpenVPN Server on Ubuntu
• Do something similar on a free tier Amazon Web Service EC2 instance
• Use the OpenVPN AWS EC2 tiered appliance

Then there’s a number of different walkthroughs for deploying OpenVPN Server as a Docker Container, and I went with this one:

• Setup Your Own $5 VPN With Docker, OpenVPN and Digital Ocean

The simplicity of a Digital Ocean Droplet, which lets you kinda skate past the accoutrements that come with (and are essential to an) AWS cloud environment, and the easy-breezy-beautiful Docker Container image were the main attractions here.

London Calling… and They Hung Up

And speaking of easy and breezy, the whole thing from start to finish took me about 15 minute to set up, and I had myself a VPN tunnel with a UK IP (as in an IP address in the UK, not those xenophobic knobs UKIP) address! The immediate downer was finding out that the clever folks at the BBC had blacklisted data centre (note the “proper” spelling there) IP addresses, so no iPlayer for me.

No big deal, I deleted the Droplet, created a new one Stateside, and I’d gotten myself a little tunnel through public wi-fi hotspots for my phone, tablet, etc. So far, I’ve been pleased with the latency (or the relative lack thereof) as well as with the ability to set up as many devices/users as I want at that miserly $5 per month. The next step is to set up a spare Netgear router that I’d flashed with DD-WRT to have a perma-connection through our home ISP.

Dee Eye Wye Vee Pee Enn

Admittedly all this is probably more work than paying a few bucks a month for a professionally managed VPN service, but there’s something oddly satisfying about setting something up yourself. Not as thrilling as, let’ say, digging your way under and out of Stalag Luft III, but it’s kinda sorta a way to make your “great escape” through your own bloody ISP (and that’s a whole ‘nother rant for another time).

And speaking of “The Great Escape,” here’s a great song by a great band:

The website of an imaginary cosmetic surgery practice for InboundRx to demonstrate the marketing of both the clinic and Inmode’s Fractora laser skin treatment equipment. By this point, the customization of a client brochure site template and its subsequent launch on Amazon AWS is pretty much routine. What made this particular deployment a bit more interesting is the configuration of Git and SSH to enable direct production code push from the Cloud 9 IDE to the AWS EC2 instance. It does take a tiny bit more upfront work, but I’m finding that subsequent code changes are significantly simpler to roll out!

Built with WordPress (PHP, CSS, MySQL, etc), launched on AWS EC2 with SSH and Git, secured with Let’s Encrypt and Certbot.

Live Site: https://www.examplecosmetics.com/

Repository: https://github.com/eeronomicon/wp-fractorademo

Over the past week or so, I got to launch four websites for InboundRx: Gore Drug (Oklahoma), Bernie’s Pharmacy (Alaska), Medical Center Pharmacy (Texas), and Capitol Pharmacy (California). The deployment process involved the creation of a development site for each client on a Cloud 9 work space, on which I customize the WordPress theme via making code changes to the template PHP and CSS files while InboundRx’s designer and copywriter would populate the site’s content.

Once the design and content reached a stable plateau, I would then create an AWS EC2 instance – based on an Amazon Machine Image of a ready-to-configure WordPress site on an Ubuntu LAMP server – and migrate the theme, plugins, and content from the Cloud 9 IDE to the EC2 instance. In two of these cases, I registered the client domains with Amazon’s Route 53 Cloud DNS and set up zone records to direct traffic to the appropriate public IP address. For all four sites, I used Let’s Encrypt and Certbot to enable HTTPS/SSL.

I’m currently exploring options to make the deployment process even more hands-free and automated. While deployment pipeline scenarios for Node and other frameworks seem well defined and have lots of examples, I’d need to do a bit of research to determine what best practices exist for humble WordPress sites.

Live sites:

• https://www.goredrug.com/
  
• https://www.berniespharmacy.com/
• https://www.medicalcentertx.com/
• https://www.cpi-rx.com/

I’d first heard of Mautic on the first day of my internship with InboundRx (and truth be told that’s the first time I’d heard of marketing automation – I’ve worked with web analytics and email marketing campaigns, but the idea of setting stages and points for your participants and having software facilitate the process flow was something that lay outside my loop until then). The idea was to use this as an alternative to Hubspot which is regarded as the proverbial Cadillac of such services (with features and price tag to go with that), and we were tasked with customizing this open source tool with modified branding and launching an instance of it on the cloud.

No-Go, Daddy

First we tried a local installation with MAMP. Great, I can follow directions and have it running on my MacBook. Next, on a Cloud 9 workspace. Then the first brick wall of publishing this app on Heroku. It took very little digging to discover that Mautic doesn’t support PostgreSQL (and Heroku doesn’t do MySQL), so no go. Next, a GoDaddy Virtual Private Server. No, Daddy, no. Upgrading to the required version of PHP was a mild pain in the rear (and trying to get PHP7 installed on their VPS was an extreme pain in the rear), and then trying to configure outbound email delivery that didn’t deliver everything as spam was as fruitless. Lesson learned: don’t try DIY when doing bulk mail.

Sailing the Open-Source Seas of Cheese

Even trying to work with the platform once it was launched (on wobbly legs) was a trial. Importing 8,000 contacts required some heavy massaging and eventual breakup of the CSV file into more manageable (or less crash-prone) chunks of 1,000. And the default pagination of 100 line items proved to be yet another pain in the rear for site admins who wanted to bulk-assign thousands of contacts into Segments and Campaigns. I’d managed to modify the PHP code to allow up to 500 items in a bulk operation, which resulted in my first (pending, probably not going to go through) pull request to an open source project.

In the meantime, I’d installed an instance of Mautic on a Digital Ocean Droplet for my own nefarious purposes, with greater success (or fewer faceplants) than with GoDaddy. But then I don’t have 8,000 folks in my contacts list. Yet.

You Can’t Spell “Awesome” without “AWS”?

Over the past couple of weeks, I’d started working with Amazon Web Services, and in particular with their EC2 virtual machines. I’d launched InboundRx’s new website on an EC2 instance, and I was curious as to the lower limit of an instance size that could support Mautic. Starting with an Ubuntu/LAMP Amazon Machine Image that I’d set up for future WordPress sites, I spun up (insert a merry twirl of a magic wand here) a t2.nano instance (insert sage shaking of heads going “that ain’t gonna work, son, that there nano’s too small!”) and installed Mautic. So far so great.

As an aside, I had to get myself up to speed on setting up key pairs for SSH access, which also came in handy in my later forays onto Google Cloud Platform, but I digress.

Cloud Rockets in Flight, APM Delight

Right around that time (a whole week-ish ago?!), I’d started mucking around with New Relic’s Application Performance Management tools (this is what happens when one attends a few Meetups in New Relic’s offices and asks the obvious question of what do these folks do), and while my initial install of the APM PHP agent was easy-peasy and uneventful (a Digital Ocean Droplet doing triple-duty with Drupal, WordPress, and Mautic), I figured I’d use the APM to see if I could get any more insights into a low power (t2.nano doesn’t get much lower!) install of Mautic tasked with importing thousands of contacts.

The PHP agent requires root access in order to install, which means (a) no-go on the GoDaddy VPS and (b) no-go on Media Temple’s Grid Server, but awesomesauce on AWS. I felt a bit like those automotive crash test engineers in that I was deliberately putting load on the application server to see whether and how it’d buckle and crumble. I definitely wasn’t disappointed, as there were plenty of hangs and crashes (nothing fatal that required calling Mulligan to re-do everything from scratch!), and having to tweak php.ini while using Mautic’s, MySQL’s, and NewRelic’s logs to cross-reference and triangulate errors was actually a lot of fun.

Probably the biggest lesson learned is that the mere 0.5 GiB of memory will cause MySQL to keel over a few times a day. I’m sure this is going to poleaxe the server’s responsiveness, but setting up a swap file seemed to alleviate that multiple-times-a-day MySQL crash.

That said, on one hand, I think a t2.nano can handle Mautic, but I do wonder about this CPU Credits per Hour thing and whether I’d end up running out of them at some point on such a small EC2 instance. #weshallsee

Deliver This Mail, ‘Cos Amazon SES So!

When we tried hosting Mautic on GoDaddy, we tried using the host VPS as an SMTP relay to send outgoing emails. Spam by any other name is still canned meat, or so the saying goes, and more often than not the outgoing marketing emails landed in the junk bin. Reverse DNS helps to an extent, and I suspect that setting up DKIM and other identity authentication would have helped as well. But since I was using AWS, I figured why not try their Simple Email Service?

Verifying a domain was quite straightforward in making a few DNS zone file tweaks, and verifying email addresses was even simpler. The biggest holdup (and relatively speaking this seems minor in retrospect) was getting Amazon to get our account out of the “sandbox” to allow us to actually send mail (as opposed to the severely limited delivery parameters of the sandbox). While we’ve yet to actually do a full-scale email campaign with the AWS setup, initial experiments are quite promising.

That said, the next instance of Mautic on AWS is going to use a bigger machine with more hamsters at the wheel.

With two locations in the Los Angeles area, Capitol Drugs is an independent pharmacy that offers a portfolio of conventional and holistic therapies. In a scenario that pretty much is a replay of the Paulsen’s Pharmacy website story, I had to “cat flap” my way into restoring full administrator access to this site in order to (a) help with making design/CSS tweaks for the Sample Saturday promotional campaign and (b) extract the WordPress custom theme files for use with future InboundRx clients wishing to use this design as the basis for their sites.

Live site: http://capitoldrugs.com/

InboundRx is a marketing agency focused on helping independent pharmacies and other healthcare practices. Starting from a set of mockups created by InboundRx’s Director of Design in Adobe Illustrator, I’d created a WordPress custom theme, based on root.io’s Sage starter theme. Making use of Bootstrap 4 and SASS, I’d created the Bosch (named for its triptych/three-panel layout) theme which was then further customized for InboundRx’s new website.

I’d created the base site and implemented the Bosch theme in a Cloud 9 workspace, and after additional customization and content generation, I published the site on an Amazon Web Service EC2 instance. The Certbot SSL is the cherry atop this cloud sundae.

Built with: WordPress, roots.io Sage, SASS, Node, Gulp, Bower, PHP, CSS, jQuery, Cloud 9, AWS EC2, Certbot SSL.

Live site: http://www.inboundrx.com/

Repository: https://github.com/eeronomicon/wp-inboundrx

To circuitously paraphrase Eddie Izzard, we Americans don’t have much history (as opposed to Europe, where all the history comes from, and there’s a castle at every street corner), so when a local pharmacy has been around long enough to require three digits to count its age, it’s definitely worth noticing. And that’s Paulsen’s Pharmacy – situated just down the road from where we live in the heart of the Hollywood neighborhood in Portland, Oregon.

InboundRx had commissioned the redesign of Paulsen’s website (along with a complete rebranding – you may note that the background photo of the pharmacy shows its pre-reboot sign), and for reasons best not discussed here, InboundRx got locked out of administrative access to the site and to the theme code that they wanted to use for other pharmacy clients.

Over a couple of days, I managed to finagle (the verb “hack” seems way too sophisticated to describe the “telekinesis through the cat flap” method used here) my way into the site to restore full administrative access to their site, make content changes to the site that required file-level access to the WordPress theme to affect, and grab all the necessary theme, content, and configuration files from the site to create a boilerplate for future InboundRx customers to use this design.

Built with: WordPress, CSS, PHP, and MySQL. Reclaimed with mild human cunning and relocated to a Cloud 9 IDE for future reuse.

Live site: https://www.paulsenspharmacy.com/

The website for an independent pharmacy in Southfield, Michigan, originally developed by InboundRx. I’ve made code changes to the custom WordPress template via forked GitHub repo and launched the site on GoDaddy’s hosted Linux server via Git pull. The client ended up making a literal last minute domain name change, so there was a bit of a fire drill to get the site back up and running, but hey, all in a day’s work!

Built with WordPress, PHP, CSS, GoDaddy Linux server/SSH.

Live site: http://www.mcspecialtypharmacy.com

Repository: https://github.com/eeronomicon/medicine-cabinet-wp-site