Yeah, that makes sense. It's not just joins, though. Consider the transactional nature of something like the signup process, where you want it to either succeed completely or fail completely.
If you're creating objects independently in multiple microservices during signup, and one of those fails, you've then got to deal with rolling back any changes that have already completed with other services.
Maybe traditional web applications just aren't a good use case for microservices?
Signup might not be a good case. Its a very occasional service with transactional issues, versus continuous high performance services (like authentication).
Right, but they also have their own internal Paxos service to manage distributed transactions, and they have thousands of engineers and thus can deal with the increased complexity.
As I said in my original comment:
> That seems like an awfully big hurdle to overcome for a new application, especially if you're a startup that needs to focus on delivering customer value as quickly as possible.
I'm really curious to hear if/how others are able to leverage the benefits of microservices yet avoid the perceived complexity that goes along with it.
Edit: I was reminded that Pat Helland (from Amazon) wrote a famous paper "Life Beyond Distributed Transactions" which gives some great guidelines on how to build an SOA that avoids reliance on distributed transactions: http://www-db.cs.wisc.edu/cidr/cidr2007/papers/cidr07p15.pdf
I still think this is clearly quite a bit more complex and harder to develop than i.e. a single Rails app, so I'm still very curious to hear when this approach starts making sense.
If you're creating objects independently in multiple microservices during signup, and one of those fails, you've then got to deal with rolling back any changes that have already completed with other services.
Maybe traditional web applications just aren't a good use case for microservices?