Computers where always do-ers. All the code of assembly languages are functions, including those who deal with memory. As functions became more complicated and memory usage went helter skelter, a new paradigm to keep memory relevant to functionality in a sustainable fashion evolved, which is the object oriented programming.
Objects are ways to align functionalities with related memory locations based on their relations to real life entities. However, When objects used for greater scopes like communications and business transactions, where different definitions of same entities happen, their structures struggled to adapt, and the control is back to functions. With concepts like remote “method” invocation and remote “procedure” call, these lifelike memory structures begin to go backstage. As business evolves to change its focus to be on services delivered to customers and the processes to deliver these services, software development had driven to service orientation, where the rhetoric of business and technical contexts are saying something important about what was happening with SOA and lately microservices.
On the business context: Service Oriented Architecture (SOA) means to avoid what the business organizations are, and focuses on what it could do as “services”; by focusing on the process they provide and align the teams for process actions. It tends to disregard the organizational structures and internal entities (usually represented in code as “objects”) and perish processes (executed as a set of functions). The rapidly changing business needs and the high dependency it hold to the IT have pushed the focus on the process over structure to how software should be built and provided.
On the technical context: service orientation succeeds over distributed objects by focusing on what the system components are doing and hiding any implementation details (usually written in OO languages). What software components are “doing” are provided as service”operations”, or in other word “functions”. Services in SOA are more like classifications of functions based entirely on the functionality regardless the relations to internal memory structures (objects) or infrastructure implementation details, except for inputs & outputs.
So, was that intentional hiding of how software manages its memory, and structures its data had proved aptitude over the intent to mimic real life objects? Should functionality be separate from how its data stored? What history revealed was that the real world is the one who is keep changing, and the real persistent is the functionality we need from software. Functional programming makes software focus on what the system will do without bothering to mimic the world objects to stay relevant. It is always relevant by what it can do. However, SOA is more than mere functions, it is one step further by hiding most of implementation and deployment details, and presents functionality as a single, standardized layer, where the only remarkable features are the functionalities. Nevertheless, the business itself usually still behind to achieve this Plutonian SOA. They are also thorn upon their hierarchies to abstract their services to their customers.
This view of the customers – or user – who shouldn’t be distracted by anything but the service they get, had dug its way down the service causality to the internal orientation of the software it uses, until we had the known service orientation. Now even internal components are trying to be “Microservices” instead of being classes. Thus, microservices are functional groups usually on object scale that hide not only their memory and data structures, but even how they are deployed and implemented physically. The result after decades of software engineering is that functional orientation became so dominant to split not just code, but even deployment stack under the name of microservices.