For Openomy, one of the things that makes our project really exciting day-in and day-out is that we went to a service based architecture early. We don't have one single application for everything and we don't have one single database for everything.
For instance, we have a user service (which controls accounts, sessions, etc and has its own database), a metadata service (which controls what files we know about, what tags they have, etc and has its own database), a file service (which controls the actual binary data of the files and has its own database), etc (we have a few others, but that gets the point across). They talk to each other through REST -- though it could be anything, of course -- to get anything done they might need.
This allows us to scale each service independently, which is great. I'm always surprised at how long it takes folks to move to a SOA.
But, perhaps, the coolest part from an always-hungry-to-try-new-things development team is that having a service based architecture means that we are free from programming language constraints. As long as the language can speak HTTP, we can try it out for a new service or a new client. There's nothing like the feeling you get when mastering a new language. And there's no better way to master a language than write something tens of thousands of people will be using.
So, we have an old front-end built in C#/Mono, we have a couple Rails services, a Java service, our new APIv2.0 (http://api.openomy.com) is written in Haskell/HAppS (which I'm particularly proud of), and now we're writing a client in Scala. And, besides that, we use Perl for some offline scripting tasks.
I think it's pretty unconventional-- but it shouldn't be! I highly recommend going this route.
For instance, we have a user service (which controls accounts, sessions, etc and has its own database), a metadata service (which controls what files we know about, what tags they have, etc and has its own database), a file service (which controls the actual binary data of the files and has its own database), etc (we have a few others, but that gets the point across). They talk to each other through REST -- though it could be anything, of course -- to get anything done they might need.
This allows us to scale each service independently, which is great. I'm always surprised at how long it takes folks to move to a SOA.
But, perhaps, the coolest part from an always-hungry-to-try-new-things development team is that having a service based architecture means that we are free from programming language constraints. As long as the language can speak HTTP, we can try it out for a new service or a new client. There's nothing like the feeling you get when mastering a new language. And there's no better way to master a language than write something tens of thousands of people will be using.
So, we have an old front-end built in C#/Mono, we have a couple Rails services, a Java service, our new APIv2.0 (http://api.openomy.com) is written in Haskell/HAppS (which I'm particularly proud of), and now we're writing a client in Scala. And, besides that, we use Perl for some offline scripting tasks.
I think it's pretty unconventional-- but it shouldn't be! I highly recommend going this route.