I'm a little long in the tooth so aren't as up to date with every new fangled technique to land in IT. Some of you may find this anecdote interesting and somewhat pertinent.
Many years ago the electric utility I worked at had a home-grown set of batch-run Pro-C and PL/SQL programs that ran various metrology operations on large volumes of meter data. These things were interdependent, ran single-threaded and created a real "peak-CPU-demand" problem for our compute hardware (the irony was not lost). Our industry was facing an explosion in data due to the switch to smart metering. What to do?
Our apps all depended on an Oracle DB. Oracle had recently introduced Advanced Queuing. So I figured I'd de-batch and decouple these things using AQ. Every program (C++) was broken into "atomic", stateless business tasks. Every task was fed by a "task queue". Tasks would take a work-item off a queue, do their thing and depending on the outcome, would look up a destination queue (destinations could only be "business state" queues; task queues could only be subscribed to state queues (topics)), dropping the task outcome onto the state queue. Being stateless and callback driven by AQ, we could run these things together and ramp them up and down as demand required.
The overall structure and dependency of the various tasks was externalised through the data-driven queue network.
The resulting solution was far more maintainable, provided "free" user-exits (by virtue of being able to plumb new tasks to existing "business state" queues), and was eminently horizontally scalable. In hindsight this was definitely not state of the art. But we were a pretty conservative business with a bunch of pretty unworldly C and PL/SQL programmers. None of us had used Java at that point. But with this approach were able to cope with a massive increase in data volume and make use of all our expensive Sun cores most of the time.
No Java, no REST, no HTML, no SOAP. But we called these queue micro services :-)