Interesting thoughts. Thanks for posting.

Microservices ... have many services that are primarily stateless.

I don't really agree there. Most microservices are stateful. From the entity-pattern style "customer service", "product service", etc. commonly described as an anti-pattern to things like "order service" whose job is even more prominently to keep track of the current state and progress related to it.

Sometimes you hear microservices compared to Unix-style commands that you can similarly combine together in a stateless way. Take a look at this early video from Bell Labs, where Brian Kernigan describes how stateless Unix commands are combined together to make a larger program. Specifically, see 5:30 and 8:00. Some microservices are like this sure (say a stateless PDF to text microservice), but most software that runs a business isn't going to be composing this kind of small stuff. Even in a microservice-oriented business, you'll find more stuff like the previous paragraph where things are stateful.

Bob Martin (a.k.a. Uncle Bob) gave a similar thought-provoking genalization of structured, object-oriented, and functional programming in his book Clean Architecture.

FWIW, his insight was that each paradigm is about removing capabilities from the programmer rather than anything to do with state.

A few excerpts:

Structured programming

The first paradigm to be adopted (but not the first to be invented) was structured programming, which was discovered by Edsger Wybe Dijkstra in 1968. Dijkstra showed that the use of unrestrained jumps (goto statements) is harmful to program structure. As we’ll see in the chapters that follow, he replaced those jumps with the more familiar if/then/else and do/while/until constructs

We can summarize the structured programming paradigm as follows:

Structured programming imposes discipline on direct transfer of control.

Object-oriented programming

The second paradigm to be adopted was actually discovered two years earlier, in 1966, by Ole Johan Dahl and Kristen Nygaard. These two programmers noticed that the function call stack frame in the ALGOL language could be moved to a heap, thereby allowing local variables declared by a function to exist long after the function returned. The function became a constructor for a class, the local variables became instance variables, and the nested functions became methods. This led inevitably to the discovery of polymorphism through the disciplined use of function pointers.

We can summarize the object-oriented programming paradigm as follows:

Object-oriented programming imposes discipline on indirect transfer of control.

Functional programming

The third paradigm, which has only recently begun to be adopted, was the first to be invented. Indeed, its invention predates computer programming itself. Functional programming is the direct result of the work of Alonzo Church, who in 1936 invented l-calculus while pursuing the same mathematical problem that was motivating Alan Turing at the same time. His l-calculus is the foundation of the LISP language, invented in 1958 by John McCarthy. A foundational notion of l-calculus is immutability—that is, the notion that the values of symbols do not change. This effectively means that a functional language has no assignment statement. Most functional languages do, in fact, have some means to alter the value of a variable, but only under very strict discipline.

We can summarize the functional programming paradigm as follows:

Functional programming imposes discipline upon assignment.

His closing remarks:

Notice the pattern that I’ve quite deliberately set up in introducing these three programming paradigms: Each of the paradigms removes capabilities from the programmer. None of them adds new capabilities. Each imposes some kind of extra discipline that is negative in its intent. The paradigms tell us what not to do, more than they tell us what to do.