Responsibility and Authority

At my last job I was the default MongoDB administrator. I lived in the Mongo shell all day for almost a solid year and I definitely used it more than any other developer, so that meant all things Mongo came to my inbox. Someone needs a document (or series of documents) updated? Send it to Ryan. Someone needs a new collection, needs data migrated from one server to another, needs to test connectivity, needs data exported? Send it to Ryan.

As our platform became more stable and more websites were deployed on top of it, Mongo began to wince a bit with the added activity. We started having odd issues with our production replica set and of course part of the investigation landed on my lap.

The point of this post is that even though the responsibility for Mongo was obviously mine, the authority to do real work was not. I could work with production data, but not SSH to the production machines.

How was I supposed to successfully see what might be causing issues in production if I couldn’t get on the box and look at the logs? How could I watch a process or look at the network activity? I couldn’t. I wasn’t given the authority to connect and do my work.

I’ve seen this happen several times in my career. I end up responsible for things, but have no power to do what I need to do in order to fix problems.

I’m happy to say that I’m getting better at identifying situations where I’m stuck being responsible without any authority to affect change.

Responsibility and Authority

Azure Fatigue

The battle rages on with Microsoft Azure. Having come from a solid year of working with Amazon’s EC2, I find working with Azure to be very frustrating at times.

A recent example is how the IP addresses – both public and private – change on instances.

For example, I have a cloud service that is up and running with a production instance and a staging instance. The private IP addresses end with .11 and .12.

I deploy my project to the staging instance and then swap staging and production once I have verified that staging is good.

What is the state of things now?

Now I have private IP addresses that end in .10 and .12. The address that ended in .11 is gone and now I have an IP with the .10 address that is not allowed to communicate with other machines since it is unrecognized.

I remember going through similar pains with EC2 (getting machines to communicate internally), but at least EC2 kept things consistent. The IPs would stick on a box that wasn’t stop and restarted. If I just rebooted a machine, the IP address would stay the same and I didn’t have this tight deployment integration that does “magic” for me.

Azure Fatigue