Starting with microservices
I have done the full theme park ride on monolith-&gt;microservices-&gt;monolith. Both have ups and downs.<p>The most important thing I learned is that &quot;microservices&quot; in absolutely no way necessitates &quot;bullshit spread across multiple cloud vendors and other scenarios involving more than 1 computer&quot;. What part of microservices says things <i>must</i> be separated by way of an arbitrary wire protocol?<p>We now have a &quot;monolith&quot; (process) that is comprised of many &quot;microservices&quot; (class files), each of which is responsible for its own database, business logic, types, etc. These services are able to communicate amongst themselves using the simple path of direct method invocation.<p>If you are looking to scale up your capacity or even make things more resilient, microservices vs monolith is really not the conversation you need to be having. If you are trying to better organize your codebase, you might be in the right place but you also need to be super careful with how you proceed.<p>We wasted a solid 3 years trying to make microservices solve all of our problems. Looking back, we spent more time worrying about trying to put Humpty Dumpty back together again with JSON APIs and other technological duct tape than what our customers were complaining about.