Amazon’s Web Services have been getting better and better, but typically by incremental amounts. Up until now, it’s been a slow trickle of improvements to a solid suite of offerings. Cheap storage, cheap computing power, cheap access to PCI compliance, etc.

This new offering however, may truly be a game-changer for their web services division. Amazon’s Virtual Private Cloud lets companies create their own isolated set of EC2 instances and connect them to their own existing IT infrastructure through a VPN connection.

What does all that mumbo-jumbo mean to the business management people? Simple. Now you can augment your IT’s infrastructure without huge capital expenditures. EC2 already runs Windows Server 2008, SQL Server, Oracle Database 11g, IBM DB2, IBM Websphere and many more.

Amazon’s immensely powerful infrastructure is available as a service at prices that will make you wonder if you should bother with your own hardware anymore.

Today Amazon made a couple of interesting announcements.  First off they have opened a new region (Northern California) with multiple availability zones (analogous to data centers, but each on separate flood plains and electrical grids).  This further increases their computing capacity and also puts data closer to all of the start-up’s in the Bay area that rely on Amazon.  The also have a US-East region, EU region and will have regions in Asia in 2010.

The key announcement however centers around some changes and enhancements to EC2 (their virtualized computing layer).  One of the main criticisms and design challenges with EC2 has been around the fact that when you shut down a server, the state of that server is lost (unlike VMWare).  There were ways around it (such as storing all data on EBS (analogous to a mounted drive on your virtual instance), but it did present some challenges.  Today they announced the availability to save server state with a new Stop command, which unlike Terminate, saves the state of that running server.

This feature is enabled because you can also now boot from EBS, instead of S3.  This leads to a faster boot time, and also makes it easier to tune your kernel or make other changes to an image.  Upon boot you can also mount multiple EBS volumes which can lead to some very robust configurations.

Another challenge of EC2 was creating an image (AMI) of a server once you had it set up.  This was fairly easy for a windows instance (using the Bundle process) but was more difficult for a Linux instance.  Now you can use the CreateImage command to create a new AMI and register it in one easy step.  See all the details here.

These are great enhancements to EC2 and are a welcome addition to the AWS offering.

We have had a lot of great interest in Cloud Loader, so the next question is "How do I start using it?"  Well, here is a simple 5 Step guide to get going with Cloud Loader to start doing integration for $0.10 an hour (or less with a reserved instance).

Step 1 – Sign Up for EC2
 

Step 2 – Sign into the EC2 Management Console

The Console is where you can go to create and manage your EC2 Instances.  Remember these are virtual servers and the console allows you to give them a static IP (Elastic IP), control the Security Group and stop and start your instances.  First off you need to create a new instance of the Cloud Loader AMI. 

Step 3 – Create a Cloud Loader Instance

Click on Instances→ Launch Instance→ Community AMIs and search on “Cloud_Loader” to find the Cloud Loader AMI.  Click the Select button.

After clicking Select you need to specify some specifics about your instance.  You will only need one instance and it can be a “Small” instance which will be fine to run the Cloud Loader.
 

Next click on “Create” next to the Key Pair Name option, enter a name for your key pair and download the key pair.  This will be required to SSH into your Cloud Loader instance.

 
Next you need to pick a Security Group for the instance.  You can use the default one or optionally specify other settings (which ports will be open).  EC2 by default has all ports closed except 22 for SSH.

Last Click “Launch” to launch your instance.  This will take 3-4 minutes to boot and fully launch.

Step 4 – Connect to your Instance

If you are using a PC you will need to use an SSH client such as PUTTy to log into your instance.  Click here for Windows instructions.

If you are using a Mac you can use the native terminal to connect.  Click here for detailed instructions on how to set up your certs and bash profile.

Step 5 – Configure your Instance

(Remember this is built on Apex Data Loader, so look here to learn more about it)

•    After logging in go to the /usr/local/dataloader directory
•    Create an FTP user on the Cloud Loader instance to use for the inbound FTP of data (the .csv file you want to load into Salesforce).
•    Edit the config.properties file with your username and password for SFDC
      Note: You will need to include your security token at the end of your password if you don’t whitelist the Amazon Elastic IP within Salesforce
•    Edit the process-conf.xml file with the data loader processes you want to run
•    Edit the automate-dl script to configure the email address you would like to use to send reports to.
•    Setup a cron to run the automate-dl script (the way you schedule automated processes in UNIX)

Final Notes

Once you have tested this approach it is likely you will want to modify the script or approach to suit your own business need.  With EC2 you can use Cloud Loader as a base AMI and then configure your own AMI based upon it with your own unique additions. 

You may also like to utilize EBS (Elastic Block Storage) with Cloud Loader to have persistent storage of your configuration files, incoming integration files or log files.  We plan to add this functionality in an upcoming release.  If you have any further suggestions for Cloud Loader, please email us at:  support@modelmetrics.com

So why do I need a server again to integrate with the cloud?

Historically one of the arguments against SaaS, or now “The Cloud” was that integration is difficult or expensive.  Several great providers have emerged in this space to make integration with cloud platforms inexpensive and more recently, even cloud based.  These approaches are great for many companies, but as you know one size doesn’t fit everyone and many companies don’t want to bring in another vendor.

Salesforce has made integration somewhat of a commodity with it’s constant improvements to the DataLoader application.  Most of you are probably familiar with it, but if not, it is a Java based client side tool that allows you to load data into Salesforce.  It can handle all of the basic CRUD operations you might expect.  It now supports direct database access as well so you don’t have to rely on .csv flat files as you did previously.

The other great thing about DataLoader is that you can take the JAR file and run it in a scripted and automated fashion to get integration on the cheap.  This approach works well to master customer data from an ERP system, or update nightly financials or orders.  It can also pull data out of Salesforce to feed a Data Warehouse for example.

The only issue, you need a server to host this puppy on.

As you know the “clouds” are converging and Salesforce, Google and Amazon all play well together.  So why not leverage the Amazon cloud to handle this type of integration?  Good news, it works great on Amazon, and is freely available for you to use.

Cloud Loader is a free pre-packaged AMI (Amazon Machine Instance) that you can literally have up and running in a few minutes and have data flowing into or out of Salesforce in the cloud.  It is based on Data Loader, but is fully automated and even has email notifications buit-in.

Cloud Loader does require that the data coming into Salesforce be available on a FTP server that is accessible from an Amazon EC2 Instance.  All you need to do within  Cloud Loader is add your mapping file as well as your Salesforce and FTP credentials and you are ready to roll.

If you want to give this a try, click here.
 

You can follow Reid Carlberg on Twitter or email him at rcarlberg@modelmetrics.com

We’ve used Amazon Web Services in my department, but I wasn’t very close to the project.  So when I had a chance to take a deeper dive, I jumped at it.  Here are some of the things I learned.

1. AWS Dropped prices on their SimpleDB service by 83% on December 1, 2008.  Holy. Moly. Talk about a great illustration of the difference between storing stuff in the cloud and doing it yourself.  And there’s a fair chance you’ll be able to use it for free.

2. One government agency was looking to do a proof of concept on a project.  If they would have bought computers, they would have had to spend about $30,000.  They couldn’t get approval so one of the people involved launched it on AWS’s EC2 service.  Total cost?  $5.  You read that right.  Five dollars.

3. Animoto, the coolest photo to video site on the web, scaled from about 40 servers to almost 5000 in three days.  40 to 5000.  Wow!  If they were handling their servers any other way, they wouldn’t have been able to do that.

4. All kinds of organizations are doing interesting things on AWS.  From the New York Times to Harvard Medical School to ….  you name ‘em, they’re probably doing something on it.

5. There are 490,000 AWS developers.  That’s about the population of Cleveland.  Imagine.

5.5. It’s easy to do complex tasks.  Watch for a new open source contribution from me on this one soon.