While researching Hurricane Irene, I came across a story about the 3rd U.S. Infantry Regiment — known as “The Old Guard” — guarding the Tomb of the Unknown Soldier at Arlington National Cemetery in Virginia throughout the storm.

As Monday evening rolls in and the east coast is dealing with the aftermath of the storm, I wondered how we fared in guarding our most precious asset – our customers’ data. So how does a world-class service organization protect against a devastating weather event?

Plan & Prepare: At Internap data centers, we have an Emergency Action Plan that we quickly put into action 96 hours before the storm. This plan outlines steps and details at the 96, 72, 48, 24, 12 and 6 hour marks. It covers critical steps such as working closely with building management, fuel vendors and security, assessing and procuring supplies and equipment, scheduling shifts for onsite personnel and providing travel arrangements and finalizing evacuation procedures.

Communicate: Our Network Operations Center (NOC) is the heart of all communications to our customers 24/7 – storm or no storm. Our goal is to communicate proactively with our customers frequently and with as much information as possible so that they know exactly what is happening and what we are doing in response. In fact, during the most intense part of the storm, we communicated to our customers on an hourly basis.

Support: Additional engineers were also brought on-site to assist customers and provide other support services should any issue arise throughout the event as we take our recent customer service award very seriously.

As expected, our four data centers in the New York and Boston areas weathered the storm unscathed. Our customers told us they appreciated our timely communications throughout the event and that we were a primary source of information for their own business planning and decision making. Neither rain, nor sleet, nor Hurricane Irene can stop Internap from providing you with 100% uptime and availability.

One of the more common discussions Voxel sales engineers have with potential clients is around whether staging environments are a necessary part of a hosting deployment. Our answer is always a resounding YES, especially for critical web apps undergoing rapid development. Unfortunately, staging environments often have a bad rep — some developers see them as a throwback to less agile programming days, product managers just feel there are too many extra hoops to jump through to see their latest feature and business owners often just see the cost and think its an extra expense.

Luckily Voxel has a team of great sales engineers who have years of experience and knowledge around managing high performance web stacks. They know that the secret to every great production environment is a solid staging setup behind the scenes and a true commitment to testing each software change against the staging infrastructure.

What is a staging environment, exactly? In the Voxel world, it’s a reproduction of your production deployment – machine configuration, build specifications, application versions, etc. – that is used to “stage” upcoming code releases. All releases are tested first on staging and then pushed without changes to the production environment.

To make swallowing the cost of staging environments more palatable, Voxel leverages our flexible, on-demand infrastructure options to fluidly create, expand and destroy staging environments using automated configuration and deployment tools. This not only streamlines the process, but lowers costs and increases the accuracy of your environment configuration.

In order to build a proper staging to production workflow, however, several other things need to be in place in your software lifecycle. Let’s review them here:

#1 – Develop It
Developing software is where it all begins. The team may be just one person or a distributed set of workers around the world constantly adding code to your application. Either way, how you develop code and manage that workflow needs to account for the staging and production role separation.

Most of our customers develop locally on individual work stations or in the cloud via VoxCLOUD servers and shared dev environments. And in these cases, a virtualized setup can be really advantageous. Each developer can have a ‘production like’ environment without the cost or overhead of operating large server groups for each developer. Or, they can clone an existing dev environment to test out a major upgrade or a set of code changes as part of their workflow. Plus, with the automation behind Voxel’s infrastructure products, many developers simply have Voxel build a pre-configured dev environment on demand each day, powering it off or destroying it when not in use.

#2 – Repo It 
Again, regardless of if you’re 1 developer or a huge global team, using a code repository like SVN and Git is a critical part of the development process. Beyond their uses in the actual development process, these code repos are great for automating deployment, testing new code and most importantly, rolling back to previous versions of code if something breaks. If you’re interested in learning more about various code repo solutions, look for more information in future posts where we’ll be dissecting a few different tools and strategies.

#3 – Stage It
Your staging server should really be for two main things:

• Testing code changes against production level libraries, versions and permissions (where only the code has changed)
• Allowing developers to step out of the deployment process and put operations people (such as Voxel’s ProManaged support engineers) in charge of releases and rollbacks.

A staging environment allows you to separate your development server, with its ever-changing code, from your production environment, which should be the final product pushed to customers. You can catch bugs, performance issues, version conflicts and other critical issues before you put any code into your production application environment. When new code is pushed into production on release day, you can feel confident that those mysterious differences between your dev server and production server won’t exist and you’ll enjoy a worry-free upgrade.

