Octopus Deploy and NancyFX
It’s been a few weeks since the last article on RavenDB. So today, moving forward on the Octopus Deploy series, we’re going to talk about NancyFX. Octopus Deploy switched from IIS to NancyFX for it’s internal web host for their 2.0+ version. Why the switch from IIS? Paul gives his thoughts on the switch in his blog post titled Designing the Octopus Deploy 2.0 HTTP API.
To summarize Paul’s post, Octopus moved to an API-first model. This radical shift ultimately made using IIS a less optimal choice. Paul admittedly said the web portal needed to be rebuilt, but why specifically switch to NancyFX?
- It’s portable as it can run self-hosted within the Octopus Service
- Independent of client changes of IIS
- Less code in comparison to ASP.NET MVC and WebAPI
Ok, those seem like solid reasons. But what was the intent or goal? Paul lists his goals for the API directly on the Octopus Deploy wiki on the API:
- To be friendly and easy to figure out
- To be hypermedia driven, using links and the occasional URI template (read more)
- To have the HTML user interface for Octopus consume the API – this means that anything you can do via the application can also be done via the API
- To have a nice client library for .NET available via NuGet
All of these goals are admirable. I’d argue that the third point, regarding consumption of the API for all aspects of the application has by far the biggest impact. Having a central API for which all components directly use cuts down on the duplicated code which in turn makes the behaviors more predictable. So the same API call for the octo.exe works exactly as the UI; this benefits everyone from development time and consistent behavior.
So just what is NancyFX? I had heard of NancyFX but had no idea of it’s origins or it’s intended usage. Just like with RavenDB, I had to learn something new. And straight from NancyFX’s documentation:
Nancy is a lightweight, low-ceremony, framework for building HTTP based services on .Net and Mono. The goal of the framework is to stay out of the way as much as possible and provide a super-duper-happy-path to all interactions.
While it’s directly aimed at developers, it’s not clear what users get out of the framework. Then the documentation goes on to explain:
This means that everything in Nancy is setup to have sensible defaults and conventions, instead of making you jump through hoops and go through configuration hell just to get up and running. With Nancy you can go from zero to website in a matter of minutes. Literally.
For programmers and end users, this is clear win. Not having to deal with every configuration permutation and just deliver a product that doesn’t need all the baggage of other platforms such as IIS, makes perfect sense. NancyFX’s mission falls right in line with Paul’s goals (or maybe it’s the other way around). How exactly does NancyFX features over IIS translate as a benefit for end users?
We learned that NancyFX can be self hosted and that this allows Octopus Deploy to avoid any issues that may arise from using IIS should you chose use it on the Octopus Server. The Octopus Deploy team has complete control of whatever they need to do without interfering with IIS and vice versa. Gaining more control and not stepping on the toes of IIS (or any other product for that matter) is a huge win for everyone. Just as performance is a feature (thanks Jeff Atwood), so is avoiding configuration nightmares with other products.
Additionally, with NancyFX there’s less coding in comparison to ASP.NET MVC and WebAPI. That means less time is needed for programming features and/or bug fixes. When you look at the roadmap and see the aggressive timeline, you begin to realize that this decision’s impact is immediate. I will note that while NancyFX’s programming style is appealing to programmers, it’s a feature that doesn’t impact users directly.
Edit: It’s been brought to my attention by @philliphaydon that this post isn’t clear about NancyFX. After rereading this post, I should add some clarification. NancyFX is not a webserver. It’s really a host. This particular host model allows for a lot of flexibility as to where NancyFX can be implemented on other existing technologies. From the documentation: “Nancy is build to run anywhere and we mean it.” You can host NancyFX in ASP.NET, Azure, WCF, OWIN, Katana, self-hosting, etc. Check out the documentation on hosting for each scenarios here. My initial focus was on how NancyFX benefits Octopus, but I probably did some disservice to NancyFX as it’s an impressive framework in and of itself. I may dive deeper into NancyFX in another post.
I admit I’m prone to some fan boy-ism in this series, but I will confess that at first I didn’t understand a lot about the choices and the technologies at hand, namely RavenDB and NancyFX. On the face of it, I thought these were just “hip” decisions and that using the latest, coolest new thing in the community was the primary motivation. After doing some research, I see that the choices were deliberate and the reasons are justified.
No installation/configuration issues or errors with IIS? Sweet. Fast development time and less code? Cha-ching. Easy to use, hypermedia driven and an accessible API to all? Boom. Done. Sold. Where do I sign?
I appreciate the fact that Paul moved away from previous architecture decisions of using SQL Server and IIS to the more appropriate tools of today, RavenDB and NancyFX. It’s hard decision to make to move away from the familiar and lose some of the previous work that’s been done. It’s even tougher to go against the grain to what the rest of the industry always appear to use. It seems like the majority of software solutions still tread down the common IIS/SQL Server path just like everyone else before. But Octopus’s primary goal is anything but common and I think that for deployments, the impact of RavenDB and NancyFX can immediately be felt, but not seen.
Should anyone care about the architecture decision behind NancyFX for the Octopus platform? Maybe. Maybe not. But just think of this – as users of Octopus Deploy, we now get the added benefits of:
- A fast release/bug-fix cycle (yay for speed)
- No need for IIS (more control and stable)
- Unified API (used internally and accessible to users)
Switching back to IIS or SQL Server doesn’t benefit anyone at this point, which begs the question why use them to begin with. Thanks to Paul (and the team – sorry for not being inclusive!) for making some tough choices. I’d like to think that all these releases, bug-fixes and new features are a direct result of those architecture decisions and users are clearly benefiting from them. For those who haven’t tried out Octopus, it’s time to get on board. Next up in my Octopus Deploy series, we’re going to talk about Octopus and Nuget.