This made me think about building your own services vs integrating others and I can't help to think rolling your own makes more and more sense.<p>I always come back to a paper some Netflix guys mentioned in a presentation I saw at a conference to make us appreciate how extremely hard integrating separate systems is : "Hundred Impossibility Proofs for Distributed Computing" (<a href="https://groups.csail.mit.edu/tds/papers/Lynch/podc89.pdf" rel="nofollow">https://groups.csail.mit.edu/tds/papers/Lynch/podc89.pdf</a>). The paper basically says there are at least a hundred walls that are mathematically proven to be insurmountable that you are going to potentially hit when trying to keep your data corruption free across systems.<p>This makes systems that keep data within the bounds of a non distributed, transactionally sound database like Postgresql comparably much more agile and powerful as you don't hit these hundred plus walls.<p>After some high profile failures of integration like Oracle/IBM's "Phoenix Pay" here in Canada, after people tried to counteract the problems with sophisticated and costly CQRS layers to manage the connections, they are now noticing what was mathematically proven in that paper, that you can't make a maintainable and reliable system when data is spread across too many different companies' servers. I think, at least for tech companies that know how to build stuff, that the trend is now to minimize holding data in a web of connected SAAS services, regrouping key data to their own transactional databases.<p>This trend has been helped by the fact that, it is now incredibly easy to build frontend and backend services tied to your own database. This "Tiny PWAs" article is a good example. This guy quickly built apps so that he didn't have to deal with ad laden ones in the app stores. As a testament to their simplicity, these apps ended up being only 1.7KB and 800B. This would have been impossible just a few years ago.