Some minor copy editing

_posts/2019-04-10-no-true-microservice.md

@@ -12,32 +12,32 @@ when it comes to "legacy" code. In most of my experiences, it has been
 delivered more subtly than this textbook example of the [No true Scotsman
 fallacy](https://en.wikipedia.org/wiki/No_true_Scotsman). "Microservice" is
 already a silly term, one which many people defend by evoking the mythic status
-of "the unix philosophy." Composition of components is an extremely valuable
+of "the unix philosophy." Composition of components is definitely a valuable
 trait in a system, especially as an organization scales with new people and
-projects.
+projects, but the microservice purity test fails in many cases.
 
 This misguided notion that everything in a service-oriented infrastructure
 should do "one thing and one thing well" is at complete odds with the realities
 of data affinity and network latency. After trying to break up a few monoliths
-"into services" in recent years, my focus has shifted from what serves the HTTP
-requests and has settled onto: how the data is stored and accessed. Taking a
+"into services" in recent years where I have frequently encountered this
+microservice-all-the-things desire, my focus has shifted away from what serves the HTTP
+requests. Instead, I'm much more focused how the data is stored and accessed. Taking a
 monolithic application and merely swapping function calls for remote procedure
-calls is not _actually_ solving anything.
+calls is not _actually_ solving anything. Optimising around what parts of the
+system require data makes more sense to me as a guideline.
 
 The "test" that I apply to the "no true microservices" approach is this: should
 authentication and authorization be handled by one service, or two? I think the
 question gets at the heart of many service-oriented architecture designs.
 Authentication is "easy", compared to authorization which can bring in
 a whole carton-load of business logic and data requirements. That said, are
-there any flows now, or in the immediate future, which need authentication but
-**don't** need authorization? Applying the "one thing" rule, these two
 functions should probably be performed by two separate services. But if you
 don't have any need for authentication without authorization coming alongside
 it, then two separate services introduces another network call, another
 service-dependency to manage, and unnecessary complexity. "But we might need it
 some day!" a microservice aficionado might retort. I certainly agree, we might
 need lots of things. Building and **delivering** software requires trade-offs,
-and the business' requirements for the next 6-12 months are not going to be
+and if the business' requirements for the next 6-12 months are not going to be
 addressed by pre-optimizing the split of these two concerns into separate
 services, then it is likely best to say [You Aren't Going To Need
 It](https://en.wikipedia.org/wiki/You_aren't_gonna_need_it) and move on.
@@ -53,10 +53,10 @@ monitoring, and debugging concerns which already affect service-oriented
 architectures. This is not to say that Functions as a Service (FaaS) are a bad thing,
 quite the contrary. I love the model for simple and stateless API endpoints,
 like handling inbound requests, enriching them, and putting their contents
-directly into a commit log/queue system for later processing and data
-warehousing. To suggest that all services fit the FaaS model is patently
-absurd; I feel similarly about the "one thing and one thing well" model of
-microservices. 
+directly into a commit log/queue system for later processing/warehousing. To
+suggest that all services fit the FaaS model however is patently absurd.
+Unsurprisingly, I feel similarly about a universal application of the "one
+thing and one thing well" microservice model.
 
 Avoiding the No True Microservice fallacy, I recommend considering
 service-oriented architecture design with the following, intentionally ordered