Configuration Management To the Rescue
To those that have managed dozens or hundreds of servers before, they know that keeping the production and staging environments “in sync” can often be a challenge. Over time, one environment might get a slight version upgrade or software patch that the other didn’t. Or a reboot on the staging side may cause a new kernel to be put in place that nobody noticed. This kind of variation completely eradicates the benefits of the staging environment (because it no longer perfectly matches production!) and can be deadly to any kind of testing regime.

To solve this problem at Voxel, we’ve integrated Opscode’s Chef platform for configuration management and cloud infrastructure automation into our internal tools and customer deployments. Chef allows Voxel to quickly and accurately scale server infrastructure and to rebuild any environment exactly the same way every time. This kind of configuration automation saves development time, trouble shooting, and system administration hours. This all leads to saving money as well as having better uptime and quality.

Using a robust configuration management system like Chef is incredibly important when moving from staging to production. It ensures the accuracy of your IT configuration and makes sure everything is installed, configured, permissioned and tasked just like your production side. Once you know your staging environment matches your production side exactly, you can effectively test on your staging environment and feel confident when it comes time to push that new code to production.

Conclusion
Despite popular belief, most downtime is not caused by network outages – it’s caused by application changes, unknown system variances, exploits and conflicts. Staging servers help you mitigate these issues, while also giving your hosting partner the proper process and control to support the uptime of your production application. With per-hour VoxCLOUD and VoxSERVER infrastructure, automated configuration management using Chef and a comprehensive approach to your dev to testing to production code process, you can easily obtain better performance and high levels of uptime for your application.

How many times have you heard people complain that customer service is dead? That no one cares and that companies only want to make money? Everyone has a horror story about being placed on hold as endless minutes, that seem like hours, tick by. When you finally talk to a rep, they are uncaring, rude and sometimes downright nasty. At the end of it all, you wonder if anyone is going to take ownership of your issue.

I recently came across some stats on “the price of bad customer service” that got me thinking. Did you know, for example, that a whopping 67% of consumers surveyed* in the U.S. alone ended a business relationship due to a poor customer service experience? Or that the improvement most asked for by consumers is “better human service”? Or that the most important factor in a satisfying customer experience is a “competent customer service representative”?

More importantly, bad customer service affects companies’ bottom line, and ultimately industries as a whole. U.S. businesses lose $83 BILLION each year as a direct result of poor customer service. So don’t just give lip service to the notion of good customer service. It will cost you more than lost customers.

By the way, I am pleased to tell you that customer service is indeed not dead but alive and thriving at Internap. In fact, our annual customer support satisfaction rating on a scale of 1 to 10 is an 8.62 compared to an industry average of 8.31 and a peer group average of 6.9.**

*Source: 2009 Genesys Global survey of Consumer Attitudes
**Source: 2011 Customer Satisfaction Survey conducted by Technology Services Industry Association(TSIA).

VoxCLOUD for Android will allow you to…

• Monitor the status of your devices
• Perform health-checks on all of your servers
• Provision VoxCLOUD / VoxSERVER devices
• Delete VoxCLOUD / VoxSERVER devices
• Check on access credentials
• Store settings for quick provisioning of common server types

Get It Now!

The project source code for VoxCLOUD for Android is now available on GitHub. We have included non-activated future functionality in preparation for Voxel’s real-time device events messaging api which, when we “switch it on”, will push notifications about your Voxel servers directly to your Android devices. These push notifications combined with Android Intents will give you real-time insight into your Voxel infrastructure. Look for these features soon, in an upcoming update.

If you  are planning on customizing or contributing to the source, our API, hAPI, is totally abstracted in code.  This means that adding any API features from api.voxel.net will take just minutes for VoxCLOUD. One thing to note, however.  With the mobile landscape changing so quickly, we have found that the VoxCLOUD Android app performs better on newer devices that are running the Tegra2 processor. And the Tegra3’s are already planned for year end release in both phones and tablets, talk about Moore’s Law times Two.

This application requires the Adobe Air runtime which is automatically installed with the app if it hasn’t already been installed before by some other application. This applications runs on the AVM – or the Actionscript Virtual Machine inside the JVM – Java Virtual Machine… I know it sounds like the plot from the movie “Inception” – but the reason we chose to use the Adobe Air API was because we already made our Desktop application with much of the same code source: VoxSTRUCTURE. We expect Adobe Air runtime to get more mature and this will help improve the app over time in areas of performance/memory usage.

Source available under GPL: https://github.com/voxeldotnet/voxcloud-air