Skip to Content

AppZero

EC2

Amazon EC2, Solaris 2.6, and the San Andreas Fault

As it turned out, the brilliance and competence of Amazon’s technocracy were no match for simple human error. An incorrect manual update to the network set up a domino effect of Catch-22-esque compound failures to Amazon’s EBS (Elastic Block Store) details of which can be found in a 6 page explanation the company offered last week.

Although cloud naysayers will no doubt try to make this event the poster child for Luddite agendas, it won’t work. Data was lost. Business was lost. News was made. But overall, the fallout has not been too bad as users have quickly come forward to stand by Amazon and the choice to use its services.

And the risk was largely knowable. As Jason posted in an article On Cascading Failures and Amazon’s Elastic Block Store  “This is not a “speed bump” or a “cloud failure” or “growing pains”, this is a foreseeable consequence of fundamental architectural decisions made by Amazon.“ 

The gains surpassed the risk. And will continue to do so. Though still in its early stages, life in the cloud is really a lot more of a learning experience than it is an adventure. Everyone involved will continue to get a little wiser in the ways that only experience – usually bad ones – can confer on those gaining the wisdom. 

As the only software vendor offering patented technology to virtualize Windows, Linux, and Solaris server applications – AppZero is a huge fan of all things cloud. We invite our customers to move their applications to and from datacenter and cloud(s) and cloud to cloud, with no lock-in. I’ve seen the hesitancy that comes from skepticism and trepidation as well as the high fives and smiles that accompany seeing and believing.

But here’s something I’ve also seen that I will never understand: Organizations running very important (though not “mission critical”) Solaris 2.6 applications on hardware that is past the hope of life support. The hardware will fail and take with it the applications. When I say, “It’s not a matter of if … it’s when.” I get knowing chuckles and head shakes as IT pros tell me how very right I am. 

When I go on to tell them that AppZero software can encapsulate their Solaris 2.6 and 7 applications, pick them up, and deposit them on Solaris 10 and bright shiny, inexpensive, reliable machines, all without a line of code … they are intrigued. Of course they are. Here’s a very cost-effective solution to a guaranteed problem.

Okay.  So here’s the question: Then why doesn’t every one of them just jump up and sign on with AppZero? Human nature or human error? Have they lived so long in denial that they’ve crossed over into magical thinking, convinced that because it hasn’t happened … it won’t? Or do they expect to be in new jobs before the when = now?

Cloud risks pale against cloud gain. Life on the San Andreas Fault brings a great lifestyle until the big one. But important apps on Solaris 2.6?  I don’t have a clue so feel free to send me one. In the meantime, let’s cloudify those Windows and Linux client/server apps – no code, no lock-in, no pain.

I am always looking for a way to communicate better and cut to the heart of any discussion. So, if you have thoughts on this subject, drop me a line at GregO {@} Appzero {dot} com or tweet me at http://twitter.com/gregoryjoconnor

In Practice: From your machine, to EC2, and back in 1 minute

Agile development and deployment workflow

This series describes a development and deployment process optimized for the needs of software-as-a-service in terms of cost structure, agility, staging and test requirements.  The resulting system will tolerate the failure of a local hard drive and crashes of a machine - physical or virtual.  Offering good performance / low cost via Amazon's EBS and EC2 services, the system will provide the ability to rollback changes both on the deployed and development system (independently or together) using Subversion.

You can enjoy instantaneous feedback when you are developing code without affecting existing users of your website by using a two machine development and deployment lifecycle.  Deployment can be a 5 second experience (as opposed to 5 minutes) using AppZero technology.

I have tried a number of lifecycle workflows for the development and deployment of Drupal websites. In this series, I will describe a two machine approach involving a local development and test machine and a deployment machine. Deployment of files will use the Subversion Version Control System; the local machine is Windows to make tools like Photoshop convenient to use; the deployment machine is a Windows machine from EC2; and we will use Apache, Drupal, and MySql.

The one-machine approach, topologically simplest, involves developing directly on the deployed machine on the Internet. I've found this approach, while seemingly simple, to have two serious deficiencies:

  • developing a new feature for a site can often involve accidentally breaking existing functionality or look-and-feel. This topology makes it difficult to evolve a site without showing the public every intermediate change.
  • tools like Photoshop  are not convenient to use on a remote basis and ftp'ing files back and forth is a cumbersome process. Even text editing on a remote machine incurs painful latencies.

For these two reasons, I advocate at least a two machine approach. This allows you to develop on your local machine, disconnected from the Internet if necessary, with all the tools you like, and deploying when you desire. Of course, in a two machine topology approach, deployment agility becomes paramount. The difference between 5 seconds to deploy and 5 minutes makes the difference between wonderful and painful.

In Practice: Agile and Scalable Site Development with Drupal, Appzero, and EC2.

Like a lot of folks, I'm excited about the possibilities that arise when you combine the agility of modern CMS's (like Drupal and Wordpress) with the scalability and administrative control offered by Compute Clouds (like Amazon EC2 and GoGrid).

In my work as VP of Technology here at AppZero, I've had the opportunity to work with a number of web site and web app developers who are trying to realize this potential. I've seen first hand that there are a lot of unwritten, but critical, details we must know to capitalize on this power.

This entry is the start of a blog series in which I'll share my viewpoint -- and I welcome your participation.

I'm going to kick off this series by sharing my experiences in developing, deploying, updating, and scaling out a Drupal installation in Amazon's EC2 Compute Cloud. I'll let you know what's worked and what's failed. I'm hoping I can make your life a little smoother so you can avoid some of the pain we've gone through -- and get right to the good part.

I'll be writing at least one entry a week.  Here's my plan:

Part 1: An agile development and deployment workflow: from your machine, to EC2, and back in 1 minute.
Part 2: Getting Drupal on your Windows machine in 5 minutes.
Part 3: Developing your site.
Part 4: Provisioning an EC2 machine.
Part 5: Moving your Drupal development site to the EC2 machine.
Part 6: Updating your Website and redeploying in a matter of seconds.
Part 7: Scaling out your website.
Part 8: Concluding comments.

Join me on this journey by commenting on the blog or writing me directly at chu@appzero.com.

 

Syndicate content