3 ms·

If you are thinking about going down the microservice path, then do yourself a favour and read Building Microservices (O'Reilly) [1]. It is a little wordy but l

If you are thinking about going down the microservice path, then do yourself a favour and read Building Microservices (O'Reilly) [1]. It is a little wordy but lays it down pretty well. I'm not affiliated with them, but do heavily research this space, and the larger ecosystem. I found it pretty well rounded. I'm not sure this articles 10 question list really covers the scope of what microservice means. For reference, I'm not talking about ~5 microservices here (as that might be trivial), but am thinking in the scope of ~50-100+. In that you should have a pretty good reason to adopt them re: your team size and scale of operations. You can see an increased rate of deployed changes, performance boosts, and freedom to choose languages that fit the problem, but it comes with additional operational complexity. In that, you will pay an upfront tax for using microservices. So, you really need to think about asking yourself these types of questions (and the ones in the article). - How and where should you break things into microservices (if monolith)? - Who should own the microservice? What does this mean in terms of coding, testing, deploying, ops issues, etc? - You will need team buy in. A switch could mean months of work. The upside is massive but you cannot push this on them. - How do you deal with things at the datastore level (can/should two microservice access the same table space)? - How are you going to deploy microservice via CI/CD pipeline into your production env? - How do microservices communicate (RPC, API, etc)? - What type of metrics do you build into your microservice? - How can you trace requests when they hit multiple microservices? - You'll need to beef up your operations tools to manage these microservices too. What does that look like? These are pretty fundamental things you need to think about and the book does a pretty decent job at explaining it. [1] http://shop.oreilly.com/product/0636920033158.do http://shop.oreilly.com/product/0636920033158.do

musha68k 11y ago
TL;DR buy the book it's great! 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 http://martinfowler.com/bliki/MicroservicePrerequisites.html

musha68k 11y ago

TL;DR buy the book it's great! 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 http://martinfowler.com/bliki/MicroservicePrerequisites.html