JeffJenkins

Yeah, if you can get away with that model things are simpler. The best first step into SOA to take is offloading work that doesn't need a user response to a pool of workers (often by publishing to a message bus, as mentioned elsewhere in the thread). I've implemented systems like that using Rabbit and Redis and it worked fairly well.

However, some kinds of requests are fundamentally about integrating the results of a bunch of different services into a response to send to the user. In that case you somehow need to gather the results of your rpcs/events in one place to integrate them. An example is Google search where the normal results, ads, and various specialized results/knowledge graph data need to be integrated to present to the user.

Another consideration is how much you want to be able to isolate services. If you have a user/auth service as in the article which completely encapsulates the database and other resources needed for data about users then you'll end up with a lot of calls into that service. It's a disadvantage because of all the reasons in my original comment, but it's great from the perspective of being able to isolate failures and build resilient systems

If you're considering switching your monolithic application into a SOA you should consider the testing and debugging implications seriously.

If your call graph goes more than one level deep then doing integration/functional testing becomes much more complicated. You have to bring up all of the services downstream in order to test functionality which crosses that boundary. You also have to worry a lot more about different versions of services talking to each other and how to test/manage that. The flip side is that the services will be much smaller, so leaf nodes in the call graph can reach a level of test coverage higher than a monolithic service.

Debugging and performance testing becomes more complicated because when something is wrong you now have to look at multiple services (upstream and downstream) in order to figure out where the cause of some bug or performance issue is. You also run into the versioning issue from above where you have a new class of bug caused by mismatched versions which either have tweaked interfaces or underlying assumptions that have changed in one but not the other (because the other hasn't been deployed and those assumptions are in shared code). The bright side for debugging and performance is that once you know which service is causing the issue it's way easier to find what inside the service is causing the issue. There's a lot less going on, so it's easier to reason about the state of servers.

It's important to remember that OrderedDict keeps insertion order, it isn't an implementation of a sorted dictionary.

I'm using MailTab Pro, which does notifications as well as presenting a mobile web view of the gmail website. I actually end up doing a lot of my email writing and processing directly from the web view because it's so much faster than the full Gmail site.

You're better off going to a hotel in terms of cleanliness, and they are located all over midtown. I've never been refused from a hotel when I searched for or asked where the restroom was

Generally multiple currencies aren't accepted and the volatility is much lower. You probably couldn't make a profit on normal consumer goods that have a return policy. For this to work you'd need potentially extreme currency changes over the course of a few weeks.

If merchants were doing sales and returns using Bitcoin it seems like you could make money on the volatility by returning items when the value of Bitcoins went up within the return window. You'd have to be willing to keep items you bought if the value of Bitcoin went down, but if you systematically made all your regular purchases that way you ought to come out ahead. Is this a real risk for merchants, or am I missing something?

Does this let you do anything on the host OS that you could do with a node.js library?

Fun fact: If you're taking one vowel and five consonants the Wheel of Fortune letters RSTLNE—not in that order—are the letters that are most likely to occur

Impressive. I think these sorts of articles are hard to come by because many (if not most) super productive programmers are doing their work for a company where the outside world won't find out about what they have done. Fabrice is notable because he's got a lot of high profile work.