Today I had the pleasure of being able to speak with Michael Friis, one of the co-founders of AppHarbor. As you know from my previous post about AppHarbor, I am excited about this company and it certainly sounds promising. The founders of AppHarbor are all expert .NET developers who just got sick of seeing their colleagues leave the .NET community because there weren’t any simple, easy-to-use solutions like Heroku available. Rather than give up on .NET, they chose to stick it out and build something that filled the gap.
During this conversation I got to ask a couple of questions that I think developers want to know of cloud/PaaS providers before they sink their time and effort into building an application or deploying an existing one.
One of the biggest questions everyone asks of cloud service providers is about security. Friis appropriately commented that they have “double duty” when it comes to re-assuring their customers. They need to convince them that Amazon AWS (the foundational platform on which both AppHarbor and Heroku run) is secure. Once that’s done, they need to convince developers that their applications and application code are secure. While they have process isolation and standard file system protections in place on their multi-tenant servers, they don’t currently have any advanced protocols in place. Friis indicated that they are dedicated to ensuring that such security is provided and that their customers can feel safe deploying their apps, mentioning possibly doing things like automatically obfuscating Assemblies on behalf of their customers, etc.
The other problem a lot of developers have with cloud providers is vendor lock-in. As I said in my last post, nobody wants to be stuck with code that will only work in one particular company’s data center (e.g. Windows Azure). Friis addressed this by saying that they are dedicated to making sure that everything about their platform is as flexible as possible, even going so far as to say that even their dependency on Amazon isn’t hard-coded into the platform. In short, customers should feel comfortable building solutions that work on their desktops and on AppHarbor that will be able to work in other environments as well. Friis also mentioned that in the future, they might even consider deploying from AppHabor to Windows Azure for those customers deploying solutions that rely on Azure services.
Perhaps my favorite feature of AppHarbor (other than it being “Heroku for .NET”) is its integration into the developer’s daily workflow. Friis touched on this during the conversation, talking about how using proprietary deployment mechanisms like Windows Azure can easily get your application out of sync where the version associated with a particular source control/CI build isn’t necessarily the one currently in the cloud. With AppHarbor’s deployments being triggered from git pushes, you have that tight coupling with a particular source code revision and the version of the software sitting in the cloud. To me, this kind of feature really enables larger companies and enterprises to consider facilities like AppHarbor as viable deployment targets for their builds.
They have a lot of plans for the future, including growing their already impressive Add-Ons program and adding features like being able to dynamically scale application instances (the plumbing for this exists, but they don’t have it enabled for customers yet), geographic affinity of application instances, and much more.
As I’ve said before – time will tell if a company like AppHarbor can pull off what Heroku has, but they seem to be off to a fantastic start. For now at least, the next time someone asks me about a cloud back-end for their application I can send them to AppHarbor instead of telling them “quit .NET, learn Ruby, then use Heroku”. The next time I need to house a bit of code “in the cloud”, I’m going to give AppHarbor a try rather than using Heroku as my default playground.