Starting with microservices
I&#x27;ve come to the conclusion that microservices as usually implemented are simply a Conway&#x27;s law concern.<p>We haven&#x27;t had a great track record defining the semantics of component boundaries, but http is both simple enough that it constricts code flow in a particular way leaving a lot of misunderstandings and bike shedding discussions off of the table, and is the ligua franca for external services owned by other orgs so your engineers can be universally expected to understand those semantics.  There is a nice decoupling of letting teams make technology choices though.  Letting that drift on a per team basis is kind of nice to allow experimentation with different technologies without having to get the whole org onboard.<p>Maybe I need to go on the talk giving, consultant circuit reselling a restricted view of DI as &quot;hybrid service architecture!  Write your code as microservices but DevOps can colocate your apps in the same process if that&#x27;s more efficient!&quot; Lolz<p>It&#x27;s also quite a nerd trap as we developers love to separate components into as small of boxes as possible, but just like I&#x27;ve seen super deep object hierarchies that didn&#x27;t gain you anything at the end of the day, it&#x27;s easy to fall into the trap of spinning every tiny bit of code into its own service.<p>I&#x27;m creating my own backend arch right now from scratch, and really trying to look at each network traversal from a &quot;what does drawing this boundary actually get me&quot; perspective.  And I&#x27;m only splitting that out because the third party protocol being implemented is inherently separate services in an interesting way.