Of all the cloud providers out there, AppHarbor easily provides the smoothest deployment experience for .NET available today. I did this in one shot, including a few mistypes, and still deployed an ASP.NET MVC 3 Web Application to AppHarbor in 3 minutes and 50 seconds. (Be sure to hit the HD button in the top right corner to get the higher definition video)
Here’s the basic outline of what I intend to speak on at the upcoming presentation I have for the Bellingham, Washington .NET Users Group. If you happen to be in the area you should swing by and give it a listen (or heckle, whatever you feel like doing).
On April 5th I have a talk lined up with the Bellingham .NET Users Group. So far here’s a quick one over of the talk:
What Cloud Computing REALLY is to us techies
Geographically dispersed data centers.
Node based – AKA grid computing configurations that are…
Highly Virtualized – thus distributed.
Primarily compute and storage functionality.
Auto-scalable based on demand.
What kind of offerings exist out in the wild?
Amazon Web Services
Rackspace
Orcs Web
GoGrid
Joyent
Heroku
EngineYard
…many others and then the arrival in the last year”ish” of…
Windows Azure
AppHarbor
Developing for the cloud, what are the fundamentals in the .NET world?
Well, let’s talk about who has been doing the work so far, pushing ahead this technology.
Linux is the OS of choice… free, *nix, most widely used on the Internet by a large margin, and extremely capable…
Java
Ruby on Rails
Javascript & jQuery, budding into Node.js via Google’s V8 Engine
The Heroku + EngineYard + Git + AWESOMESAUCE capabilities of pushing… LIVE to vastly scalable and distributable cloud provisions!
So where does that leave us .NETters?
AWS .NET SDK released a few years ago.
Windows Azure & SDK released about a year ago.
These two have however been lacking compared to Heroku and EngineYard for those that want something FAST,
something transformative, easy to use, without extra APIs or odd tightly coupled SDKs.
Enter…
AppHarbor
In Summary the .NET Platform has primarily:
AWS for the top IaaS and most widely available zones & capabilities at the absolutely lowest prices,
Windows Azure for the general build to PaaS Solution, and for the people lucky enough to be going the Git +
MVC + real Agile route, AppHarbor is the peeminent solution.
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.
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
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
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
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!
Windows Azure AppFabric is arguably the main feature set that truly sets Windows Azure apart from any cloud services on the market today. The AppFabric allows cloud users to hookup on-premises services to their cloud services, to secure cloud & on-premises services with new or existing security frameworks (identity based, active directory, or otherwise), cache Internet or other content, and on top of all that build out and enable composite application integration.
At the same time that Windows Azure AppFabric is one of the main features that sets Windows Azure apart from the competition, it is often one of the most misunderstood or unknown parts of the entire offering. In this chapter I’ll cover the main parts of the AppFabric including the service bus, access control, caching, integration, and patterns for integrating composite applications.
Home of Windows Azure AppFabric
The first thing to do in order to begin building with the Windows Azure AppFabric is to download the SDK, check out the various Windows Azure AppFabric Sites and familiarize yourself with what it is and how it works into the Windows Azure Platform.
On the main site you will primarily find a marketing presence, but with links to many locations with useful architectural, development, and related technical information. On the left hand side of the site there is a navigation bar that provides access to specific information describing the service bus, access control, and other features of the Windows Azure AppFabric.
The next major web presence that is extremely useful for Windows Azure AppFabric is the Windows Azure AppFabric Team Blob. It is located at http://blogs.msdn.com/b/windowsazureappfabric/. This site is regularly updated with development tips, patterns and practices, related MVP and Microsoft Enangelist links, updates on the SDK, CTPs, and other technical information.
The last major link that should be reviewed and checked often in relation to Windows Azure AppFabric Development is the Windows Azure AppFabric Developers’ Center located at http://msdn.microsoft.com/en-us/windowsazure/appfabric.aspx. Next to the blog, which often links to this page, this site is probably the most useful in relation to AppFabric Development. There are headlines, quick starts, and other documentation related to AppFabric Development with Ruby, Java, and other languages and technology stacks.
I don’t want to provide a direct link to the SDK. The reason is that Microsoft’s method for tracking and providing download links to SDKs, CTPs, and other related software often changes. The best way to find the current download location for the Windows Azure AppFabric SDK is to use a search engine and enter the keywords “Windows Azure AppFabric SDK” (click the link as I setup the search for you). The first links provided will get you to the current location to download the SDK & other related files discussed below.
As of the current v1.0 release of the SDK there are several downloads that are matched along with it for documentation and samples. There is also a specific WindowsAzureAppFabricSDK-x64.msi and a WindowsAzureAppFabricSDK-x86.msi. Each of these are different and specific to the 32 or 64 bit architecture. Along with the SDK there is a v1.0 C# and Visual Basic file available for download that includes multiple examples of how Windows Azure AppFabric works. The last file that is included with the Windows Azure AppFabric download page is the WindowsAzureAppFabric.chm. This is simply a documentation file for the Windows Azure AppFabric SDK.
What Exactly is Windows Azure AppFabric?
Windows Azure AppFabric can be seen as the all encompassing fabric that interconnects on-premises solutions to Windows Azure solutions, and even Windows Azure solution to other solutions within the cloud. Windows Azure AppFabric is broken down into two main feature offerings simply called the service bus and access control. Some new features are coming online in the very near future; the main one I’ll discuss is the Windows Azure AppFabric Caching.
Windows Azure AppFabric
That’s all I have right now, and would love any feedback on things I should mention, discuss or otherwise add to this write up. I’m thinking of using it as an intro to AppFabric in some of the pending presentations I have coming up. So please throw in some feedback on what else you might like. -thanks
Click on Part 1 and Part 2 of this series to review the previous examples and code. First and foremost have the existing code base created in the other two examples opened and ready in Visual Studio 2010. Next, I’ll just start rolling ASAP.
In the JunkTrunk.Storage Project add the following class file and code to the project. This will get us going for anything else we needed to do for the application from the queue perspective.
[sourcecode language=”csharp”]
public class Queue : JunkTrunkBase
{
public static void Add(CloudQueueMessage msg)
{
Queue.AddMessage(msg);
}
public static List<CloudQueueMessage> GetAllMessages()
{
var count = Queue.RetrieveApproximateMessageCount();
return Queue.GetMessages(count).ToList();
}
public static void DeleteMessage(CloudQueueMessage msg)
{
Queue.DeleteMessage(msg);
}
}
[/sourcecode]
Once that is done open up the FileBlobManager.cs file in the Models directory of the JunkTrunk ASP.NET MVC Web Application. In the PutFile() Method add this line of code toward the very end of that method. The method, with the added line of code should look like this.
[sourcecode language=”csharp”]
public void PutFile(BlobModel blobModel)
{
var blobFileName = string.Format("{0}-{1}", DateTime.Now.ToString("yyyyMMdd"), blobModel.ResourceLocation);
var blobUri = Blob.PutBlob(blobModel.BlobFile, blobFileName);
Table.Add(
new BlobMeta
{
Date = DateTime.Now,
ResourceUri = blobUri,
RowKey = Guid.NewGuid().ToString()
});
Now that we have something adding to the queue, we want to process this queue message. Open up the JunkTrunk.WorkerRole and make sure you have the following references in the project. Windows Azure References
Next create a new class file called PhotoProcessing.cs. First add a method to the class titled ThumbnailCallback with the following code.
At this point everything needed to kick off photo processing using Windows Azure Storage Queue as the tracking mechanism is ready. I’ll be following up these blog entries with some additional entries regarding rafactoring and streamlining what we have going on. I might even go all out and add some more functionality or some such craziness! So hope that was helpful and keep reading. I’ll have more bits of rambling and other trouble coming down the blob pipeline soon! Cheers!
You must be logged in to post a comment.