5 ms·

The article is mostly about outsourcing "heavy lifting" like database hosting to cloud providers and non-critical software to SaaS providers. I agree with the a

The article is mostly about outsourcing "heavy lifting" like database hosting to cloud providers and non-critical software to SaaS providers. I agree with the article when it comes to database hosting/infrastructure but I would like to see more discussion about outsourcing to SaaS. Outsourcing to SaaS means trusting your (and your customers) data to lots of different companies. And in the case of SaaS those companies could be small software companies or even one-man operations. This is not very compatible with upcoming data privacy regulations like GDPR. And I suspect that more and more companies are going to be looking at a model where they purchase/license/outsource non-core software but host it themselves in their own datacenter or cloud accounts. The solution I am working towards in my current project is to build the software from day 1 with dual-mode operations in mind. Easy to host as SaaS but with the option of running Standalone on customer premises with the same codebase. Just different configuration/modules.

Cthulhu_ 9y ago
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.
- mooreds 9y ago
  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 http://www.mooreds.com/wordpress/archives/2872
rushabh 9y ago
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.
notyourday 9y ago
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.
- ape4 9y ago
  You're outsourcing sewage treatment when you run your own toilet. But, yah, I agree running a database on a computer is pretty easy.
- vbsteven 9y ago
  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.
  - always_good 9y ago
    Also, "just run your own X" starts to fall flat once you grow beyond having a single project in your life.
    - notyourday 9y ago
      s/single project/single successful money making project/g Oh to have those problems
  - notyourday 9y ago
    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".
tetha 9y ago
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.

Cthulhu_ 9y ago

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.

mooreds 9y ago
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 http://www.mooreds.com/wordpress/archives/2872

rushabh 9y ago

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.

notyourday 9y ago

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.

ape4 9y ago
You're outsourcing sewage treatment when you run your own toilet. But, yah, I agree running a database on a computer is pretty easy.
vbsteven 9y ago
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.
- always_good 9y ago
  Also, "just run your own X" starts to fall flat once you grow beyond having a single project in your life.
  - notyourday 9y ago
    s/single project/single successful money making project/g Oh to have those problems
- notyourday 9y ago
  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".

tetha 9y ago

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.