Yes. It’s called “understanding your constraints”.

The inverse is “appeal to higher power”; (implication being that its almost religion since it’s based on faith).

However: if you think that running large systems is hard, then it follows that it’s better to deploy small systems.

There can be times to outsource for sure, and I’m being relatively glib: but this idea of rent vs own is quite pervasive in the industry and it leads to dangerous situations where entire companies grind to a halt because these trade offs were talked down.

Regardless of that; understanding the trade offs is important, the famous “your nines are not my nines” is good to reference here: https://rachelbythebay.com/w/2019/07/15/giant/

Not sure about the name, but there are reasons to expect more reliability. You're only handling your traffic, not all the customers at once. You don't need to scale/distribute that far. And you can predict the traffic/storage needs better. In SaaS case someone does it for you, but it's a much bigger problem and they care less about you (as a single customer id 37826) than you do.

And you can either stick with the same version/featureset, or time upgrade outages to periods when you know your operations won’t be impacted.

> but thinking you're better at running software than a SaaS is hubris.

Disagreed on several points.

First off, if you're using something like Sentry, chances are that building and running software is your job so it should not be a problem. If self-hosting Sentry is a problem I would start doubting the skills of your tech team.

Second, running a service for your own use is very different to running a service that has to scale to the entire world. Your service won't need as many moving & distributed parts as the SaaS Sentry since it will only ever have to handle a fraction of the latter's traffic.

Finally, if you're in control, you can schedule risky maintenance operations during times where a potential accident (operator error, etc) won't affect your business. You can't do that with an SaaS.

> First off, if you're using something like Sentry, chances are that building and running software is your job so it should not be a problem. If self-hosting Sentry is a problem I would start doubting the skills of your tech team

Sentry is a pretty complex piece of software with a lot of moving parts. They have good orchestration around it, either Helm charts for Kube deployments or a giant bash script managing docker-compose for mono-machine, and it just works. However understanding either of them, and being capable of debugging aren't skills i expect your average developer to have. It's more for SRE/Infra/Platform/etc. folk. Like i don't expect the average developer to be capable of debugging Kubernetes on their own.

Of course, many of them absolutely can, but many more would prefer that to people who do that for a living. The type of developer using Heroku and other PaaSes precisely to avoid getting their hands too deep into infrastructure stuff.

  > If self-hosting Sentry is a problem I would start doubting the skills of your 
  > tech team.

I can't think of any team I've worked at in the past year for whom reading the self-hosted Sentry docs and standing up an instance would be impossible.

However, my experience is by and large at early-stage startups, and so I also can't think of any instance where I'd want to have my team working on that when they could be working on adding value to our product. If I can pay Sentry to handle setup, scaling, maintenance, etc (and I do!), then that's worth it when weighed against the dollar and opportunity cost of having my team handle it.

That's not to mention maintenance or other issues.

Just so we're clear: I completely agree with that stance. My grandparent comment is quipping that the option is rarely on the table.

We as an industry build our businesses on proprietary solutions that are difficult (nearing on impossible) or extremely expensive to self-host.

I love that there are options for SaaS; I strongly dislike being locked into SaaS -- and it feels like a lot of the companies I join are locked into some SaaS offering with no possible migration plan, despite dubious uptimes, awful support, rising prices and overall dissatisfaction with the product. (atlassian springs to mind immediately)

It's tech debt, of a certain type; and some tech debt is acceptable, especially in a startup.

Having an option such as Sentries to self-host is basically the best you're going to get... Gitlab is the same: Pay them to host, or host it yourself, the product is the same, the only "debt" incurred is the setup and migration, which is much lower than, say, Jira -> YouTrack.

It's not going to be more reliable probably, especially if you are trying to host a app with tens of services talking to each other. Scale/load might make a difference sometimes. I'm thinking github's recent issues here. But I wouldn't want to self-host github/gitlab, that would become a full time job probably :) If we decided github was not reliable enough, I'd just make sure we would not be dependend on it for normal work and maybe run my own git server and mirror it to GH.

I am however a proponent of self-hosting open source things you could get as a managed service. I.e databases, elastic search, redis etc. Provided you have the expertise to do that and benifit from it. For example, I used to run a redis setup that would failover in <5s on crashes and with basically 0 downtime for upgrades etc. Now we use ElastiCache and an upgrade will cause serveral minutes of downtime. I haven't had redis crash ever, but I have had elasticache & rds instances dissapear. Sometimes failover works, sometimes not and you have little to no wayt ot find out what is going on.