Typically they get mentioned in the same breath as PaaS and CI/CD, because these are necessary preconditions for sanity.<p>Architecture and design follow the contours of possibilities our tools lay out for us.<p>If it is hard to build many little services that interact (circa 1999: provision servers by fax, meet them at DC, configure each by hand, install software via FTP, fuck it doesn't work, fuck this I'm writing a monolith) then they don't get written.<p>If the cost of microservices drops -- you install a PaaS, you have decent CI/CD -- then the relative advantages (team independence, rapid iteration and deployment, somewhat easier horizontal deployments) become more compelling.<p>You'll see this pattern across the industry. Every "revolution" is really just a shift in the underlying economics of the different options. NoSQL was compelling because HDDs are slow, with SSDs the gap was narrowed considerably. Networks are fast enough that paying the network hop is considered acceptable for most human-facing purposes, once upon a time we did everything we could to squeeze stuff into the L2 cache. You can write massively multi-threaded software in COBOL, but it's probably going to be easier to use Go or Java for that purpose.<p>As the relative costs of alternatives shift, so too the industry.<p>Which is a long-winded way of saying: I don't think PaaS-less microservices is really "a thing". Hypothetically possible, but going to quickly run into heavy headwinds.
What do you mean by PAAS?<p>In my experience, every company that ends up adopting a microservices architecture ends up building some sort of layer of developer tooling on top of their ops infrastructure (whether it's K8S, EC2, or something else). This is because in microservices, you need to make it easy and cheap to deploy new services, which means developers need some sort of access to operational tooling (or else you need a huge ops team).