My life, in Code

This is a story about expectations in the service industry, and the impact of missing those expectations.

My wife and I recently moved into a new house, and as part of the process we ended up making a few tactical capital improvements & purchases. One particular purchase we hemmed and hawed over for a few months, debating between brands and features, etc. In the end, we decided to go for a-not-quite-top-of-the-line model from the top brand in the market.

The thing that drew us to this brand in particular was their reputation; We liked the security of knowing that when you invest in an expensive purchase, the company will stand behind it. That's how companies build such reputations. When I went through my rookie orientation at Rackspace, it was preached over and over about Nordstrom and the reputation they've built that now extends far beyond the boundaries of the retail industry; about how Rackspace aims to have that level of service (and reputation).

Needless to say, less than a month after said purchase, and on the second use, it decided to just not work. I tried everything I could think of, but to no avail. I couldn't figure out what to do other than call my sales rep, who had handled every part of the process including delivery for me.

Upon description of my issue, he said he knew the likely cause, and I shouldn't be alarmed; usually it was a minor fix, but they'd have to do it at their service center.

Here's where things went awry. He said, "Of course we'll take care of it for you, we'll stand behind you, but, we'll need you to pay the pickup and drop-off fee."

And with one innocuous little statement, my expectations were shattered. I had to explain to the rep that, "no, I won't be paying for pickup and drop-off," and that "It's brand new, and has basically not been used." He of course apologized, and explained that he could talk to his manager and "pull some strings".

In the end, they came around and "covered for me this time" after I insisted that I wouldn't be paying, but this only underscores how little the dealer understands about service.

