 <p>This is a big subject indeed. When moving into microservices, you need to remember that a lot of your headaches are going to be operational (devops oriented) rather than "code". </p> <p>Also, there's so much out there that at some point you will just need to make a decision, regardless if it's optimal. Things will change along the way in any case. Make the best decision you can at the moment, go with it, and tweak later.</p> <p>Regarding your questions, REST is a common practice. There are also other options (WCF, Avro, whatever). Give yourself a timeline for a decision. If you know REST and feel comfortable with REST, take the decision. Try to see if you can build it so you can change / add other protocols later, but don't make it delay you too much.</p> <p>Like Udi said, some architecture considerations are if you need to call this service sync or async (via a message bus). Also, yes, think about service discovery. There are several options (zookeeper, consul).</p> <p>For some background and overview, try going through some of the resources:<br> <a href="http://blog.arkency.com/2014/07/microservices-72-resources/" rel="nofollow">http://blog.arkency.com/2014/07/microservices-72-resources/</a></p> <p>This also gives a quick overview of microservices patterns:<br> <a href="http://microservices.io/patterns/microservices.html" rel="nofollow">http://microservices.io/patterns/microservices.html</a></p> <p>But again, there's a lot of information and ways of doing things, don't get swamped. </p>