Lately, I have been working on a Rails + Sinatra project, based on microservice architecture. This architecture was chosen from scratch for the project—and I think this is where things started getting painful. I am not really against microservices architecture, but I do find it very overwhelming and cumbersome.
I felt we could have built an MVP in a single Rails app first, and then added more features to it as components or modules. Components can have their own controllers, views models, etc, and can even talk to their own database. I was watching a video on component-based architectures in Ruby and Rails by Stephan Hagemann (http://youtu.be/-54SDanDC00), and it seemed simpler to start your application as a component collection and then slowly move to service-oriented architecture (SOA). Your services can be component-based too, but this time your components would be small.
You can design one service which is a suite of small services, and you would see as you scale your application higher and higher that it becomes a suite of small services—and you have your microservices architecture in place.
My take on microservices architecture is don’t start out with it—it can negate all the benefits which Rails offers of speedy development and quick prototyping. Also, such architecture requires good developers, and everyone may not be comfortable doing things this way. As an analogy, you can think of how many people know how to speak and write in a particular language—like English—but not everyone is comfortable writing poetry in it.
So, how would I approach my next application? I would probably design different components according to business needs and create a well organized monolith first; and then separate different components into services, if need be; and then small services out of a big service, if there was any need to do so.
If you are a PHP or Java developer, then you might want to figure out how you can design your application on component-based architecture and then slowly take it from there.