I've been hearing the Microservices buzz for a while. I recently tried to set up a new project as an ensemble of microservices but got stuck. There is a fair bit of "common" tooling like load balancers and events/log system. I'm about to throw in the towel since it seems too complicated to get going for a brand new project.
From my impression of the recent buzz about Microservices, and having spent the last year building them, Microservices shine as a refactoring approach for large/monolithic applications.
Notice his use of Kafka and 0mq to create an SOA for microservices. All of the stuff I had seen previously had the services communicate with each other via REST. So everything is synchronous. In the talk whose link I posted above, communication is asynchronous via messages. Is it reasonable to do both?
Also, how the heck does one deal with transactions across services?
Sure, it's possible/reasonable to do both. I work with asynchronous Microservices using RabbitMQ where PubSub shines in that many services can respond when the application publishes a message (1 service for email, 1 for push notifications, 1 for capturing data for analytics, etc). But it is fire and forget as far as the application is concerned.
Compare that to synchronous services where the application has be aware of all of them and coordinate calling them all. It is easier to use synchronous when the application requires an output from the service to respond.
Transactions across services are certainly not easy:
"Distributed transactions are notoriously difficult to implement and and as a consequence microservice architectures emphasize transactionless coordination between services, with explicit recognition that consistency may only be eventual consistency and problems are dealt with by compensating operations." [1]
