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.
— Ian Paullin (@ianpaullin) December 2, 2014