Octopus Deploy and RavenDB
Octopus Deploy uses RavenDB (Wikipedia) as it’s database. Many Windows applications typically fall onto the SQL Server platform for a database but Octopus Deploy went in a different direction. Paul Stovell, the author of Octopus Deploy, addresses why he chose RavenDB over SQL Server and other variants on the Octopus Deploy blog post: How Octopus uses RavenDB. Part of my article is rehashing what Paul Stovell mentions in his blog post. It’s an excellent post that really gives some perspective about why they chose RavenDB. I’ll give my own perspective on these benefits but let’s address the choice of RavenDB and how it may affect you.
Preface: As a developer, I’ve worked primarily on SQL Server 2000 on up to 2012. I’ve dabbed a bit in MySQL and PostgreSQL (it’s been quite a while for the latter two). While I’m confident with my skills regarding traditional SQL databases and queries, I’ve have yet to really dip my toes into the NoSQL pool. I am by no means an expert on RavenDB or similar architectures. That said, after reading a lot of information on RavenDB, I feel like I can support Octopus Deploy’s choice in RavenDB without diving too far into the technical details. From my perspective, RavenDB offers positive benefits over SQL Server (in no particular order):
When installing Octopus, the menus simply ask where to install the database (default is C:\Octopus\Database). That’s it. There’s no more details necessary beyond that. I view this as a major bonus as I shouldn’t have to configure an embedded database. Since it’s bundled in, the vendor should make whatever tweaks, configuration changes necessary. Not me. And did I mention installation is fast? Installing the Octopus server and database is a breeze.
Upgrades to the Octopus Server
Upgrades are pretty simple (2.0+). Migration paths from 1.6 to 2.0 are a little more complicated, but I have yet to venture down that road as I haven’t had the opportunity. But upgrades in the Octopus Server are simply a removal of the service itself. The database is left intact. Once the service replaced, the database connects to the upgraded service and all your projects, environments, tentacles, etc. are there. This isn’t anything special of course, but it’s worth mentioning as it’s recommended that you backup the database before any upgrades to the Octopus server executables. I think the bigger point is that this upgrade process is (relatively) seamless. As of today, I’ve done three updates (from 2.0 – 2.3) with no problems whatsoever.
I’ve read numerous articles on RavenDBs pros/cons and overall performance. If I had to summarize how RavenDB performs, I’d say RavenDB is a solid choice for web apps with mostly CRUD (Create, Retrieve, Update, Delete) type actions and that appears to be the majority opinion as well. There’s no real issues I’ve read concerning scaling either.
However, there’s one use case that RavenDB doesn’t perform well for. The most succinct statement in terms of cons comes from the author of RavenDB, Oren Eini (aka Ayende Rahien) from his blog post.
One case that we don’t recommend using RavenDB for is reporting, though. In many cases, reporting databases need to answer queries that would be awkward or slow on a RavenDB system. For reporting, we recommend just throwing that data into a reporting database (either star schema or a cube) and do the reporting directly from there.
This appears to be the consensus. Don’t do reporting on RavenDB. A good post from stackoverflow on RavenDB solidifies this. For you, as an Octopus user, there’s no reporting that I’m aware of within the Octopus Deploy application.
It’s not enough to have a database, but you need to back it up! In Octopus, backing up RavenDB is super simple and anyone should be able to use it. By default, it will automatically back itself up every 4 hours to the default directory supplied at installation (which you can change). You can view the database backup settings by clicking on the Configuration link in the upper right hand corner, and selecting the “Backup” tab on the left-side. They provide four easy configuration options:
1. Whether to automatically back up (or not).
2. Where to store the database backups
3. The interval of time between backups
4. The time to start backups
It doesn’t get much easier then that, does it? You can, of course, manually backup at anytime as well. You should manually backup your database just before doing an upgrade of Octopus (again, I’ll cover upgrades later). Keep in mind, restoring your database backups require the master key!
After installing the Octopus server, you’ll be notified to backup the master key. The master key can be found on the main Octopus Server Manager (displayed below). This master key is used to restore database backups. Do not lose this key!
In a nutshell, all the documents and indexes are encrypted out of the box upon installation. You can read more directly from the Octopus Deploy blog on encryption here: http://octopusdeploy.com/blog/encryption-in-2.0 and http://docs.octopusdeploy.com/display/OD/Security+and+encryption
Currently, the cost is “effectively” zero in comparison to a SQL Server license (depending on the edition of course). Granted RavenDB is bundled into the cost of Octopus so there’s no clear price tag. Either way, it’s one less license to purchase and (in my opinion) I’d rather have the deployment database segregated from anything else.
That said, not having the need for a SQL Server license or anyone to administer the database server is a huge plus for small teams and organizations. For medium and enterprise sized organizations, this might feel a little uncomfortable which is understandable. Larger organizations have much more invested (licenses, servers, personnel) in their database of choice so getting stuck with RavenDB may be off putting as it may seem like you won’t be able to access your data. Never fear, though Octopus (and RavenDB) have some methods for you to get, backup and lockup your data. You may be thinking that while all those points are nice, you’d still want access to the raw data. Ok, no problem. There’s two ways of doing that.
Method #1 – Use the RavenDB Studio
If you want to see what’s in RavenDB, you can view the it within a URL on your Octopus server. The Octopus documentation on the database also mentions this as well by using http://<yourservername>:10931/ you can view the current RavenDB.
1. Make sure the port is open on the firewall
2. You will need Silverlight installed to view the database
3. The site will require authentication and then you’ll be able to view the RavenDB
Below is the screenshot of RavenDB Studio from a browser
Method #2 – Use the Octopus API
Octopus has an Open API. You can view the documentation of this API on GitHub here: https://github.com/OctopusDeploy/OctopusDeploy-Api/wiki. Here’s another URL that demonstrates the Octopus .NET library client to access the Octopus server though the API. http://docs.octopusdeploy.com/display/OD/Octopus.Client I have not personally tried interacting with the API directly, but the documentation is there. If you want to really get information without going through RavenDB studio, you can use the provided API. Keep in mind, all components of Octopus (server, tentacles, octo.exe) use the API as well!
You can see that in spite of having RavenDB as a database, it really doesn’t impact you in any negative way. Most reservations about RavenDB are, if anything, a personal preference and not based on what positive aspects RavenDB offers. There are several ways to access your data as well as a simple, secure mechanism for backing up and restoring your data.
I applaud Paul for thinking forward and reevaluating SQL Server as the database of choice. It’s not an easy decision to abandon a popular platform, especially in the database arena. For me, the benefits of having a simple installation, fast performance, painless backups and easy data restoration has made for a great user experience!
I may follow up on RavenDB with a technical article and try it out for myself, but for now, I’m staying on the Octopus Deploy series. Next up, I’ll discuss the embedded webserver for Octopus Deploy, NancyFX!
Another great article Ian!
We’re adding one more setting to the backup page in the upcoming Octopus 2.4 release: # of backups to keep.
For licensing, we have RavenDB ISV licenses so there’s no royalty per customer – amortised across all of our customers it’s probably less than $1 per customer.
Thanks, Paul! For both the update to backups of the database AND the low, low, low, low, low cost of RavenDB to the customers! RavenDB FTW!
Is this document relevant still:
Yes, it’s totally relevant going forward. From versions 2.0 (I believe) to 2.6, Octopus is using RavenDB. After 2.6, 3.0+ will use SQL Server.
I googled “Octopus RavenDB” and this article came out 4th on the results page.
Nice one Ian.