Sentry 9.1 and Upcoming Changes

We recently tagged our final point release in the Sentry's 9.x series. Just like old versions of Sentry, this includes a huge swath of bug fixes, improvements, and new features. If you're on our cloud service, you've had access to these (and newer features) for quite a while due to the way we cycle features out. If you're updating from a previous version of self-hosted Sentry and interested in the major highlights, take a look at our changelog.

Most importantly, if you are one of the thousands of companies running open source, there are a few things you need to know about 9.1 that will affect you down the road.

From your stack to ours

A long time ago, we took the approach of trying to support as many different environments as we could. This strategy was made possible by building simplistic abstractions out of the actual APIs we consumed. For example, our nodestore service was a simple interface that only had to support get, set, and delete, which meant that you could adapt it to a SQL database, use Riak (as Sentry has done for many years in production), or use even your own custom key/value store.

As Sentry progressed, maintenance of these often rarely-used abstractions became a burden by hindering our ability to innovate on certain kinds of features and adding an enormous amount of complexity to shipping new versions of open source. So, we made the decision to move away from supporting multiple abstractions. In all future versions of Sentry, we will only support service providers we use ourselves. In some cases that will still provide choice (for example, local disk vs. S3 vs. GFS for file storage), but in general, we'll be limiting it to things we need.

The driving force behind this decision was search abstraction. For a long time, Sentry allowed you to run with very minimal infrastructure: any flavor of SQL database and Redis. That became increasingly complex over time, with certain abstractions having worse performance or simply not supporting behavior.

Going forward, in the next major release of Sentry — which we're still determining a timeline around — we will no longer support any database other than Postgres, and we'll be dropping support for any unused production service within Sentry's core codebase (for example, Cassandra as a key/value store). Ultimately, streamlining our support unblocks development and ensures we're hitting the quality bar you'd expect of us.

Building a better foundation

The biggest change we'll be making going forward is requiring our new search infrastructure, codenamed Snuba. Snuba — named after Facebook's Scuba — is powered by Clickhouse, which is a very fast distributed column-oriented database. With its speed and flexibility, Snuba allows us to build much more powerful search-like capabilities as well as rapidly prototype new ideas.

You likely aren't seeing any of this functionality if you're self-hosting Sentry as we've disabled all features which require the new (more complicated) infrastructure. However, if you're on our cloud service, you've already seen a lot of the power activated from this work with things like cross-project searches, additional search syntax, and our experimental Discover query builder.

In the next major version of Sentry, we're requiring Snuba, which unfortunately means we're also going to require Kafka, Zookeeper, and a number of other very large infrastructure changes. We know this will be painful for anyone self-hosting Sentry, and, while we hope to provide a reasonable migration path, it's always a good time to reflect on the value of self-hosted Sentry versus letting us operate it securely in the cloud for you.

Python 2's end of life

The last major pain point we're going through is moving on to Python 3. This has been particularly challenging for us due to the various libraries and frameworks we use within Sentry, specifically Django and South. Many of you are likely familiar with Django — a popular web framework for Python — and South is an older solution for handling database migrations. We're unfortunately still running on a fairly old version of Django due to the complexity that existed to switch off of South.

South has made it possible for us to easily (and semi-painlessly) offer accessible database migrations for all, but it doesn't support any versions of Django beyond ours. We've had to fork South and update it to support a newer version of Django, which will allow us to transition all of our SQL migrations over to Django's new native migration framework and upgrade to present-day versions of Django.

We're going to be off of Python 2 by the end of the year, but it's still unclear when we'll be able to ship the version of Sentry that makes the transition to Python 3. It will likely be the next major version, but our work on infrastructure services like Snuba aren't hindered by the Python or Django version requirements.

Data isolation in the cloud

Given the significance of the upcoming changes, we know that many of our customers will be evaluating the appropriateness of self-hosting for their business.

It's not uncommon that people start using Sentry by spinning up a small installation — often due to security and compliance being easier to manage — and then outgrowing that and moving on to our cloud service. Before today, that often meant deciding on where you want your tradeoffs between reliability, availability, performance, and compliance. While we're able to provide the best solution for most of those concerns, compliance was often the sticky point. We haven't been ignoring that concern, and today we offer a single tenant solution for those customers who would rather offload that business risk to us.

With Sentry's single tenant offering, we can deliver the same great value you get from our cloud service like continuous security, high availability, first-class support, and the latest and great features as soon as they become available. In addition, we're now able to give you the peace of mind your legal folks would love by guaranteeing data isolation.  Our Single Tenant offering is primarily aimed at enterprises as there's additional cost and complexity for us to run it, but if that's interesting to you, please get in touch.

Sentry 10 and beyond

There are still a lot of unsolved problems when it comes to shipping software in [literally every year], and we're going to keep making things better.

Later this year, our initial performance monitoring features will roll out, all of which are built on top of the new infrastructure and continue to remain completely open source. We've also been very actively developing support for analyzing crash dumps from even more runtimes (like Breakpad and iOS). Keep an eye on future updates in our GitHub repo and forum.

If you're interested in helping us change the way developers ship code and monitor applications, we have open positions in San Francisco, Vienna, and Toronto, and would love to talk to you!