In-process libraries that are orthogonal to your domain aren't a golden ticket. SOA lets you scale the parts that need to, one service at a time, be that caching, search, storage or domain logic.
I disagree that in-process libraries are actually less complex architecture, it just hides the complexity within a single process.
In-process libraries that are orthogonal to your domain aren't a golden ticket. SOA lets you scale the parts that need to, one service at a time, be that caching, search, storage or domain logic.
SOA is also considerably more complex to architect, configure, and administer. If you don't need it yet, why pay for it?
I disagree that in-process libraries are actually less complex architecture, it just hides the complexity within a single process.
I'm not sure what you mean by "hide". Using these tools you can scale up a much larger order of magnitude before having to worry about breaking out services.
We're talking about the difference between 1-2 servers and 10-20, and that's a fairly substantial difference in man hours, architectural complexity, physical plant, etc, especially early on in a startup.
Chances are good you'll never even need to grow to that scale, either -- we ran a game site with 4 million in yearly revenue (and quite a bit more than 10 million requests/day) on about 8 mid-range servers.
With commonly used processes (like memcached and sphinx search) and normal client libraries, I have not found a substantial increase in time to architect and configure. You are right about time to administer, but in my experience that is front-loaded, and the added ease of troubleshooting problems readily offsets it.
By hide, I mean you still have services that your domain logic is consuming, but they appear to be part of your business application in a mono-process architecture instead of being "exposed" in SOA.
If adding servers is painless and automated, then I disagree that there is a substantial difference between 2 and 10. If you want to have fast recovery, reproducibility and transparency, a cluster of 2 servers takes almost as much effort as a cluster of 10.
Tuning applications doesn't add nearly as much to the bottom line as feature development does, especially early on in the start-up. Twitter is an obvious example of not performance tuning fast enough, but 1000x times that are examples of scalable websites we'll never hear of[1].
The conventions and convenience of "mainstream" rails architectures make this SOA approach nearly painless.
However, I do agree that rails is obnoxiously slow. To me, this is a huge problem in your average response time more than total throughput of the architecture. Further, I think we agree that scaling is not a problem, until it is a problem.
One thing you may not be aware of is that in the ruby world, sphinx and memcached are actually easier to use than their in-process equivalents. Further, the tendency in the rails world to go with MySQL rules out all the awesomeness of Postgres.
Comments
In-process libraries that are orthogonal to your domain aren't a golden ticket. SOA lets you scale the parts that need to, one service at a time, be that caching, search, storage or domain logic.
I disagree that in-process libraries are actually less complex architecture, it just hides the complexity within a single process.
In-process libraries that are orthogonal to your domain aren't a golden ticket. SOA lets you scale the parts that need to, one service at a time, be that caching, search, storage or domain logic.
SOA is also considerably more complex to architect, configure, and administer. If you don't need it yet, why pay for it?
I disagree that in-process libraries are actually less complex architecture, it just hides the complexity within a single process.
I'm not sure what you mean by "hide". Using these tools you can scale up a much larger order of magnitude before having to worry about breaking out services.
We're talking about the difference between 1-2 servers and 10-20, and that's a fairly substantial difference in man hours, architectural complexity, physical plant, etc, especially early on in a startup.
Chances are good you'll never even need to grow to that scale, either -- we ran a game site with 4 million in yearly revenue (and quite a bit more than 10 million requests/day) on about 8 mid-range servers.
Thanks for sharing your experiences.
With commonly used processes (like memcached and sphinx search) and normal client libraries, I have not found a substantial increase in time to architect and configure. You are right about time to administer, but in my experience that is front-loaded, and the added ease of troubleshooting problems readily offsets it.
By hide, I mean you still have services that your domain logic is consuming, but they appear to be part of your business application in a mono-process architecture instead of being "exposed" in SOA.
If adding servers is painless and automated, then I disagree that there is a substantial difference between 2 and 10. If you want to have fast recovery, reproducibility and transparency, a cluster of 2 servers takes almost as much effort as a cluster of 10.
Tuning applications doesn't add nearly as much to the bottom line as feature development does, especially early on in the start-up. Twitter is an obvious example of not performance tuning fast enough, but 1000x times that are examples of scalable websites we'll never hear of[1].
The conventions and convenience of "mainstream" rails architectures make this SOA approach nearly painless.
However, I do agree that rails is obnoxiously slow. To me, this is a huge problem in your average response time more than total throughput of the architecture. Further, I think we agree that scaling is not a problem, until it is a problem.
One thing you may not be aware of is that in the ruby world, sphinx and memcached are actually easier to use than their in-process equivalents. Further, the tendency in the rails world to go with MySQL rules out all the awesomeness of Postgres.