Getting past 'as a Service'

It strikes me that, for the last ten or so years, I have been deploying Telephony as a Service.
So?
Note that this isn't Telephony running on Freeswitch running on AWS (Twilio), or Telephony running on Asterisk running in our datacenter (Fonality), or even Telephony running on a Huge Solaris Cluster Somewhere (Broadsoft).
The point here is that the type of service I built doesn't neatly break down into the oh-so-neat layers that you always see in these type of diagrams

If anything, what I've built is more like

where the various parts are all munged into one somewhat nebulous cloud.
"But!", I hear you start, "But!  How can you build anything to scale when its all cloud-y and nebulous-y!?"
The easy answer, of course, is to wave my hands and say something mysterious and profound, like "Exelsior!" or, "Erlang!".
The reality, however, is that in the fine, you will find various elements of Infrastructure, Platform, and Software, all doing Service-y things.  But, in the gross, they are not so easily de-reference-able.

The thing is, the layers are all a-merging.  It turns out that building complex distributed telephony systems is hard.  Really hard.  To build out some of the more complex applications, you really need to have a pretty good handle on whats going on at all the levels - the servers handling the calls (infrastructure-aaS), the applications moving data around (platform-aaS), and the APIs used to actually manipulate the calls (software-aaS).
Yes, of course, by the time this is all presented and visible to the end user in some nice-neat GUI, or better yet, API, its all taken care of and is a simple SaaS.
Except that it isn't.
Why not?  Because there are all sorts of fun things involved like rate-control, telephony costs, QoS, etc., that really cut across various levels of the platform.  And yes, I know, we could make oure APIs even more complicated, and end up with a scenario where the stack is truly de-referenced, except at this point it is not just getting a little ridiculous, it is pretty much making my original point, which is that the layers are a-merging, and you need to have visibility across the different layers of the stack.
Its not just me, by the way.  Take a look at Heroku, or Elastic BeanStalk - they do almost exactly the same thing.  Its basically the growing realization on everybody's part (even Werner Vogels!) that once people start to get specialized (like us! Telephony clouds!), they need to have greater visibility into how the cloud functions, and consequently too much de-referencing can actually end up being counterproductive.
In short, the future is about Cloud-as-a-Service (CaaS?), where the cloud is the merging of the previous as-a-Services.