<story><title>Microservices and the First Law of Distributed Objects</title><url>http://martinfowler.com/articles/distributed-objects-microservices.html</url></story><parent_chain><item><author>PaulHoule</author><text>The real strength of micro services is physical isolation more so than logical isolation.  That is, there is an 80&amp;#x2F;20 rule as to scaling.&lt;p&gt;For instance,  there is probably one function of your system that is responsible for a huge amount of work.  If everything is in one database (say SQL, mongo,...) You have a complex system that is hard to scale.  If you split the heavy load out,  you might find the scaling problems vanish (because the high load no longer has the burden of excess data) and even if there is still a problem it is much easier to optimize and scale a system that does just one thing.&lt;p&gt;The most disturbing thing about microservice enthusiasts is that they immediately jump to:  oh,  we can write these services and clients in Cold Fusion, Ruby, COBOL, Scala, Clojure, PHP and even when we write them,  the great thing is &amp;quot;WE DON&amp;#x27;T HAVE TO SHARE ANY INFRASTRUCTURE!&amp;quot;&lt;p&gt;That&amp;#x27;s bougus to the Nth degree because a lot of the BS involved with distributed systems has to do with boring things like serialization,  logging,  service management,  etc.&lt;p&gt;I think you still want to use the same language,  same serialization libraries,  management practices,  etc.  across all of these services otherwise you are going to get eaten alive dealing with boring but essential problems.</text></item></parent_chain><comment><author>eikenberry</author><text>The real strength of micro services is that it should force you to specify your services by API and protocol. This is what allows it to scale to larger groups developers at the same time as scaling to large customer bases.&lt;p&gt;Both Netflix and Twitter, for example, have fallen into the trap you describe of using a common set of infrastructural libraries. With Twitter this has manifested by their micro services actually being a tightly coupled distributed application, not  a loosely couple set of services. Netflix on the other hand has the set of libraries, yet have many groups not using them and because they went with libraries instead of APIs&amp;#x2F;protocols the non-library using applications don&amp;#x27;t follows the standards.&lt;p&gt;You need fully specified APIs and protocols with at least a 2 if not 3 different implementation platforms to keep you out of the trap of the common infrastructure.&lt;p&gt;[edit: fixed capitalization]</text></comment>
<story><title>Microservices and the First Law of Distributed Objects</title><url>http://martinfowler.com/articles/distributed-objects-microservices.html</url></story><parent_chain><item><author>PaulHoule</author><text>The real strength of micro services is physical isolation more so than logical isolation.  That is, there is an 80&amp;#x2F;20 rule as to scaling.&lt;p&gt;For instance,  there is probably one function of your system that is responsible for a huge amount of work.  If everything is in one database (say SQL, mongo,...) You have a complex system that is hard to scale.  If you split the heavy load out,  you might find the scaling problems vanish (because the high load no longer has the burden of excess data) and even if there is still a problem it is much easier to optimize and scale a system that does just one thing.&lt;p&gt;The most disturbing thing about microservice enthusiasts is that they immediately jump to:  oh,  we can write these services and clients in Cold Fusion, Ruby, COBOL, Scala, Clojure, PHP and even when we write them,  the great thing is &amp;quot;WE DON&amp;#x27;T HAVE TO SHARE ANY INFRASTRUCTURE!&amp;quot;&lt;p&gt;That&amp;#x27;s bougus to the Nth degree because a lot of the BS involved with distributed systems has to do with boring things like serialization,  logging,  service management,  etc.&lt;p&gt;I think you still want to use the same language,  same serialization libraries,  management practices,  etc.  across all of these services otherwise you are going to get eaten alive dealing with boring but essential problems.</text></item></parent_chain><comment><author>superuser2</author><text>Docker is a promising building block for solving logging and service management and that&amp;#x27;s something I&amp;#x27;ve been playing with for a while. You stream your logs to your container&amp;#x27;s stdout&amp;#x2F;stderr and can pick them up from the Docker REST API. You can also hit the Docker REST APIs across your hosts to discover the IP addresses and ports of the containers running various images. None of this is &amp;quot;solved&amp;quot; yet but it&amp;#x27;s getting there.&lt;p&gt;Serialization... depends, but you can get pretty far with JSON over HTTP.&lt;p&gt;So I guess you do need your microservices to be uniform in some respects, but the consistency of &amp;quot;every microservice is a Docker container exposing a REST API that speaks JSON and streams logs to stdout&amp;quot; would seem to be enough.&lt;p&gt;It&amp;#x27;s easy to build that in several languages... if Rails makes sense, use Rails. If Sinatra makes sense, use Sinatra. If Java makes sense, use Java.&lt;p&gt;You could run into trouble if you start using languages that only one or two of your staff members know, but it does allow for some flexibility (i.e. just because certain parts of the application are enterprisey doesn&amp;#x27;t mean everything has to be.)</text></comment>