Azure Storage test drive

For the last year and a half I’ve been taking one class a semester at MATC in Madison. Having been trained as a Technical Writer, I’ve basically learned all this sysadmin stuff “on the job.” I figured it would be a good idea to fill-in-the-blanks for the stuff I didn’t learn yet. The classes require a external hard drive to house and manage VMs you use during labs and tests. Being 30 and having a full-time job allows me to buy really cool, really fast hardware to satisfy this class requirement. I opted for a 128GB Vertex 4. This thing SCREAMS. I get labs done in record time.

So how am I supposed to get my homework done if a spaghetti and meatball tornado comes through and wipes out the lower half of Wisconsin, taking my external hard drive with it?

TO THE CLOUD!

I’ve been using Azure at work for a variety of things so I figured I’d give this a try. I have 3 VMs and with them all zipped up (individually) I have about 16GB total to upload to Azure.

There are 3 Azure storage basics you need to know about: storage accounts, containers, and blobs. A storage account is the first thing you need in order to get started.

The storage account sets up the subdomain you’ll use to be able to communicate with your storage objects: yourstorage.*.core.windows.net. You also set the affinity group (location) where your content will be stored.

Once your storage account is up, you’ll need a container. Think of a container as a folder – only it’s not a folder – it’s a container. It holds your blobs – binary large object (i.e. your files). More on that in a bit.

Click Storage in the left-hand navigation

Click on the storage account name (my account is called “inhifistereo,” you can call your’s whatever you like)

Click containers at the top of the page > then click New at the bottom of the page


Now give the container a name and choose Public or Private

Private is just that; private. Meaning you have to be logged on (or have a Shared access key, but that’s fodder for another blog post) to access your stuff. A public container is cool because you can access it from anywhere as long as you have the URL. Click the checkmark and we’re good to go.

So a container is a container – like a folder, only it’s a container. And a blob is a file. The part that took me a second to understand is this storage isn’t like a fileshare up in the cloud. It’s the basic building blocks of storage in the cloud. A container dictates the access method, and a blob is the big ‘ole file that sits within the container.

Now to get content up to Azure. You could write a console app, use PowerShell, or a third-party tool. For this exercise, I opted for a third-party tool: . There are other tools too:

The files took me basically all day to upload. There were several reasons for this. For one, I have the most basic Broadband package Charter offers, but I’m not doing this for a living or every day so the time is no big deal. I’m charged by the GB not the minute, so if it took several days no biggie. But I’m not getting any younger…

Following this blog post, I did learn that the tools above do not upload in parallel, hence why it took so long.

“But David, you have a Skydrive and Dropbox account along with a hosting account. Why use Azure Storage?” Why not!? The real beauty of Azure storage is I only pay for what I use, and I pay pennies at that. Skydrive and Dropbox require a yearly commitment, and college classes only last 18 weeks. So when the class is over I can blow the container away and I don’t get charged anymore. I don’t plan on ever using these backups so they’re cheap insurance. Now having said that, Azure storage (and Amazon, and Google, etc.) aren’t really setup for consumer usage. But I’m not your typical consumer.

I’ll give PowerShell a shot next time and probably try Amazon as well to see if there are any performance differences. If I’m feeling really ambitious I may try doing a console app.

Price-wise, I’ve been charged a total of 15 US cents so far. I may have to go raid the couch cushions…

Dynamics CRM reactions

As the newly minted Dynamics CRM admin at Trek, I feel I’ve got just enough experience to be a danger to myself and others. Therefore, it’s time for a blog post.

We’re using the Microsoft hosted, Online version of CRM and it’s been interesting to find many Microsoft Partners have shied away from that choice. As opposed to SharePoint consultants pushing the Microsoft O365 kool-aid, it seems that many partners are pushing their own hosted versions over Microsoft’s. Very much a departure from what I’m used to.

What’s also interesting is that Microsoft CRM plays second fiddle to Salesforce.com right now. I haven’t done enough research to know who has the larger install base, but it’s definitely clear from a Marketing standpoint that Salesforce is where it’s at right now. In my native world, SharePoint is – hands-down – the king of Enterprise Content Mgmt systems, but with Microsoft CRM it feels like the product is playing catch-up.

Strategy-wise, 3 things have struck me about ensuring success for your CRM deployment:

  1. Know your processes – you have to know how your users are going to use this; “build it and they will come” does not work here
  2. Don’t make CRM a fancy front end to your ERP system – this blog post sums it up for me
  3. Social (just like in SharePoint) is king

Know your processes

I’ve read a lot of blog posts lately about failed CRM deployments that were supposed to “replace Outlook.” Replacing Outlook – while a noble pursuit – is a lackluster strategy if you don’t know how your people actually use Outlook to begin with when it comes to managing customers. It means you have to ask the hard questions and get your hands dirty with your users. Document as much as you can when it comes to process. That way expectations can be set and everyone understands how things should work.

CRM cannot be a fancy front end to ERP

The blog post I linked above did more for me than almost all the others combined. If you want to guarantee an almost certain death to your deployment, make it a front end to your ERP system. While surfacing data from your ERP system is not entirely bad, recreating ALL the data is bad. Why would I go to CRM to do some of the things I can do in my ERP system when I can just go to my ERP system and do everything.

Social is king

If you’re not collaborating in your CRM system, then you’re doing it wrong. Same can be said for SharePoint. Social is only going to get more and more important as time goes on and more people join social networks in their personal life. Obviously Microsoft sees value in Social since they dropped 2 Bil on Yammer, meaning that product is going to be ingrained in all other Microsoft products. Therefore, there are now 3 truths in life: Death, Taxes, & Social in the workplace. Get used to it.

Conclusion

So that’s what I’ve learned so far. I have more opinions on the subject of CRM, but they may/may not be right based on my experience thus far. I’ll post more as I get more “in-the-know.”