Instead I meant to use Kubernetes as an example of the work being done to standardize and abstract these sorts of microservice issues. Kubernetes solves a lot of orchestration issues and I expect there will be greater work with other projects into solving other problems like distributed transactions in the future.
The current thoughts on microservices is that you should really re-evaluate how critical strong transnational guarantees really are to your application.
Are there some examples of what else one can do?
I'm generally fine with service 2 eventually being called if service 1 is, but then I need that to happen.
e.g. I have a payment service and an internal "subscriptions service". If user requests a refund, I have to both issue refund to payment service and cancel internal subscription
Can you explain more how kubernetes help with distributed transactions? I was aware they are more of a management system for microservices, not something that handles db transactions.
I've found splitting a monolith into microservices very painful because it prevents you from easily having all-or-nothing db commit semantics. It's a lot easier to wrap your entire RPC/API endpoint in a single db transaction than it is to issue multiple commits (e.g. an RPC to a microservice that writes) and worry about the large number of states that can result if your endpoint crashes mid-way.