In a monolithic app interfaces can be more fluid because you can have automated tests and static analysis and compile time checks verifying that a given change works. That means you can prototype and iterate faster while the business requirements may still be churning considerably. To realize the benefits of an SOA you need a much more stable interface and some way to handle validation and correctness of the wire protocol. If you do it right and come up with a stable interface, you gain the benefits of decoupling system administration, scalability, and even development to a great extent. But if you do it wrong you end up a lot more work for an equivalent business logic architecture, and if you don't have any scaling issues than the cost-benefit is likely not to be there.

My rule of thumb about whether an SOA is a good idea to pursue at a given point in time is much more related to the team size than the nature of the app.

(Disclosure: I'm owner of CloudAMQP - RabbitMQ as a Service, www.cloudamqp.com)

A new interface for each service, sure, but if your services only need to be deployed internally, some sort of authentication layer could be overkill.

Howsabout the one that was addressed in the blog post, namely that SOA is going to slow down your process?

Premature optimization indeed.