Blog

Driven by Open Source

Seven years ago I would frequent an IRC channel setup for users of the Django web framework. Like an old-fashioned Stack Overflow, it was a mix of people asking questions and others answering. At some point, someone asked how to log exceptions to the database. While not understanding, it seemed not overly difficult and I helped come up with an example. Shortly afterwards I took that example, threw it into a repository, and committed the first lines of code to what would eventually become Sentry.

commit 3c2e87573d3bd16f61cf08fece0638cc47a4fc22
Author: David Cramer <dcramer@gmail.com>
Date:   Mon May 12 16:26:19 2008 +0000

    initial working code

 djangodblog/__init__.py | 35 +++++++++++++++++++++++++++++++++++
 djangodblog/models.py   | 36 ++++++++++++++++++++++++++++++++++++
 2 files changed, 71 insertions(+)

A few years later Chris Jennings (Sentry’s co-founder) joined Disqus. He then convinced me to come out to San Francisco and help build the fast growing community platform. Just a couple months after joining the team, around May of 2010, I saw Disqus was using the example code I had pushed to GitHub years before. To my surprise the very basic functionality that existed had proven to be extremely useful to them. It was then that we decided to double down on the idea and really make something out of the tool. This was the day Sentry was truly born.

Discovering Our Roots

During my tenure at Disqus, myself and many others grew to deeply value and contribute to open source. Coincidentally enough, GitHub also happened to be right upstairs from that first office, and we quickly found ourselves routinely at their drinkups. For us, open source became much more than the simple idea of free software, it became part of our lifestyle and began to encompass everything around us. We released hundreds of small Python and Django libraries during that time, in addition to driving continued improvement on Sentry and other products.

Today, Sentry remains just as committed to open source. Our world runs on open technology. From the tools that we run to monitor our servers (and applications), to the entire operating system underneath. Sentry couldn’t exist without open source, and it’s our belief that the way forward for this kind of technology is in that same spirit. We will remain just as committed, if not more, to improving Sentry, and doing it through open source.

The Opportunity

Through early iterations of Sentry we eventually built a standalone platform. This would allow anyone to report exceptions upstream via a standard API, in any language, on any platform. Quickly it led to an ever increasing amount of interest from our open source community. A lot of our colleagues within the Django world were early to adopt it, but what was even more surprising was the adoption in other ecosystems which we had no part in.

We saw SDKs being created in Ruby, PHP, JavaScript, and Java, as well as less popular languages like Erlang and R. It seemed like overnight that we went from a little Python and Django application to software that was integrated everywhere. From platforms that we didn’t know existed to even being run by many of our role models in silicon valley. Sentry adoption was growing massively.

Strength in Community

Sentry's Commit Graph

Fairly early on it became clear that the community wouldn’t contribute a lot to the Sentry server. It was large, complex, and required an understanding of a lot of things. This actually worked out well for us. It meant we were able to clearly drive the direction of the project without having the fumble around with too much contributed code. We took a strong focus on building extensible entry points into Sentry, and once again friends and colleagues stepped up. Soon the ecosystem expanded to include various integrations from issue trackers to notification systems.

During that time we also saw the realm of people running Sentry internally grow. Huge companies had chosen to adopt open source technology instead of inventing their own. It was amazing to see that small little project blossom and help thousands of engineers by making their job just a little bit easier. Most of it all, it was amazing to see people continue to run and expand open source.

Today those contributions still ring true. The Sentry team is primarily the company itself, and we actively improve on the server and continue to open up things for the ecosystem. The ecosystem itself continues to help us maintain our current SDKs as well as drive adoption of new ones. It feels like I discover something new that the community has come up with on a weekly basis.

In Good Company

Over the course of time a recurring theme had come up: people loved Sentry, but sometimes they’d simply rather not host the server themselves. While we didn’t know this yet, eventually we’d be convinced to build out the premium service, and what is now getsentry.com.

Before leaving Disqus, I spent the Christmas of 2012 engulfed in building the minimal set of features needed to support customer billing on top of Sentry. Two months in, on February 28th of 2013, we had our first paying customer. That customer was Matt Robenolt, whom has contributed heavily to many parts of Sentry and is now actively involved in the company. Over the next three years we built out the business (in our spare time) and we started seeing a real opportunity. What once was a a few dozen lines of code had turned into a valuable, sustainable business with thousands of paying customers. Most importantly of all, it was, and is still open source.

Credit Due

Today Sentry has become the standard. Thousands of customers trust us with their data on our hosted platform, with tens of thousands of developers using our open source software on-premise. None of this would have ever been possible without open source, and we want to pay special thanks to everyone who has written, contributed, or helped maintain the various Sentry projects throughout the years. At the end of the day, we’re able to continue building open source software primarily because our contributors, and our customers have put their trust in us.

With that said, we’re proud to be able to say that we’re looking to expand the team. If you love open source and want to help us build the future of application monitoring, we’d be thrilled to talk to you. Exciting things are coming, and we can’t wait to share it with you all.

From everyone at Sentry (myself, Chris, Armin, and Matt),
Thank you

Comments?

Single Sign-On via Google and New Pricing

Today we’re launching updated pricing for our Small, Medium, and Large tiers. As we’ve done in the past, you’ll be grandfathered into your existing plan. Grandfathered plans remain the same price with the same feature set (and limitations). One caveat to that is the restrictions limited and hobbyist plans (see below).

Updated Pricing and Quotas

The new plans are now member-restricted. This ensures we’re able to offer things like SSO to smaller teams, without having to seriously crank up prices. As always, our large plan brings the most freedom.

