Why would you spend the time creating an AWS instance?


When consulting on the projects that I am assigned to, I require the security of mind that if my CQ instance dies, I have a way to rebuild it in minutes not hours.  Not just the "base install" but all of my configurations as well.  I need the complete "environment" state preserved to be potentially reconstituted at a moments notice.  This keeps the client happy, and me from losing sleep or worse.

Yes, there are many was to protect your precious CQ instance from the dangers of the development cycle.  I won't list them here, and I am sure if you have used CQ for any meaningful amount of time, you have destroyed your CQ instance at least once.  It seems to me that it happens at least once per project, and pretty much inevitable.  I will say as CQ has matured, the frequency of crippling my CQ instance has decreased.  Maybe its from more experience, although I am more inclined to believe it's the stability of the platform.

A plug for CQ's stability - I love telling this story.

[Plug:start] Rewind about 3 years.  The company I worked at essentially revoked system engineering support for us after the project launched.  So our CQ 5.3 instances ran for little over year with little or no systems administration: cleaning up old workflows, version purging, binary garbage collection, etc.....  Nothing, no love.  The only time we had down time was when it was scheduled for quarterly application releases.  I know our site got lots of traffic, I cannot remember how much, and the author cluster had about 2 dozen or more people banging on it daily: video uploads (we had ~3-5 G of digital assets), etc etc.  Even on CQ 5.3 - the architecture had tremendous stability.  The Vignette VCM we used prior to that needed daily handholding to simply not fall over...it sends chills down my spine. [Plug:end]

So I got sick of coming up with ways to quickly reconstitute my CQ environment andconfiguration: using backups, CQ packages, remembering which backup was the right one, remembering to delete old backups, what filesystem to store the backups on, blah blah blah.  I'm not sure I can remember what I had for lunch yesterday let alone what, where, which one.  Not to mention the disk speeds were terrible.

Today I decided to install CQ 5.5 SP 2.1.  PLEASE READ THE RELEASE NOTES.  Here are the release notes from Feike Visser's tweet a day or so ago.  Yeah, I didn't read them.  So when the popup opened after installing the package, I dutifully stopped and restarted my instance.  It never came back up.  Sometimes when the SlingRepository wont restart, deleting the Lucene indices will do the trick.  No such luck here: I didn't read the destructions.  The instructions stated that you DON'T restart immediately because there are background processes doing "stuff" that need to finish BEFORE you restart.

OK, so how to recover the state of my instance?  I simply stopped my AWS instance, and then restarted it.  Because my instance is setup to NOT persist on shutdown, I can delete all of the files on the filesystem and not care one bit.  When the instance shuts down, it's current state is lost completely.  Within 5 minutes I am back up and running.  Deja vu all over again.

So like most things there are still tradeoffs.  I can't keep the admin/admin username/password,  I changed that immediately.  I have to be sure that I create AMI snapshots to preserve a state I am interested in.  I usually keep 2 or 3 snapshots just in case.  The disk space cost is pretty darned low, and is well worth it for the relief of juggling disk space locally to manage a local snapshot.  The AWS speed is pretty good for creating snapshots as well.  Even if, heaven forbid, my house burns down or my dog decides to use my USB drive as a chew toy, thats fine.  My "stuff" is on AWS infrastructure, and I can sleep pretty good knowing my data isn't local.  AWS hardware is almost guaranteed to be more safe than mine.

The other safety net is that not only is my CQ instance safe from binary hazards, so is my whole Ubuntu OS that CQ runs on.