add monolith vs microkernel debate

README.md

@@ -158,7 +158,7 @@ I once consulted a startup where a team of three developers introduced 17(!) mic
 
 Is this the right way to approach the uncertainty of a new system? It's enormously difficult to elicit the right logical boundaries in the beginning, and by introducing too many microservices we make things worse. The team's only justification was: "The F(M)AANG companies proved microservices architecture to be effective". *Hello, you got to stop dreaming big.*
 
-Checkout the [Tanenbaum–Torvalds debate](https://en.wikipedia.org/wiki/Tanenbaum%E2%80%93Torvalds_debate). The claim suggested that Linux's monolithic design was flawed and obsolete, and that we should do a microkernel architecture instead. Indeed, the microkernel design seemed to be superior "from a theoretical and aesthetical" point of view. Three decades on, microkernel-based GNU Hurd is not yet production ready, and Linux is everywhere - this page is powered by Linux, your smart teapot is powered by Linux.  
+Checkout the [Tanenbaum–Torvalds debate](https://en.wikipedia.org/wiki/Tanenbaum%E2%80%93Torvalds_debate). The claim suggested that Linux's monolithic design was flawed and obsolete, and that we should do a microkernel architecture instead. Indeed, the microkernel design seemed to be superior "from a theoretical and aesthetical" point of view. Three decades on, microkernel-based GNU Hurd is still in development, and Linux is everywhere - this page is powered by Linux, your smart teapot is powered by Linux.  
 
 A well-crafted monolith with truly isolated modules is often much more flexible than a bunch of microservices. It also requires far less cognitive effort to maintain. It's only when the need for separate deployments becomes crucial (e.g. development team scaling) that you should consider adding a network layer between the modules (future microservices).