The best advice I can think of is to build one. There really aren't any general rules. Everyone's needs (and languages/platforms/tools) and experiences are going to be different, which is great to learn from, but isn't going to present you with prescriptive advice.
However, since microservices are, by definition, small, building something basic is not complex or time-consuming. I'd suggest tackling something fundamental, such as user login and restricting service actions based on, say, a user's role.
This is all well-established stuff in web-based apps via sessions, etc., but presents a number of issues when using microservices. For example, you'll probably want some sort of token (for the user) and a way to manage it.
Going through those steps will get your brain ticking over about any number of problems and will provide you with much learning.
Since you are using Rails, I'd suggest creating a User service (one rails app) and a Blah service (another rails app) that requires authorisation to access some actions. Building that, and thinking through the issues, and building solutions, will give you a lot of feel for building microservices.
Rails (specifically v4 in API-mode, which avoids a lot of MVC stuff) is actually quite cool for microservices, where you can leverage its filters and gems to provide cross service functionality -- like the token handling I alluded to above.
(As an aside: if you do do the above, you'll probably find that you need some sort of "system/root" user access to some services. The "obvious" solution is to create such a user with super powers (that only the system can use). However, think through the implications of this -- massive potential security hole -- and other ways in which you can provide the required services. Actually, thinking about it, that might be a prescriptive rule: never create a super/root user -- that's not to say that a user can't have, say, an admin role.)
Thanks! I agree that just building something is a great way to get familiar with this stuff. I'm not looking for someone to say "this is how you build SOA" (which is probably why I found the rails book lacking) but rather "here is some complex challenge which I solved in this way, and here are the things we would have done differently in a re-write". Getting started with microservices is easy - there's probably more code to write in the deployment / testing / monitoring / logging plumbing than there is in your entire first service - but I'm sure there are subtle patterns that others have found that'd be good to know.
However, since microservices are, by definition, small, building something basic is not complex or time-consuming. I'd suggest tackling something fundamental, such as user login and restricting service actions based on, say, a user's role.
This is all well-established stuff in web-based apps via sessions, etc., but presents a number of issues when using microservices. For example, you'll probably want some sort of token (for the user) and a way to manage it.
Going through those steps will get your brain ticking over about any number of problems and will provide you with much learning.
Since you are using Rails, I'd suggest creating a User service (one rails app) and a Blah service (another rails app) that requires authorisation to access some actions. Building that, and thinking through the issues, and building solutions, will give you a lot of feel for building microservices.
Rails (specifically v4 in API-mode, which avoids a lot of MVC stuff) is actually quite cool for microservices, where you can leverage its filters and gems to provide cross service functionality -- like the token handling I alluded to above.
(As an aside: if you do do the above, you'll probably find that you need some sort of "system/root" user access to some services. The "obvious" solution is to create such a user with super powers (that only the system can use). However, think through the implications of this -- massive potential security hole -- and other ways in which you can provide the required services. Actually, thinking about it, that might be a prescriptive rule: never create a super/root user -- that's not to say that a user can't have, say, an admin role.)