I'll second that, can't recommended the book enough. It will tell you exactly why and when you should go down the microservice rabbit hole (at this point). I'm saying at this point because there are still many angles to this (actually by paradigm) and lots of tooling surrounding it which are not quite there yet (including most prominently docker & co).
Don't fall for the admittedly great modern devops/open-source marketing.
I've been doing both application development as well as good-old systems administration (xen, jails, openvz) for many years and believe me this stuff is still very resource intensive even with the help of other similarly experienced peers readily available. We are literally talking google-level infrastructure architecture, which of course is both bad (setup time) and good (much more flexible and often "simpler" to grasp when the whole flow is established).
While I'm still not at the product stage with my two microservice projects started in August and September (both explicit microservice customer requests, mind you) a friend of mine meanwhile has single-handedly been building two monoliths over the last couple of months. He's been leveraging the still undeniable king-of-web-app-productivity-combo of rails/heroku and is about to move on to his next project while his customers are down the "let's polish some more" beta publishing-angst.
Microservices are fun and they are an important development in our field for many use-cases but be an engineer and pick the right tool for the right job, already - educate your boss, peers or customers about the importance of seeing things more objectively!
Also, don't succumb to the macho "You must be this tall to use microservices. OK, challenge accepted!" like I have to admit to have fallen for myself (I readily obliged to going forward with the tasks at hand) - the cards are largely stacked against you, most certainly when you are alone or not well connected!
I'll second that, can't recommended the book enough. It will tell you exactly why and when you should go down the microservice rabbit hole (at this point). I'm saying at this point because there are still many angles to this (actually by paradigm) and lots of tooling surrounding it which are not quite there yet (including most prominently docker & co).
Don't fall for the admittedly great modern devops/open-source marketing.
I've been doing both application development as well as good-old systems administration (xen, jails, openvz) for many years and believe me this stuff is still very resource intensive even with the help of other similarly experienced peers readily available. We are literally talking google-level infrastructure architecture, which of course is both bad (setup time) and good (much more flexible and often "simpler" to grasp when the whole flow is established).
While I'm still not at the product stage with my two microservice projects started in August and September (both explicit microservice customer requests, mind you) a friend of mine meanwhile has single-handedly been building two monoliths over the last couple of months. He's been leveraging the still undeniable king-of-web-app-productivity-combo of rails/heroku and is about to move on to his next project while his customers are down the "let's polish some more" beta publishing-angst.
Microservices are fun and they are an important development in our field for many use-cases but be an engineer and pick the right tool for the right job, already - educate your boss, peers or customers about the importance of seeing things more objectively!
Also, don't succumb to the macho "You must be this tall to use microservices. OK, challenge accepted!" like I have to admit to have fallen for myself (I readily obliged to going forward with the tasks at hand) - the cards are largely stacked against you, most certainly when you are alone or not well connected!
http://martinfowler.com/bliki/MicroservicePrerequisites.html