Git Rid of Windows Azure and Amazon Web Services (AWS) SDKs with .NET + Git + AppHarbor Deployment Revolution

I’ve been wanting to do a quick write up on the state of cloud apps from my perspective.  What’s my perspective?  Well I’m keeping up with  the SDKs from the big players; AWS and Windows Azure.  I’m also working on several cloud applications and providing consulting for some people and companies when approached related to which stack to go with, how to apply their current stacks (such as Ruby on Rails or .NET) in migrating to a cloud service provider.  Cloud services, or really more accurately utility computing has my personal and professional interest.  Above all, I keep trying to stay informed and know what the best path is for anyone that seeks my advice for moving into hosting & working in the SaaS, PaaS, or IaaS Space.  Feel free to contact me in regards to cloud questions:  adronhall at the famous gmail dot com.  🙂

Now on to the good tidbits that have been released lately.

The latest Microsoft goodies area available.  For the Windows Azure SDK go check out the Microsoft MSDN Site.

For the latest awesome from AWS (Amazon Web Services) SDK check out the AWS .NET Site.

These two SDKs are great for customers who want to build on the bare bones X platform.  Now whatever language & stack one builds in they are tied to that.  Ruby on Rails, .NET, Java, PHP, or whatever.  But getting tied to the stack is kind of like breathing air, one has to live with what air they have.  You can’t exactly get a refund very easily on that.

The Cloud SDKs though for Azure & AWS provide a certain amount of lock in, in addition to the stack lock in you’re using.  One of the easiest ways to prevent this lock in is to use a general deployment method backed by source control on something like Git or Mercurial.  So far though, .NET has been left out the cold.  There has been almost zero support for pushing .NET via Git or Mercurial into a cloud.

Heroku
Heroku

Ruby on Rails however has had support for this since…  well since the idea popped into the minds of the people at Heroku, EngineYard, and the other companies that are pushing this absolutely amazing and powerful technology pairing.

Engine Yard
Engine Yard

Again, for .NET, the problem is it has been left in the dust.  Smoked.  It has left a lot of .NET Developers moving to Ruby on Rails (which isn’t new, this is just one more thing that has pulled more developers away from the .NET stack).

 

Well, that’s changed a bit.  FINALLY someone has gotten the Git + .NET Pairing in the Cloud put together!  FINALLY you can get a cloud application running in a minute or two, instead of the absolutely inane amount of time it takes on Windows Azure (15+ minutes most of the time).  So who has done something about this?

AppHarbor is the first fully deployable solution for the cloud that allows Git + .NET to get going FAST!  I don’t work for these guys at all, so don’t think I’m shilling for them.  I’m just THAT happy that .NET has been pulled out of the dust bins and the community has this option.  I am flippin’ stoked matter of fact.

Currently, because of pricing and ease of deployment, I’ve been solely using AWS.  I can have a .NET MVC app running in AWS in about 5-10 minutes.  Between that speed of setup and the pricing, I pay 2/3 as much as Azure would be and can deploy much fast with a completely traditional .NET deployment.  No special project type needed, no extra configs, just a straight deployment with full control over the server (i.e. I can RDP in with no problem).  Anyway, the list of reasons I went with AWS over Azure really deserve an entire blog entry unto themselves.

AppHarbor
AppHarbor

With AppHarbor though I can step into the realm of doing exactly the same thing a Ruby on Rails Developer would do with Heroku or EngineYard.  Fully PaaS Capable with the scalability and features without needing to port or migrate to an entirely new stack!  I’ll probably keep a number of things running on AWS (such as the pending WordPress Websites I am about to push up to AWS), but will absolutely be starting up some applications to run in AppHarbor.

If you’re a .NET Developer and you’ve been wanting, looking for, and frustrated that the .NET Community didn’t have a Git + Cloud Deployment option for .NET, wait no longer.  Give AppHarbor a look ASAP!

Anyway… off to do a little work on my infrastructure project.  Cheers!

Windows Azure SDK Unit Testing Dilemma — F5DD Plz K Thx Bye

I’m a huge advocate for high quality code. I will admit I don’t always get to write, or am always able to write high quality code. But day in and out I make my best effort at figuring out the best way to write solid, high quality, easy to maintain, easy to read code.

Over the last year or so I’ve been working with Windows Azure (Amazon Web Services and other Cloud/Utility Platforms & Infrastructure also). One of the largest gaps that I’ve experienced when working with Windows Azure is the gross disregard for unit testing and especially unit testing in a Test Driven Development style way. The design of the SDK doesn’t make unit testing a high priority, and instead focuses mostly on what one might call F5 & Run Development.

I’ll be the first to stand up and point out why F5 Driven Development (for more on this, check out Jeff Schumacher‘s Blog Entry) is the slowest & distracting ways to build high quality code. I’d also be one to admit that F5 Development encourages poor design and development. A developer has to juggle far too many things to waste time hitting F5 every few seconds to assure that the build is running and code changes, additions, or deletions have been made correctly. If a developer disregards running the application when forced to do F5 Development the tendancy is to produce a lot of code, most likely not refactored or tested, during each run of the application. The list of reasons to not develop this way can get long pretty quick. A developer needs to be able to write a test, implement the code, and run the test without a framework launching the development fabric, or worse being forced to not write a test and running code that launches a whole development fabric framework.

