ianakelly · April 5, 2016 15:00
diff --git a/Microservice Architecture Review - Ian Kelly b/Microservice Architecture Review - Ian Kelly
 Page 18 "I call this"  Was expecting "We call this" as its written by multiple people and their is not a call out for whom the author is in the chapter.
 Chapter 2 is Missing any treatment of leveraging microservices to support a polyglot implementations vs standarization.  This is one of the powerful reasons for Microservices, the ability for the team who owns the service to make their own decitions about the implemntation and since all consumers consume the API interface none need to be aware of the implementation
 Also missing was a statement that many time carving up a monolith is much easier that producing a cogent microservice strategy from a green field.  This is true because often the teams understand the discrete components of the running monolith better than they can guess at the full component set of a new effort.
 First 2 chapters are highly referenced - I appreciate that but would also want a place where I could get to all the links - Would that be made available?
 Page 57 - Solution Architecture may not be a required element - there are many instances where there is not a strong or even present Macro view of how services interact from the start, this sometimes comes later as a force to rationalize the Microservice explosiion but its not always a precursor - If presented as something like that it may be an impediment to success for some feeling like they need to figure out the whole before working on the components.
 Chapter 3 is kind of a downer - After we hear how awesome things can be and how great the success of those who have chosen this way has been we enter into the "Standardize All the Things" section.  I bristle at the need to go back to this type of thinking and just seeing "Standardize" everywhere.  Figure 3-2 is brilliant but the text does not mirror how that can evolve from a very small set of goals and principles.  It needs a better tie in with Chapters 1&2 it is written like a stand alone article and has none of the references or what I think of as externally acquired authority on te subject. I do not like Chapter 3.
 Page 71 - "Now that we have a general model for establishing complex systems" WHOA!  We were just discussing Microservices how did this get to be a complex system on us?  I know what it can become and how the multiple connections and cross process dependancies may look like but that does not imply that we immediately move to compelexity.
 Page 73 - "The reason for this difference between real pilots and the average pilot can be sum‐ med up in what Rose calls the principle of jaggedness."  Who is Rose???  not ref'd or introduced
 Term MSA - just added out of the blue - Not liking that, and the Term MSA should not be used!
 Page 74 - "Goals for Microservice Architecture"  The stated goals are NOT uniform.  We jest heard how there is No Average man and before we heard how you would find your own goals to be then force fed three goals where Cost is #1?  That was in Chapter 2 as a difference from SOA!
 Chapter 4 is a little better but needs work to integrate to the tone and feel of the earlier chapters - It leaves me feeling like I have read chapter 4 in maybe 15 other books before.
 Page 81 - "Shared Capabilities" this is starting to read like a Thomas Erl SOA book of top down "Enterprise Architecture"  I wonder if this needs to be covered?  There are some rather strong contrasts from the text presented and some of the benefits of Microservice Architecture is based upon a departure from these things.  As stated in Steve Yeggae's famous Rant " It doesn't matter what technology they use. HTTP, Corba, Pubsub, custom protocols -- doesn't matter. Bezos doesn't care."  So there are fairly large scale proofs that this is not the way for all implementations.
 Page 99 - Presents service discovery as a requirement, not all systems and many of the successful ones too have not had service disovery mechanisms outside of load balancers.  This should be acknowledged.
 Chapter 5 - Could be good to show some graphic of the Service Discovery and Routing Styles mentioned
 Chapter 6 should be after Chapter 2 - it Flows better and provides some concrete examples and discussion that may help the tone of Chapter 3.
 Chapter 7 - I am not a fan of "Intro, Little Analog Story, and then the Meat of the topic" style.  Its too Blog/Article like.  Get me to the content.
 I think chapter 7 has some good elements but it needs to be reworked - its too authoritarian in its POV - maybe thats on purpose but if its going to be so driven by the desire to machinate controls it should have a counter point chapter that discusses the other side of the coin - people working together vs being controlled.
	Page 18 "I call this" Was expecting "We call this" as its written by multiple people and their is not a call out for whom the author is in the chapter.
	Chapter 2 is Missing any treatment of leveraging microservices to support a polyglot implementations vs standarization. This is one of the powerful reasons for Microservices, the ability for the team who owns the service to make their own decitions about the implemntation and since all consumers consume the API interface none need to be aware of the implementation
	Also missing was a statement that many time carving up a monolith is much easier that producing a cogent microservice strategy from a green field. This is true because often the teams understand the discrete components of the running monolith better than they can guess at the full component set of a new effort.
	First 2 chapters are highly referenced - I appreciate that but would also want a place where I could get to all the links - Would that be made available?
	Page 57 - Solution Architecture may not be a required element - there are many instances where there is not a strong or even present Macro view of how services interact from the start, this sometimes comes later as a force to rationalize the Microservice explosiion but its not always a precursor - If presented as something like that it may be an impediment to success for some feeling like they need to figure out the whole before working on the components.
	Chapter 3 is kind of a downer - After we hear how awesome things can be and how great the success of those who have chosen this way has been we enter into the "Standardize All the Things" section. I bristle at the need to go back to this type of thinking and just seeing "Standardize" everywhere. Figure 3-2 is brilliant but the text does not mirror how that can evolve from a very small set of goals and principles. It needs a better tie in with Chapters 1&2 it is written like a stand alone article and has none of the references or what I think of as externally acquired authority on te subject. I do not like Chapter 3.
	Page 71 - "Now that we have a general model for establishing complex systems" WHOA! We were just discussing Microservices how did this get to be a complex system on us? I know what it can become and how the multiple connections and cross process dependancies may look like but that does not imply that we immediately move to compelexity.
	Page 73 - "The reason for this difference between real pilots and the average pilot can be sum‐ med up in what Rose calls the principle of jaggedness." Who is Rose??? not ref'd or introduced
	Term MSA - just added out of the blue - Not liking that, and the Term MSA should not be used!
	Page 74 - "Goals for Microservice Architecture" The stated goals are NOT uniform. We jest heard how there is No Average man and before we heard how you would find your own goals to be then force fed three goals where Cost is #1? That was in Chapter 2 as a difference from SOA!
	Chapter 4 is a little better but needs work to integrate to the tone and feel of the earlier chapters - It leaves me feeling like I have read chapter 4 in maybe 15 other books before.
	Page 81 - "Shared Capabilities" this is starting to read like a Thomas Erl SOA book of top down "Enterprise Architecture" I wonder if this needs to be covered? There are some rather strong contrasts from the text presented and some of the benefits of Microservice Architecture is based upon a departure from these things. As stated in Steve Yeggae's famous Rant " It doesn't matter what technology they use. HTTP, Corba, Pubsub, custom protocols -- doesn't matter. Bezos doesn't care." So there are fairly large scale proofs that this is not the way for all implementations.
	Page 99 - Presents service discovery as a requirement, not all systems and many of the successful ones too have not had service disovery mechanisms outside of load balancers. This should be acknowledged.
	Chapter 5 - Could be good to show some graphic of the Service Discovery and Routing Styles mentioned
	Chapter 6 should be after Chapter 2 - it Flows better and provides some concrete examples and discussion that may help the tone of Chapter 3.
	Chapter 7 - I am not a fan of "Intro, Little Analog Story, and then the Meat of the topic" style. Its too Blog/Article like. Get me to the content.
	I think chapter 7 has some good elements but it needs to be reworked - its too authoritarian in its POV - maybe thats on purpose but if its going to be so driven by the desire to machinate controls it should have a counter point chapter that discusses the other side of the coin - people working together vs being controlled.