Initial thoughts on Octopus Deploy 3.0 – from RavenDB back to SQL Server

This is pretty big news for any Octopus Deploy users. Paul Stovell has hinted a return back to SQL Server over the past few months in blog posts and uservoice forum comments, but from the public view, it’s all speculation and rumor until otherwise official. This weekend, Octopus made it official –  version 3.0, they’re moving from RavenDB back to SQL Server.
This is a large paradigm shift within the Octopus Deploy universe. I can’t fault the Octopus team for moving back to SQL Server. In some ways, it seemed inevitable only because RavenDB knowledge within organizations was dwarfed or non-existent compared SQL Server DBAs and SMEs on hand. It’s an uncomfortable feeling that (typically) large companies have with RavenDB; they don’t have anyone on hand to support it. I’ve mentioned this before in a previous post.
While the Octopus blog post on this subject goes onto explain some serious technical issues they’ve had with RavenDB, I feel this move is largely not only a technical decision, but rather a move to placate the users as well as alleviate the burden for them in supporting RavenDB. Paul echoed this sentiment in his post by saying “since most customers don’t have in-house Raven experts, we’ve been the first (only) line of support when there are problems with Raven“. This is a move for organizations that are comfortable with SQL Server (which seems to be just about everyone) and with the necessary resources and assets to support it can use Octopus. While I haven’t had many issues with RavenDB, I realize others have so when it comes time to support a product in production without the necessary knowledge or SMEs to help during an emergency, there’s a frenzied dance of support emails and Skype sessions. This makes end users and organizations uneasy. The change to SQL Server makes sense if only to give end users what they want because they’re comfortable with it.
Regardless of my take on the switch, there may be some benefits that SQL Server can offer in spite of my preference for RavenDB. With RavenDB, installation is a breeze, it’s fast, secure and just works – what’s not to like? Well, one thing we’ve struggled with is creating a HA/DR solution for Octopus Deploy. There hasn’t been any official HA/DR configuration for Octopus up until October of this year when they added documentation on configuring Octopus to use an external RavenDB. We’ve been using Octopus for over seven months and we have no high availability or disaster recovery in place. This is nerve-racking. Database backups are nice but even every four hours leaves a lot to be desired for something that needs to be up 24/7. If SQL Server lets us leverage our in-house SQL Server resources and SMEs, it may trump embedded RavenDB in this specific scenario.
One thing that makes me slightly nervous about the switch is the API and just how dramatically it might change. We automate a lot on our Octopus server leveraging the API as much as we can. A whole new API might make the transition difficult, but well worth it if we can internal support and HA/DR. That said, I’m looking forward to 3.0 despite the fact I’m still trying to upgrade to 2.5.12 from 2.5.4. And now that 2.6 is on the horizon, December is shaping up to be a busy month.
Update: After a brief twitter conversation with @DamianM (Damian Maclennan) the CTO of Octopus Deploy, it looks like the API is going to be the same even with SQL Server.



2 Responses

  1. Just to be clear 🙂
    I said we shouldn’t change based on a SQL server backend. The way we’re building this (so far) means that semantically there shouldn’t be difference to the API. A release is still a release, a deployment is still a deployment etc.
    If we were to add new features / functionality to 3.0 there may be API changes, I’m not promising total stability. Just that we don’t *want* to introduce breaking changes, and today I don’t see any need to.
    (aka you’re not allowed to hate me if we were to change something….)
    Great post though, it is a big change. I like having something embedded and zero friction to install, but it’s far from zero friction to support. The SQL solution we’ve (Paul mainly) come up with looks to be not only faster, but should be much easier to support. We just need to nail the install experience.

    • Thanks for the clarification, Damian! It never occurred to me the ‘zero friction to support’ angle because, frankly, I wasn’t the one supporting it. 😉 In any case, I’m looking forward to 2.6 (first). One major release at a time for me. 😀

Leave a Reply

Your email address will not be published.

Post comment