ianakelly · April 28, 2016 19:28
diff --git a/Chapter 5 b/Chapter 5
 Page 69 - Might be a good use of a pivot from the seemingly simple question of "how to properly size microservices" into an adjustment 'how to properly scope" microservices scope = size (functional footprint) + boundaries (concept footprint)
 Page 69 - was the value of not sharing covered previously?  If so was the value of duplication as a desireable pattern covered?  I forget...
 Page 70 - The answer is 42 could use a Douglas Adams Hitchhikers Guide to the galaxy footnote.
 Page 70 - Just saw the handling of the first note on size and pivoting to scope - Nice!
 Page 70/71 - Brings up a reason to advocate for share nothing implementations - the New York developer building an app used in Cairo might also highlight the need for a regionally focused implementation that does NOT share an implementation across teams i.e. US accounting tax calc and Egypt accounting tax calc as seperate Microservices
 Page 72 - Typo "The Microwervice Way"
 Page 79 - The text refers to hiding implemntation details - in my experience this needs to be explained more broadly so folks can understand that you are sheilding API consumers away from knowing your internal models, terms, and concepts and putting things in the terms, concepts, and structures the client might assume.
 Page 81 - Bravon on the Greg Young inclusion! 
 Page 90 - Centralization - Might be a good launching point to discuss the diminishing economies of sclae in Microservices.  Software Arch has long held that reuse is the highest and best goal, where as in the Microservice ecosystem it creates limitations in your deployment, versioning, size, complexity, and external depedancies
 There should be some overview of Immutable Microservices in the chapter - so far everything assumes mutated state
	Page 69 - Might be a good use of a pivot from the seemingly simple question of "how to properly size microservices" into an adjustment 'how to properly scope" microservices scope = size (functional footprint) + boundaries (concept footprint)
	Page 69 - was the value of not sharing covered previously? If so was the value of duplication as a desireable pattern covered? I forget...
	Page 70 - The answer is 42 could use a Douglas Adams Hitchhikers Guide to the galaxy footnote.
	Page 70 - Just saw the handling of the first note on size and pivoting to scope - Nice!
	Page 70/71 - Brings up a reason to advocate for share nothing implementations - the New York developer building an app used in Cairo might also highlight the need for a regionally focused implementation that does NOT share an implementation across teams i.e. US accounting tax calc and Egypt accounting tax calc as seperate Microservices
	Page 72 - Typo "The Microwervice Way"
	Page 79 - The text refers to hiding implemntation details - in my experience this needs to be explained more broadly so folks can understand that you are sheilding API consumers away from knowing your internal models, terms, and concepts and putting things in the terms, concepts, and structures the client might assume.
	Page 81 - Bravon on the Greg Young inclusion!
	Page 90 - Centralization - Might be a good launching point to discuss the diminishing economies of sclae in Microservices. Software Arch has long held that reuse is the highest and best goal, where as in the Microservice ecosystem it creates limitations in your deployment, versioning, size, complexity, and external depedancies
	There should be some overview of Immutable Microservices in the chapter - so far everything assumes mutated state