MBaaS is dying, and not just because of the awful acronym

Another hot, as-a-service acronym seems to be biting the dust.

“MBaaS” – mobile backend-as-a-service – received perhaps its death blow when Facebook announced it would be shutting down Parse, the company’s popular service for mobile developers. This follows kill announcements for similar services, including Dropbox’s Datastore API and StackMob (as well as a near-death scrape for Kidozen – albeit for different reasons).

Strangely, the need for MBaaS remains.

To create great mobile experiences, developers need quick and simple access to the kinds of backend cloud services (e.g. photo store, geolocation, key/value pair) that make their apps go.

Indeed, the MBaaS space remains flooded with vendors.

So what’s going on?

The standalone problem

As the “M” in the acronym declares, the majority of MBaaS offerings are built exclusively for mobile use cases. That is, they provide out of the box a preset number of services, perhaps 20 to 30, that are essential for most mobile apps.

Rather than having to handcraft these services again and again, developers could simply open up the box and choose what they needed, along with the necessary cloud infrastructure to run them. Until very recently, that was a boon – enough obviously to attract a wide market of vendor aspirants.

But today, “mobile” is no longer just about “an app running on a smartphone.”

Rather, it’s about engaging digital experiences that run beautifully across a range of devices –a range that seems to expand by the quarter, and which certainly no longer consists exclusively of devices with screens.

In that world, the backend services challenge is much larger. Imagine you’re part of a development team asked to create a fulfilment app that must orchestrate data from the company’s SAP and Oracle systems, as well as Salesforce and perhaps an external data source such as LinkedIn. For extra credit with the lines of business, the app should have a slimmed-down Apple Watch extension. (This scenario is not entirely invented. We see customers confronting these kinds of challenges on a regular basis.)

And remember: your legacy middleware/ESB investments were built for web. They don’t speak mobile.

In this scenario, you bump up against the limits of pure MBaaS pretty quickly. You still need its services – your fulfilment app needs photo storage and geolocation, for example. But there’s plainly much more.

Small wonder that in our own recent survey of almost 6,000 mobile developers, conducted jointly with IDC, nearly three-quarters of the respondents named getting mobile-optimized access to backend data as “the most challenging aspect” of app development.

MBaaS as a citizen of the larger microservices world

The truth seems to be that MBaaS isn’t dying outright; instead, it’s necessary services are gradually being subsumed into larger, microservice-driven architectures.

The embrace of microservices reflects an awareness that, in the march to build better and better digital experiences, developers and companies need a way to create and orchestrate data endpoints (read: APIs) that are easily consumable by any client, whether that client is a phone with a screen or a car with a voice.

If I put on my developer hat, I’m reminded there’s a reason these “-aaS” offerings seem to mushroom and die at such a terrific rate. Too often, particularly in the PaaS/IaaS histories, you see a focus on what I’ll call “dumb plumbing.”

As a developer, I don’t really care how many levers and dials exist for me to configure my infrastructure. What I care about is quick and easy access to backend services. The more the services, and the easier they are to get, the faster I can create the digital offering I want, and the better it’ll be.

I don’t really want “-aaS” offerings of any stripe. What I want are APIs. But more than that, what I really want are the means to build great experiences.

Read next: 5 ways to proceed with migration now that Parse is done