The reality is that every product or service you can buy has problems from time to time. Cars might come from the factory with a cracked power steering pump (My father's SUV), clothes may have a seem that wasn't sewn quite properly, servers might have a dead main-board, but in all of these cases, it's not how the problem manifested, it's how we deal with the problems as representatives of the companies.

If the dealer in this case had said, "I'm sorry you had a problem, I'll have my service guy coordinate a pickup with you." the conversation would have been over. And I would have sung the praises of their treatment with my family and close friends. But as soon as they communicated their expectation that I pay for the service call, it said to me, "You are not our partner, you are a resource to be exploited." It was compounded by the treatment where the Sales Representative convinced me that he was "going above and beyond to take care of me" after he was the one that tarnished the experience in the first place.

As of version v0.8.7, pkgcloud now supports Rackspace Cloud DNS. By itself, this isn't particularly newsworthy, however, when you consider that Rackspace Cloud DNS is currently a free DNS service (you only need to have a Rackspace Cloud account) that you realize the impact adding this to pkgcloud has.

DNS is designed to help abstract away the specific IP address or provider generated CNAMEs, and Rackspace Cloud DNS allows you to do this at no extra cost.

Creating DNS records for your cloud assets has always been an important part of a provisioning platform for any cloud based application. Consider the resources you need to manage when you're using load balancers, spinning up and tearing down new compute instances, utilizing multiple network interfaces per instance, and even leveraging multiple datastores and provisioning regions.

When I was helping build Clipboard's* infrastructure, we created DNS records for the public and private interfaces of every compute instance whenever we brought up new instances, for example: web-03.private.prod.clipboard.com and riak-07.stage.clipboard.com. We also used DNS for our load balancers, our work queues, and even external services that we depended on.

Considering the price (free!), and how easy node.js integrates with web APIs, there was no reason to not leverage the awesome service. Now that we've added it to pkgcloud it's even easier!

In this example, I'll show you how to add a Zone to your cloud account, and create a record with pkgcloud and node.js

var pkgcloud = require('pkgcloud'), config = require('./my-config.json'); var client = pkgcloud.providers.rackspace.dns.createClient(config); client.createZone({ name: 'mydomain.com', // the domain to use for the zone email: '[email protected]' // this is the SOA contact email address }, function(err, zone) { // handle your errors appropriately in your application if (err) { console.dir(err); return; } zone.createRecord({ name: 'www.mydomain.com', data: '192.168.0.1', type: 'A' }, function(err, record) { if (err) { console.dir(err); return; } // use your newly created record here }); });

As you can see, creating a zone and adding a record to the zone is very straightforward. You can read more about the records interface and zones interface for Cloud DNS on github.

In a way, the bus ride 90 minutes north of San Francisco set the table for what the attendees had in store for the 4 days we'd spend in the hills of Marin County. There were introductions, stories swapped, jokes made, and sights to be seen. But the most significant part of the bus ride  was that most of the attendees were all experiencing it together.

NodeConf was a markedly different Conference. For the first time in 2013, NodeConf Summer Camp and NodeConf proper were merged into a single event at the fantastic Walker Creek Ranch north of San Francisco in Marin County.

Photo courtesy Lyle Troxell

Instead of traditional presentations, the sessions were classroom focused with core contributors and community members running them. Everyone had an unique schedule to maximize meeting new people, and getting exposure to a number of different topics.

The sessions were great, if only because of how broad the topics were, but it was what happened outside of the conference schedule that made NodeConf shine for me.

Most of the conferences I've attended have been more formal in nature. At a convention center or hotel, with sessions running during the standard working day, and usually ending at a reasonable hour in the evening. Even when these conferences host parties or evening activities, there's an inevitable scattering at five or six o'clock that results in most groups coalescing around already established relationships.

In contrast, NodeConf had a "captive" audience. The result of this was a fantastic inter-mingling of folks that might not otherwise spend time getting to know one another. 

For example, during nearly every open period, games of 4-square broke out. Who knew that 4-square would be an unifying force in the Node community? At one point on the final night we had three games going simultaneously, but it wasn't about the game as much as it was building new and strengthening existing relationships. 

We even had a veritable Kum Ba Yah as everyone joined Paul Campbell in singing a verison of The Auld Triangle during one nights after dinner activities in the amphitheater.

In the end, NodeConf was community building at it's finest, and is exactly what makes me so excited for future of Node, our community, and gets me motivated to take part in shaping where things go from here.

This week, I was granted commit permissions on nodejitsu/pkgcloud. This is a huge indication of trust from the folks at Nodejitsu, and not something I take lightly. Early in my career, while at drugstore.com, I learned the difference between ownership and stewardship, and it's something I still carry with me:

Stewardship is an ethic that embodies the responsible planning and management of resources. The concepts of stewardship can be applied to the environment, economics, health, property, information, religion etc. Stewardship is often linked to the principles of sustainability.

Part of what was so appealing about working for Rackspace was our approach to Open Source Software and being part of the OpenStack community. Take a look at our node.js SDK plan as a perfect example; rather than build our own package, let's go out into the community and make the best cloud provisioning package even better. It's about being responsible members of the community and being good stewards.

The funny thing about stewardship in the OSS community is that it applies even before you're a core maintainer of a project. To a degree, it's fundamentally part of what makes a community healthy and vibrant. Just like when I mow my neighbor's front lawn or they watch my girls when they play in front yard, it's about having each other's backs and filling in the gaps when necessary.

The reality is my workload probably increases as a core committer. The bar must be high for the core team, and I need to ensure my commits always reflect the standard of quality we're hoping to achieve for Rackspace as a company, as well as as a member of the vibrant #node.js community.

I've been spending a fair amount of time looking at the OpenStack and Rackspace compute API implementation (in preparation for a future major update to pkgcloud) and I realized that it's very easy to make a change to a signature and not realize the cross-provider impact it may have.

For example, consider this multi-provider example:

var pkgcloud = require('pkgcloud'), providers = ['amazon', 'joyent', 'rackspace', 'azure', 'openstack'], async = require('async'), helper = require('helper'); // Loop through our providers and create a client async.forEachSeries(providers, function(provider, next) { var client = pkgcloud.compute.createClient(helper.getProviderConfig(provider)); // Create a new server, and then add a key client.createServer(helper.defaultServerOptions(provider), function(err, server) { client.addKey({ name: 'my-key', key: 'some-key-value' }, function(err) { next(); }); }); }, function(err) { process.exit(0); });

The point is that a subtle change in how one of the providers parses options for either createServer or addKey could result in a failure.

Obviously, we should have test cases for these (we do for a fair number already) but additionally, I think we can do some organizational changes to better communicate to future contributors the implication of being a cross-provider method.

It's been a few crazy weeks since I started at Rackspace, and while I've already been to San Antonio multiple times, as well as attending my first OpenStack Summit and meeting all of the awesome folks at the SF Rackspace office, I've spent the majority of my time getting up to speed on pkgcloud.

For the uninitiated, pkgcloud is a multi-provider cloud provisioning library from Nodejitsu for Node.js, with bindings for Rackspace, Amazon, Azure, Openstack, and Joyent compute clouds. The objective is to define a standard interface for cloud assets, such that you don't have to spend a significant amount of energy learning multiple APIs; you just focus on the integration.

For example:

var pkgcloud = require('pkgcloud'); var client = pkgcloud.providers.rackspace.compute.createClient({ username: 'myAccount', apiKey: 'myApiKey' }); client.createServer({ name: 'myServer', flavor: 2, image: '9922a7c7-5a42-4a56-bc6a-93f857ae2346' }, function(err, server) { // use your server here });

You could use any of the compute providers here, and (image/flavor details not withstanding) your createServer call will work. In addition to compute support, pkgcloud has support for multiple storage services, as well as a number of database providers.

What's Next?

My focus has been on getting the prerequisites out of the way in order to support Rackspace Next Generation Cloud Servers (built on OpenStack) and to refactor the Rackspace client to be based on the OpenStack client. Given these plans, I wanted to be clear about what I was hoping to get merged in as the v0.8 release of pkgcloud:

Rackspace client completely based on OpenStack

Support for Rackspace NextGen Cloud Servers

Continued Support for Rackspace Cloud Files (implemented as an extension of an OpenStack swift client)

Lots of samples, test cases, and documentation as appropriate

* Thankfully, working in #nodejs I don't have to worry about console being available (I'm looking at you IE).

Given that a number of people have asked about what I'm doing and why I moved on and so forth, I figured I'd share a little insight into what's going on. After spending nearly 2 years at Clipboard, I decided it was time pivot into something a little different. 

Working at a startup was the most exciting challenge of my career, and it opened my eyes to so many new things that it's hard to know where to begin. I was able to wear a ton of hats, write more code that I had in the previous 5 years at Microsoft, and work with great people.

Mostly, though, Clipboard introduced me to node.js, which has become the central point of my new role at Rackspace.

Officially, I'm a Developer Advocate with Rackspace, and leading Rackspace's node.js SDK efforts for the Cloud product APIs. Most of this work will be done in pkgcloud, a multi-provider cloud package. I'll also spend a fair amount of time at conferences talking with customers and figuring out what we do well, and where we can improve.

Unofficially, I get to work on cool stuff; contributing to a number of open-source projects, evangelizing our tech and culture, all while cutting my teeth as a conference goer.

It was hard to make the change, but at the end of the day, it feels like it was time to broaden my horizons, and be challenged in even more and interesting ways.