[TeMPOraL]

There are trade-offs to everything, and a lot depends on a deal you have with your vendors. But if anything, it's the vendors that are the actual "torpedo in the hull" - a foreign body in your system, that you have very little control over and that can explode at any moment, leaving you with a vendor-shaped hole in your company. It's manageable when the third party is a commodity vendor - you can replace your printing house or blog host every other week at almost no noticeable difference. But in the world of software services, everyone is doing their damnest to not be a commodity, to make themselves unique. That uniqueness means a larger hole when they go down (or get acquihired), and also stronger ability to extract money from you. A codebase you own won't one day tell you that, starting next year, they're discontinuing the service package that was critical to your business, and now you have to buy two separate service packages plus a custom integration fee just to retain the functionality you grew dependent on.

[lmeyerov]

Right -- this is about commodity stuff. Agreed, asking a vendor to own your non-commodity bits means not owning your core speciality, which adds even higher levels of risks.

A nice thing about vendor-shaped holes in commodity areas is the holes are clear and plenty of vendors happy to quickly fill in. Comparing that to changing some internal project that gets its tendrils into who knows where with who knows what servers & services is night & day. I much rather figure out a Hubspot-to-Wordpress-and-Marketo migration or Zenefits-to-Gusto migration than some weird internal Elixir, Java, & InfluxDB Zeit blog spread over a bunch of AWS services that were primarily developed by two microservices devs who had both left the company to their next great thing over a year ago.