Traditional applications can be monolithic beasts with APIs as the final layer These services present a prescribed flow are often inflexible and were built to do a specific purpose.
Traditional applications are usually object oriented with a series of services being called internally, and eventually rendered as a soap/rest API. Quite often with all functions being within a single code repo.
In contrast a Micro services oriented architecture, each set of functions are usually in their own repo, and they expose each service as a rest API. These APIs don’t need to be public facing (thats a separate discussion), but the fact is that they built to be available for consumption.
Orchestrated services (services which call other services) are often used to sequence service together increasing error handling and roll back and protecting the processes from the caller.
A legacy api vs a micro services orchestration is almost identical, but because the micro services now exist, it allows a developer to re-orchestrate for other uses without much effort.
True innovation requires a exploration of new uses, and that often requires the need to intermix new partners/software/uses with existing services. Micro services by design are delivering 1 core function per service, its beauty is that you can uncouple, re-assemble and re-orchestrate services without changing the core contract in a way that allows a separate trusted app to be built without needing to alter any of the existing code..
Micro services architecture is not easy, but if implemented properly can be a strong enabler to deliver iterative innovation without compromising your core API contracts/functions.