Each CGI script has access to pieces of state that the other scripts in the system have access to. For example, "login.pl" could access state related to more t

Each CGI script has access to pieces of state that the other scripts in the system have access to. For example, "login.pl" could access state related to more than just logins; it has full access to the database and could conceivably do anything. For that reason, people call the architecture monolithic, even though each API endpoint is its own computer program that runs top to bottom in isolation from the other CGI scripts in the directory/app. A microservices approach would separate the state related to logins from the state related to other features. So there would be a login services, that accepts usernames and passwords from end users, and provides internal services like "given a session cookie, tell me if it's valid and what the user's name is" or "store this key/value to the session" or "read this key/value from the session". Isolating concerns from each other is common in both monoliths and microservices. It's just how people tend to design ANY computer program or distributed system. Obviously it's hard to draw the line between "function that does this" and "service that does this", and it's possible to have microservices that you call over an RPC that just reads/writes the same database the caller uses. It's messy and indistinct, and is probably too general a word to attach a ton of meaning to. (My followup is to read deeply into critiques of the patterns. The HN commenter that says "microservices suck" will be perfectly fine that Apache sends a WSGI request to a Python app, which speaks TCP to a database. Those, they say, are services, not microservices, so their rage does not apply in that case. But... it's a pretty arbitrary line, so you have to read and understand carefully to identify the problems they have and what advice of theirs to take.)