persei8

If I could recommend _just_one_ resource from that list, it would be http://www.tigerteam.dk/talks/IDDD-What-SOA-do-you-have-talk...

amazon.com is pretty traditional web application and they've been doing SOA for ages.

Service owns it's data. Other services can't access this data directly. Within service, on it's data, you can do as many "joins" as you want.

Request/Reply pattern makes a poor choice for communication between services - it increases coupling. It doesn't matter much if it comes with HTTP or any other flavour.

Again, Jeppe nails it in very detailed post: http://www.tigerteam.dk/2014/microservices-its-not-only-the-...

Transactions spanning several microservices violate their autonomy - one service should not lock resources of another.

Jeppe Cramon explains it pretty well in http://www.tigerteam.dk/2014/micro-services-its-not-only-the...

> If the entities in one service are not in strong relationship with one another, it's a sign you can split them in two services. But if two microservices talk to each other so extensively, that the service boundary is becoming a bottleneck, it's a sign that they should be one service.

In other words it's best to break down services by Bounded Contexts.

Is it true that you don't fully buffer body of POST request on router? This limitation works against Unicorn design and makes it hardly a "fix": http://rubyforge.org/pipermail/mongrel-unicorn/2013-April/00...

To me framework is a set of libraries, glued together with some infrastructure code. Framework provides some conventions that speed up most common tasks.

It may be possible to use framework as a library, though there is no or small benefit.