I’m looking for some resources on taking an existing monolithic Rails 3.0 application (35K LOC) and breaking it apart into an SOA design. Any books, blogs, screencasts, or example applications would be awesome.
The main questions I’m looking to answer are:
- Is SOA even the right design?
- Where do I start?
- What are some common pitfalls I can avoid?
- What should I be thinking about now vs what can I do later? (ie performance)
Some resources I’ve seen but not totally sure if they are the right places to start:
- Service Oriented Design with Rails
- RESTful Web Services
- Enterprise Rails (not sure if this book is still relevant)
- SOA Design Patterns (maybe too “enterprisey”?)
It depends. Don’t you hate these kinds of answers?
Breaking up your app to loosely coupled services using messaging or API calls would, by definition, be implementing SOA.
The beauty of it is that you can interchange service implementation without changing their interfaces and allow for independent deployments without having to bring down the whole app. Also, I’d implement the SOA via specialised API controllers that are versioned and expose custom state rather than their whole state which you’d reserve for authenticated users or role-based sessions.
The dilemma, from my experience, is whether to implement synchronous or asynchronous calls. Synchronous calls are obviously easier to program, but may leave your user hanging while they are being executed, and you’d have to handle timeouts for long-running queries. Watch out for database and web server timeouts.
If you implement asynchronous calls, let’s say via ActiveMessaging or alike, youd have to handle callbacks or some kind of notifications to bubble up to your user. It also entails setting up primary and secondary message brokers and maybe some JavaScript or pollers to check for status. It’s all fun though!
I’d first see if it’s “worth it”: after all, SOA is cool, but does introduce multiple points of failure that you do not have currently.
If you think your broken up app will result in discrete services that are HA and will serve other projects, I’d start with “the druby book” and “service oriented” as you mentioned.
I think the biggest concern would be transactions across multiple services and the ability to roll-back the whole operation if a distant service fails. The problems begins if you are in some operation where you call A and it calls B and B calls C and C fails.
Who knows that C failed? How will you tell B and A to roll back? Can they? Do they save state? Tough questions for upfront design.
One other issue is that life gets complicated when you throw a workflow on top of your SOA: who’s the keeper of the business process? Centralised or distributed? It’s all absolutely cool stuff again, but heaviness creeps in, no? But that’s life if you must move to SOA.
I’d factor out the obvious generic services that can be used in other apps right now. I would not over-SOA your environment to avoid adding points of failure and keep the ones SOA introduces to a minimum.