The systems engineer who can recall back to late nights spent testing their systems for Y2K bugs will probably be very hesitant moving a system and data out of their total control and out to the cloud, even though “everyone’s doing it – it’s all the rage” doesn’t add a bit of weight to the thought. However, once the one who signs your check says to “make it so, I understand and accept the risks”, the cloud couldn’t be a better place. Although people can debate what the cloud really is, the definition I’ll use is the following: any system or resource that isn’t in your complete control that can only be accessed via the internet, and you don’t have an associated electricity bill.
There are a number of leased line company choices and that number is still growing as big names fall over themselves in an effort to get a piece of the pie. We chose to go with Amazon Web Services (AWS). They have been in the cloud business since the start and have a very impressive list of companies which rely on their infrastructure for their core business, including themselves. The online retail numbers for Amazon.com during November and December are staggering, and the system demands are even more staggering. Simply put, they’ve got more on the line for uptime and accessibility than I do for my internal iSupport system.
If you are completely new to AWS, Infravio has a great tutorial, take some time to review their documentation and understand their terminology. There is a lot of it. In simple terms, EC2 is “Elastic Compute Cloud”—think a massive virtual machine space; an “Instance” is your running machine profile consisting of memory, compute units, and volumes. “Reserved” can be thought of as a reduced rate when paid in advance, which is really just an accounting mechanism. For a system like iSupport which should be on and working 24/7, that will always be High Availability. Added volumes are for storage. Simple Storage Service (S3) is for data caches, which aren’t needed for an iSupport installation as the iSupport product itself manages the capture and presentation of the web data.
A virtual private connection (VPC) is needed to permit Windows pass-through authentication and asset scanning in your local domain. To set this up, you’ll need to coordinate with the folks who maintain your router configuration. There are a few other ways to link your network to the AWS server, but that is between you and your security team. (We are not going to try to pretend we know the security and connection method that is best for your organization.) Today with browsers that recall logins and passwords, the built-in iSupport forms-based authentication is simple and effective.
There are many more features and capabilities that AWS can offer, but in most cases an iSupport installation can be kept simple. An instance can be started from a simple basic system that we have set and configured. If your database versions match, it’s as simple as waiting for the SQL databases to transfer and attach to the SQL server. Once an instance is defined and running, it’s accessed like any other remote Windows server. You are still responsible for backups, so establish a plan to back up your SQL data regularly, ideally to a separate defined volume. Once your server configuration is defined, take a snapshot of the server’s storage volume. OS updates also need to be maintained, so take a snapshot before and after any update changes so there is an easy rollback plan. You can restore the snapshot and save a few hours of downtime if ever the need arises.
Once it’s all in place, configured, and running, your local computer room is a bit quieter and cooler. It suddenly hits you that there is one less resource that you need to worry about. No power concerns, no HVAC concerns, no fire suppression system to test and maintain, no concerns for flooding, no physical security concerns, and no hardware to age, replace, and amortize. It’s potentially available anywhere in the world at any time. Life just got a bit better.
You gain a speedy system. I haven’t found documentation that quite explains it for reference here, but the servers are built as virtual equivalents to a physical box server. That equivalent is leveraging the scaled processing and optimization done by AWS. Although the system spec may seem small compared to a physical system, it works much faster than the same data on an equal physical system. If the instance you first selected is a bit overwhelmed, you can change the instance memory and compute units without losing your configuration and you can tune it to best meet your needs for pricing and performance. The m1.large is a good choice but I wouldn’t suggest anything less than an m1.medium. (Be sure to DEACTIVATE your iSupport license BEFORE making server profile changes.)
Looking back, the journey wasn’t that bad. It may have seemed overwhelming at first, but now that we’re on the other side it was actually fairly easy and well worth it!
