Like the ancient civilizations uncovered by anthropologists, the tools we use say something about who we are. Chris joyfully uses Ruby every day. He believes that flourishing is the key to happiness, servers are an anachronism, and the person that will create SkyNet has already been born. At New Relic he is a Happiness Engineer, where they let him work on things that makes someone’s day better. His stuff lives in San Francisco where he visits it from time to time. Chris tweets occasionally, speaks often, and drinks coffee in between.
The dreams of developers working on monolithic Rails applications are frequently filled with sugar plums and service-oriented architectures--but like any kind of software design, SOA can easily become a tangled mess. Many of the same principles that guide our software design can guide our architecture design.
We apply SOLID principles to applications to keep them loosely coupled, we design interfaces so we can send logical messages to our domain objects. We hide our databases behind abstractions because how we access our data shouldn't matter to how we consume it. Rarely, though, do we see the same practices applied to our services and APIs, leaving us with tightly coupled and difficult to extend service-oriented architectures.
If you are facing the monorail to SOA challenge, consider looking at your services as objects and your APIs as messages. Service-oriented applications are complex, and the best way to fend off complexity is though object-oriented design.