MonolithFirst
> 1. Almost all the successful microservice stories have started with a monolith that got too big and was broken up.<p>This is pure survivor bias. The majority -- by far -- of 'failure stories' I know of in the software industry are ones in which a company tried to take their monolithic code base and modularize or microservice-ize it.<p>> 2. Almost all the cases where I've heard of a system that was built as a microservice system from scratch, it has ended up in serious trouble.<p>This is not because microservices-first is inherently flawed. This is purely a skill set issue. Microservices demand a greater skill set. A 'monolithic' approach puts much less of a demand on the engineer's skill set.<p>For a simplistic but illuminative example, if all you know how to do is build systems that operate on global mutable state (most newbie programmers), then of course you will run a lot further in a monolith than if you are trying to do this in a microservices pardigm.<p>This is a simplistic example because effective use of microservices requires much more of a skill set than not using global variables. The truth is that effective use of microservices (knowing how to build architecturally sound software) is way beyond the reach of MOST smart, senior level engineers that I've met in my career. If this sounds arrogant, it's not; there's a definitive architectural skill set that CAN BE LEARNED but that is missing from most software practitioners. (Our industry/academies need to learn how to teach it.)<p>This is the elephant in the room in our industry--and why we spin so many wheels talking about everything else. All of the energy we spend talking about patterns, processes, languages, etc etc do so much less for our industry than if we trained our practitioners in how to construct architecturally sound software systems.