No plumbing is required in modern architectures such these of SAP HANA, Starcounter, or Tarantool. When the application server and database are combined, the access control is arbitrary, databases talk whatever you want, no need to torn the code apart into stored procedures, backend and frontend code. Plus to this, lots of unnecessary moving parts are removed in such architectures, so that the whole thing runs on 2 servers instead of 20, while the code is simpler than ever.
The referred article needs clarification. What it really addresses are the flaws of conventional software architectures. Fortunately, this critique does not generalize.
Many web apps are indeed suited as a logic sprinkled atop several *aaS endpoints. Music streaming, social networking, collaboration and such.
This client-side logic can be made to run really fast with the evolution of JS engines and now also WebAssembly. Meanwhile communication cost is always bound by signalling over wires times number of endpoints. More time waste comes from data redundancy invoked by a physical separation of services (severity depends on the app nature). Within the fastest client side possible, overall latency will be capped by messaging.
Still all is well while you have 3-4 endpoints to mash up: probably staying within 1-2 seconds of psychologically acceptable latency so that your user won't switch to something else too fast.
Things shall not be that funny once you need to integrate more than 5 endpoints. Messaging overhead turns into seconds and tens of seconds. A good example comes from business software. Parts of a typical ERP suite are tightly coupled on data: should you have a person, it is the same person for accounting, CRM, BPM, project planning etc. Integrate these parts the SOA way and obtain irreducible chatter between endpoints and thus slow UX.
It was observed that up to 40% of total system workload in typical SOA-style ERP suite is in data exchange between the core ERP system and the satellites. One has to control the flow between endpoints transactionally, hence aggressive caching is not only very complex there, but would not actually work.
Having that in mind and thinking of the enterprise software, I am personally in big favour of approach that SAP HANA guys took, where the business re-unites all the apps on a single platform and lets them share data in transactional way. This is contrary to the widespread belief that future enterprise systems should be a collection of SaaS components integrated through standard interfaces.
The management of redundancy is prohibitive, and extra workload from shipping data back and forth creates a bottleneck. And, by the way, there is no need to implement physically disjoint microservices to achieve great system modularity, neither should you build monolith anymore to address performance problems. Leverage the capabilities of modern software platforms and "do microservices the right way".
In the world of enterprise software understanding comes right now that data integration always beats messaging in total cost of ownership.
Surely there is no sliver bullet, what is good for enterprise software might not suit other domains. But just imagine when one builds a game engine where polygons are rendered on one machine, physics calculations are done on the other machine, multiplayer logic is on third, and all flows and mixes up through the user machine. Wouldn't it be kinda slow? But enterprise software done via messaging-based integration isn't really far from that.
The question here is really "When do you need distributed transactions"? One of misuses is when one cannot achieve enough performance on a single node. E.g., one builds a system serving 1000 REST requests per second (RPS), achieving 2 seconds latency per request, having a DB as a bottleneck. To be honest, I've seen real software built giving 23 sec latency per only 50 RPS. Does it mean there is a need to scale it out or simply that a chosen DB is a problem? The cases I've seen through my practice are mostly on the latter.
Simply choose the most suitable solution, not the most hyped one. A mistake would be to sacrifise transactions via using some "general NoSQL database". Today, for real, you can have a single node capable of millions RPS on real-world scenarios with ACID transactions of arbitrary complexity, choosing solution like http://starcounter.io/. Please, please don't just take yet another no-transactions DB, which is no-transactions even on a single machine, having 4 db nodes on 4 cores completely separate as if they've been 4 different machine. Then you observe bad performance and start to scale things up, paying more and more for the cloud. Not the best idea to spend time and money.
And, if you DO really need distributed transactions, then it mostly means they'd be driven by a logic of your subject domain. E.g., you might have one department in Sweden, one in the USA, then you need to manage distributed accounts in the right way, where "right" is up to your banking policy. However, if you need to scale reads, there is just no problem of doing so within "no-distributed-ACID" solution. The same time, if you need to scale writes, doing distributed transactions isn't a good idea either, as you've seen from the topic starter article.
So, right tool for the right job.
Outside of the brackets I keep a topic of fighting with latency via distributed transactions. I mean those things around caching, CDN and async replication. Distributed transaction isn't a remedy there at all, since it doesn't patch speed of light by any means.
The referred article needs clarification. What it really addresses are the flaws of conventional software architectures. Fortunately, this critique does not generalize.