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.
(No side-interest here, just found it confusing that the page mentioned "hardcopy expected to be published in May")
Designing Distributed Systems https://www.oreilly.com/library/view/designing-distributed-s...
Building Evolutionary Architectures http://shop.oreilly.com/product/0636920080237.do
Building Microservices http://shop.oreilly.com/product/0636920033158.do
They encompass most of the topics you've enumerated earlier.