Now don’t get me wrong, the development fabric is freaking AWESOME!! It is one of the things that really sets Windows Azure apart from other platforms and infrastructure models that one can develop to. But the level of work and effort makes effectively, cleanly, and intelligently unit testing code against Windows Azure with the development fabric almost impossible.

But with that context, I’m on a search to find some effective ways, with the current SDK limitations and frustrations, to write unit tests and encourage test driven design (TDD) or behaviour driven design (BDD) against Windows Azure, preferably using the SDK.

So far I’ve found the following methods of doing TDD against Windows Azure.

  • Don’t use the SDK. The easiest way to go TDD or BDD against Windows Azure and not being tightly bound to the SDK & Development Fabric is to ignore the SDK altogether and use regular service calls against the Windows Azure service end points. The problem with this however, is that it basically requires one rewrite all the things that the SDK wraps (albeit with better design principles). This is very time consuming but truly gives one absolute control over what they’re writing and also releases one from the issues/nuances that the Windows Azure SDK (1.3 comes to mind) has had.
  • Abstract, abstract, and abstract with a lock of stubbing, mocking, more stubbing, and some more abstractions underneath all of that to make sure the development fabric doesn’t kick off every time the tests are run.  I don’t want to abstract something just to fake, stub, or mock it.  The level of indirection needed gets a bit absurd because of the design issues with the SDK.  The big problem with this design process to move forward with TDD and BDD is that it requires the SDK to basically be rewritten as a whole virtual stubbed, faked, and mocked layer. Reminds me of many of the reasons the Entity Framework is so difficult to work with for testing (has the EF been cleaned up, opened up, and those nasty sealed classes removed yet??)

Now I’ll admit, sometimes I miss the obvious things and maybe there is a magic “build tests real easy right here” button for Windows Azure, but I haven’t found it.  I’d love to hear what else people are doing to enable good design principles around Windows Azure’s SDK. Any thoughts, ideas, or things I ought to try would be absolutely great – I’d love to read them. Please do comment!

My Current Windows Development Machine Software Stack

I recently did a clean install of Windows 7 64-bit.  It had been a really long time since I listed the current tools, SDKs, and frameworks that I’ve been using.  Thus here’s my entourage of software that I use on a regular basis that is installed on my primary development machines.

Basic Software & System OS

Administration Utilities

Themes & Such

In addition to these packages of software another as important, if not more important to my day-to-day software development includes these software services and cloud hosting services.

SaaS, PaaS, and IaaS

Software I will be adding to the stack within the next few days, weeks, and months.

Project Review, What Would You Want To Know?

I’ve worked more than a few projects in my career. One thing that I always find sorely missing throughout many Enterprises is a follow up report of what went well and what went wrong on a project. In other words a list of successes and a list of things to improve. With that in mind I’ve put together the following survey questionnaire for the end of a project. What other items might you add that you’d want to know?

  1. Is the overall project considered a success?
  2. What caused roadblocks or stoppages during the project?
  3. What caused excess work that was unnecessary?
  4. What processes could be avoided, added, or otherwise changed to streamline the day to day development and operations?
  5. What could management do to have made the project even easier to accomplish successfully?
  6. What could inidividual developers do to have made the project even easier to accomplish successfully?
  7. Were the tools needed to complete the project made easily available?
  8. Were access, work environment, and other physical assets provided in a timely manner to complete the project?

Please leave a comment or three about what you’d want to find out once a project is complete.

It Brought a Tear to My Eye, Agile Ideals Rock!

I’ve been leading a software development project for a little over a month, one of my team members and I have been communicating back and forth steadily.  Via IM or verbally, e-mail or however we need to.  We’re having a good time figuring out things as they come and getting things done in a very Agile way.  To lay it out as the manifesto is written;

We keep ourselves and interactions over process and tools.  We make sure to have working software on almost every single build that could literally be deployed, while forgoing the currently unnecessary documentation.  We collaborate constantly with the customer representative and don’t worry every minute about the contract negotiation.  Response to change is almost instant, as it comes along almost every day.

As we’re hustling along getting a complete vertical implementation of a project together this coworker comes to me and states, “It is great to work on a project with someone that knows what they’re doing, and not sent off in a corner to read documentation books on what was done in the past!”  That statement made me so happy.  This is one of the major reasons I advocate Agile!

Agile helps team members get bought into the project.  The team gets involved in ways that other processes just don’t allow.  The team feels enabled, empowered, or whatever one may call it to actually get the job done!  Being Agile isn’t about process or tasks or work items, being Agile is a mindset, is about being interested and involved in what you’re doing for your project.

After a dirge of conversations and some frustrating efforts recently, this is the type of thing that leaves those negatives in the dust.  This is the type of statement and motivation, when I see it, that makes me love what I do and love to come into the office each day!

So anyway, I had to make this post.  Because today, even though I thought it would be a slightly miserable day.  That one statement redeemed it and my day is now rocking!