Prices and quotas for the new plans:

  • Small ($29/mo)
    10 members, 20 events per minute

  • Medium ($99/mo)
    25 members, 50 events per minute

  • Large ($249/mo)
    unlimited members, 200 events per minute

Integration with Google Apps

The biggest change with the new plans is that all of our company-focused tiers now include Single Sign-On for Google Apps. This means that switching to the new Small ($29), Medium ($99), or Large ($249) will give you full access to Google SSO. If you’re not using Google and you’re on our new Large plan, please let us know, as we have upcoming integrations for other providers and we’re happy to put you on the early preview list when they’re ready.

Changes to Limited and Hobbyist Plans

Today we begin enforcing the long-stated membership quotas on the limited and hobbyist tiers. These plans have always been our way of providing a cheap service for people who are building side projects. Unfortunately, many people have accidentally or purposely taken advantage of that in the past, both in terms of data and quotas. Additional members (beyond the first) on these accounts will be locked out until the account is upgraded.

As always, if you have any question or concerns, hit up support at getsentry.com

Better Team Managment in Sentry

Today we’re rolling out several improvements to the way teams are managed in Sentry. We feel these changes will help your organization become more autonomous, as well as provide ways for its members to reduce any unnecessary noise. Here’s a quick look at what’s new:

Joining and leaving teams

Before, teams were only visible if you were a member of the team or if you had global access. Today we’ve introduced an ‘All Teams’ tab that surfaces teams in your organization that you might want to be a part of.

There was also no way to leave a team once you were added. This was especially annoying for users with global access as they are automatically added as members of every team. Now team members can choose which teams they want to be a part of.

Open and closed membership for organizations

Organizations can now set whether they want team membership to be open or closed. With open membership, any member can join. With closed membership, a member must first request to join a team. Admins will see pending requests in the app as well as be notified via email.

Let us know what you think at hello@getsentry.com.

Continuous Deployment with Freight

Early on at Sentry we set up Jenkins to automatically deploy after a passing build. Eventually we wanted better control over where we were deploying, and when (i.e. branch FOO to staging). To solve this we started with simple parameterized builds, and effectively had something working. Unfortunately when it came down to adding external controls we hit the age-old API issues within Jenkins itself.

Enter Freight

When we started going heads down on Sentry this year, it was a goal to make sure our tooling was functional and accessible. While we don’t want to invest a lot of time into those things, we want to ensure our day-to-day workflows are smooth. We started off by looking at what tools exist, and found things like GitHub’s Heaven. Originally going down that path, we quickly (though reluctantly) decided we were better off writing our own, as we’re not rubyists, and some of the design decisions simply didn’t make sense for our security model.

Enter Freight. Freight is heavily inspired by GitHub’s Heaven project, but it has a few key distinctions:

  • It’s not coupled to GitHub
  • It can run entirely behind a firewall

Beyond that there’s a lot of things in common, but at the core they’re both just task runners.

Freight Deploy List

Freight Deploy Log

A Simple Core

Just like Heaven, Freight is entirely focused on executing deploys, primarily through simple commands.

A few key things are already done for you:

  • Multiple apps and environments.
  • Management of the source repository (unique per app).
  • Basic workspace management (repository is copied over, and deploy is executed from new location).
  • Abstractions for deploy provider, validation checks, and notifiers.

In our case, we simply plug in our existing Fabric deploy scripts (using the Shell provider):

{
    "command": "bin/fab -a -i {ssh_key} -R {environment} {task}:sha={sha}"
}

Freight automatically fills these in with the appropriate values at runtime.

We’ve also bundled in checks for GitHub Context (we use CircleCI), as well as notifications for Slack.

API Driven

Freight is an API-first project. It’s becoming what is the modern standard in reusable and accessible tooling. The choice allows us the ability to quickly whip up a React-based frontend, as well as integrations such as hubot-freight:

Freight Hubot Integration

We’ve also built out a very basic command line utility, freight-cli:

$ freight deploy --help
Usage: freight deploy [OPTIONS] APP

Options:
  --env TEXT
  --ref TEXT
  -f, --force
  --help       Show this message and exit.

$ freight deploy getsentry --env staging
Created new Task with ID = 404

$ freight tail 404
(waiting for output..)
>> Check has passed: github
>> Running ['git', 'fetch', '--all', '-p']
Fetching origin
Warning: Permanently added 'github.com,192.30.252.131' (RSA) to the list of known hosts.
>> Running ['git', 'clone', '/tmp/freight-repo-1', '/tmp/freight-workspace-70653104e33011e496e95a5015beb482']
Cloning into '/tmp/freight-workspace-70653104e33011e496e95a5015beb482'...
done.

An Early Preview

We’re huge believers in open source, and while Freight is fairly early, we’ve kept all of it’s development public. The source, as well as the intended goals are all available on GitHub. While today the setup requires you to have a little bit of knowledge around how Python packages work, it’s fairly quick to run on Heroku.

It’s our hope to continue the open source tradition that started Sentry wherever possible, and developer services are the lifeblood of a lot of what we do. Give it a try and let us know what you think.

Welcome Armin Ronacher

We’ve been building Sentry the product for a while now, but we’ve only recently begun building Sentry the business. With the overwhelming adoption of both our open source and paid products, it’s become clear that we no longer have a little side project — It’s time to up our game.

Enter Armin Ronacher. Many of you may know Armin through his wildly popular Flask and Jinja projects as well as his presence in the Python community. Armin is a long-time colleague and friend. When he and I would talk about the future, it was clear that given the opportunity we could build something special together.

That’s why it’s my pleasure to officially welcome Armin to Sentry. Armin is a machine and brings a breadth of experience to the team, especially in areas where we want to grow. This is the beginning of something great and I hope you’re as excited as we are.