The real advantage of microservices is being able to scale different parts independently.<p>The way we do it in Java is to logically partition services,  and it turns out that some of them are so small they fit in the same address space as the server process and it just not worth breaking them out,  particularly when one of our goals is to be the service that is done loading before your finger has even hit the stopwatch to start timing the 15 second load of the other guys.  (Who are doomed because they use shiny front-end technology)<p>There is one &quot;service&quot; that runs out of process on the same physical server,  and then two &quot;services&quot; that run on other machines,  one of them is an authentication server hosted at Stormpath,  the other one is a DynamoDB.  We rebuild the primary and supporting databases each day on a second cloud server,  connect it to Stormpath and Dynamo,  then nuke the old server once it passes int tests.<p>You need to have a strategy for ser&#x2F;deser that requires close to zero effort when you need to change things.  Frankly I think it is stupid stupid stupid to replicate code any more than you need to.  I worked at a place where &quot;on principle&quot; they wanted to have the code be decoupled so every team would hand-code ser&#x2F;deser logic which meant that it took two weeks or more to make a small change that would ripple through the system and introduce more bugs.<p>Lotsa consequences of that such as &quot;have a schema&quot;,  &quot;generate code&quot; and &quot;don&#x27;t module module A in Rust,  and module B in Go,  and module C in Shiny3&quot; or you are doomed.  It feels so good to have competitors that are doomed.