Most large-scale web companies have evolved their system architecture from a monolithic application and monolithic database to a set of loosely coupled microservices. Using examples from Google, eBay, and other large-scale sites, this talk outlines the pros and cons of these different stages of evolution, and makes practical suggestions about when and how other organizations should consider migrating to microservices. It concludes with some more advanced implications of a microservices architecture, including SLAs, cost-allocation, and vendor-customer relationships within the organization.

<ul>
  <li><i>In a monolith there is no enforcement of modularity. It all depends on the discipline of the engineers. Sloppiness can happen.</i></li>
  <li><i>The database, the data persistence layer is usually the hardest to decouple.</i></li>
  <li><i>If you don’t end up regretting your early technology decisions, then you probably over engineered.</i></li>
  <li><i>Microservice is SOA done properly.</i></li>
  <li><i>Natural selection of services: Services continue to justify their existence through being used.</i></li>
  <li><i>Architecture without architect. No central approval for technology decisions.</i></li>
  <li><i>Standardized communication.</i></li>
  <li><i>Standardized infrastructure.</i></li>
  <li><i>In a mature ecosystem of services, we standardize the arcs of the graph, not the nodes!</i></li>
  <li><i>Small teams, Microservices, DevOps, Agile practices = are facets of some modern programming practices. It just does not have a name yet.</i></li>
</ul>