You Want Modules, Not Microservices
Ted Neward argues the microservices pitch is recycled: of six quoted benefits, two come from microservices literature, two from twenty-year-old EJB material, and two from Oracle Tuxedo, forty-year-old technology. Strip the branding and what remains is the module — an independently built, versioned, deployed and reusable unit of code, the concept Parnas defined in 1971 and Unix pipes-and-filters delivered in the 1970s. What organizations actually bought was organizational clarity: small teams owning their own analysis, testing, data and deployment dependencies instead of waiting on DBA, QA or infrastructure groups, at the cost of full-stack staffing and on-call duty. Technically, in-process module calls become network calls, adding five to seven orders of magnitude of latency and running into the Fallacies of Distributed Computing, which more nodes only worsen. Neward's advice: any decomposition behind a common API convention works; fix organizational dependencies directly. Suited to architects and tech leads.