Cloud service provider Tier 3 has released Iron Foundry, a .NET-friendly fork of VMware’s Cloud Foundry platform-as-a-service. Iron Foundry gives the sizeable number of .NET developers an open source alternative to Windows Azure and lets them participate in the increasingly popular Cloud Foundry ecosystem.
Much of Cloud Foundry’s popularity comes from its broad support for a diverse range of platform technologies such as Java, Ruby on Rails and Node.js. However, up until this point, the millions of .NET developers have not been able to publish their web applications to a Cloud Foundry environment. Tier 3’s Iron Foundry, which has its source code available on GitHub, fills that void by contributing a series of components that give .NET developers the tools and framework they need to deploy applications to either a hosted Iron Foundry provider or locally within an enterprise. These components include the .NET fork of the Cloud Foundry code base, an updated Droplet Execution Agent (DEA) that can leverage Microsoft’s IIS web servers, and a Cloud Foundry Explorer tool that can be used by itself or as an add-in to Visual Studio. Developers using Iron Foundry can take advantage of some of the same application services that Cloud Foundry supports such as MongoDB, Redis and MySQL, as well as a new application service for Microsoft SQL Server.
Tier 3 is pledging to keep their .NET fork synchronized with the main Cloud Foundry branch and they plan to support developers through community forums and by hosting a free test environment. In order to learn more about this offering, InfoQ reached out to Tier 3 and interviewed their technical team.
InfoQ: What's your motivation behind Iron Foundry? What do you hope that it accomplishes in the .NET community?
Tier 3: There were two motivations that led to Iron Foundry: The first was that we believe in the Cloud Foundry project, but as a .NET based development shop, we really wanted to use .NET on Cloud Foundry. This is also really important to our customers as it easies their adoption of cloud services. As an enterprise-focused public cloud, at Tier 3 most of our customers are mid-tier to large enterprises whose mission critical applications are .NET based. To enable those customers, we contributed a core .NET Framework fork of Cloud Foundry, which Tier 3 is committing to keep it in synch with the main Cloud Foundry branch, and both a Windows version of Cloud Foundry Explorer as well as a Visual Studio Plugin for Cloud Foundry.
Our second motivation is a desire to contribute back to the community with a strong open source project that people will use. Our main hope is that this project enables .NET developers with choice in the PaaS solution they enable inside and outside of the firewall. We are committed to Iron Foundry for the long haul. Our engineers will actively engage in the IronFoundry.org community forums to provide substantial support to the Iron Foundry community as it grows. And to accelerate adoption, Tier 3 is donating a full test bed environment via a “try it now” feature on IronFoundry.org consisting of one web and one database instances per developer for 90 days
InfoQ: Where do you see the core differences (development/deployment/management) between an ASP.NET web application deployed on Iron Foundry and an ASP.NET web application deployed on Windows Azure?
Tier 3: While these are both great PaaS platforms and there is room in the marketplace for both, for us again it comes down to choice and interoperability.
For developers, beyond the obvious ones such as choice in where to run it, there are several benefits that come with a Cloud Foundry-based PaaS. Azure forces a full .NET compliancy and this constant contention to code means the tools are proprietary to the platform itself. But in Cloud Foundry there is less coupling to tooling Iron as only the framework is customized. Iron Foundry is Cloud Foundry plus .NET, so devs have access to standard tools. For example, a developer could write .NETcode against a MySQL backend or just write again a simple name-value pair datastore like Redis .
We also like that with Cloud Foundry the inherent interoperability enables access to other types of services not offered on Azure such as NoSQL and other services since it is fully extensible. And of course, since its open source, and the community is backed by major players, we expect to see the ecosystem really take off around it. In addition to this, the developer can run their own version of the PaaS, there is only a hosted option with Azure which costs $$. This means that the developer can have a test, QA and staging PaaS before going external to a production PaaS.
For operations teams, the fundamental difference is that, since Cloud Foundry is open source, they can chose to run it on any service provider that supports it or, by enabling a custom service as a private PaaS, run it on their own cloud. Again, this gives operations teams the most freedom of choice among compute platforms and ensures they have access to one that suits their specific needs – for enterprise for example, in areas such as security, compliance, availability, location, etc.
One of Cloud Foundry's biggest advantages is to be able to add instances to an application -- this is an advantage that Iron Foundry inherits. In Cloud Foundry, you just add an instance on the fly and the app is pushed to the new node. Like Azure, Iron Foundry uses the same easy to "Click to Deploy" methodology within the IDE. Both systems do it really well. The only known gotcha as far as I know is that Azure you have to redeploy the app when you make changes to instance numbers and instance sizes since all the is defined in Service Definition.csdef.
InfoQ: You've added a SQL Server service to Iron Foundry to go along with "traditional" Cloud Foundry services like Redis and MongoDB. Did you see this as a critical step to bringing Microsoft-oriented developers on board?
Tier 3: In the .NET ecosystem, NET and SQL go together like bread and butter. We felt that Iron Foundry could not happen without having SQL server support. I believe as Cloud Foundry grows, its Database as a Service offering will have to support SQL server in order to support .NET.
InfoQ: What was one of the biggest challenges in getting .NET applications to work in a Cloud Foundry environment?
Tier 3: The first challenge of getting a.NET application to work in Cloud Foundry environment was enabling Windows Server and making sure that all the operations were ported over from a Linux environment. The second, and probably the biggest, was the tool set as .NET developers had limited resources for deploying and configuring Cloud Foundry. We solved that by adding a Windows version of Cloud Foundry Explorer and a Visual Studio add in for Cloud Foundry.
InfoQ: Are there any architectural changes from Cloud Foundry in Iron Foundry or were you able to simply extend the existing architecture and "plug in" the Windows-based application containers?
Tier 3: While there were some minor changes, the beauty of Cloud Foundry is that it is a very extensible system that allows for other services and applications to be added with little to no issues. The biggest challenge again was enabling the interaction of Windows and IIS as stated above.
Iron Foundry forked the Cloud Foundry code and made addition to the cloud controller and NATS so that a .NET web app can be recognized. We have built a Ruby on Windows version of the DEA so that we can orchestrate on IIS. We will be subsequently replacing the Ruby+Windows with a C# port. Given that it is a fork, one can run up a Ruby on Rails app without any issues as we are officially supporting .NET. We ported VMC to a .NET version which is in beta as we have all the "important" items ported but not 100% coverage.