With SOA, I wouldn't really say this is necessarily Go or Ruby/Rails specific. It would be the same if you were just using Ruby or Go by themselves. What it comes down to is how your application is architected. You could do SOA with just Ruby or Go.
There are a lot of benefits to a Service Oriented Architecture.
- Clear separation of responsibility
- Different teams can work on different components
- Simplifed application archetecture code-wise
- Can lower development and management costs
- Configuration flexibility
- Targeted performance monitoring
- Simplified/gradual software updates
- Inherent service documentation (godoc generates from source)
- Targeted unit testing (does the service work?)
- Better scalability
You could probably add more benefits to that list.
The biggest obstacle to overcome is the initial planning, especially for the first time. How far do you break things down? What things should be separated? If you don't find the right balance, you can end up losing out on the benefits.
As far as how to design a SOA architecture, that really depends. If I were building a blog service with articles and comments you could have API methods like:
SubmitEntry
GetEntry
SearchEntries
GetComments
SubmitComment
The general idea is your service(s) does/do all the work. The font-end application is just a GUI. With MVC, your front-end could still have a model - it would just make API calls instead of database calls.
As far as what language to use, that really depends on you. Go is an amazing language. Its community is growing fast, but it's young. You may not be able to find a package you would otherwise have in Ruby. You may end up having to write your own. Having said that, Go has a lot of potential, and it is fun to write in!
Personal experience: The company I work for used to use PHP. A year ago we decided we needed to make a change, and we decided on Go. We have had to write a few libraries ourselves, but overall it has been an amazing year. We are now use Go exclusively (with a dash of C/C++).
