I find it hysterically funny that companies think that operating their own mysql, postgresql, redis or mongodb is "a difficult task". It is like a home owner deciding that knowing how to operate their own toilet is a difficult task that must be outsourced.

Oh and before someone says "we outsource fixing our toilets to plumbers" - in this case we are not event talking about replacing a flap, we are talking about being able to use a plunger.

Setting up a single postgresql is not that difficult indeed. But in a production scenario with decent uptime guarantees you are going to at least need master-slave replication, make sure they fail over when the master goes down, have backups so you can do point-in-time recovery, rotate and ship the logs somewhere, apply security patches, and more.

Sure, I can do all that by myself but that takes time, time that is better spent serving my clients instead of setting up yet another replicated db. It takes me a few minutes to setup an Amazon RDS instance with all that enabled out of the box.

Could you possibly provide the chapter and verse of this dogma? The harsh reality is that the vast majority of the companies *do not have traffic or need to have 99.9% available infrastructure because they:

a) do not have service that operates 24x7

b) do not have peopleware needed for 24x7 operations

c) service customers that do not have 24x7 operations

A metric boat load of now shuttered "startups" would have been going concerns providing very nice long term living (and retirement) to their owners had they been optimized for "not spending 109% of revenue for Yet Another Thing We Should Use As a Service".

Also, "just run your own X" starts to fall flat once you grow beyond having a single project in your life.

s/single project/single successful money making project/g

Oh to have those problems

Operating such services in a fairly static production environment is indeed simple, though in many cases I suspect it’s wasted effort that could be better spent elsewhere.

In our (Intercom) case these tasks are not simple.

We are lucky to have had exponential growth in most metrics (including database throughput) for the entire 7 years of our existence. This is a harsh environment for datastores! A 99.9% SLA makes it even harder.

We are also nowhere near finished building out our vision for the product. We prefer to focus on that instead of operating data stores, which we can pay someone else to do.

You're outsourcing sewage treatment when you run your own toilet. But, yah, I agree running a database on a computer is pretty easy.

A great opportunity to move to open source. It will help you not only have more control on your assets in case of privacy and GDPR, but also avoid vendor lock-in.

Mh, my current company does this, and it's a real pain and a massive innovation showstopper. It's nice as long as you have a single application and a single database. That's easy to do on premise.

Then you need search, so you either build the search yourself, or build on solr/elasticsearch or anything else building on lucene. Then you need a cache, and suddenly you need to worry about cluster setups, choose a cache implementation. Then you end up with a use case which would be easily solved with a persistent queue, or neo4j or whatever, but your on-premise solutions block you.

It sounds simple to have n different backend solutions, and to offer a binary choice - everything built-in and everything not-built in. But usually you end up with about n! * #on-premise different setups and they all end up with their own classes of bugs and difficulties to setup.

Well since this article is from Intercom, I can share that we outsourced our support / chat / things to Intercom, instead of (what was also proposed at the time) building our own.

A company for which I worked also leveraged intercom. I found it quite useful. Especially in the way it let non technical team members set up rules based customer interaction around onboarding and feature discovery.

See more of my thoughts here:

http://www.mooreds.com/wordpress/archives/2872