Mobile backend as a service (MBaaS) has developed as a means of creating a standardized architecture for linking...
many types of mobile devices to IT applications. As valuable as MBaaS is, questions about its use and evolution are important. First, what does MBaaS really mean? Second, is there a trend visible in the MBaaS space that shows where the concept is heading? And finally, will MBaaS be subsumed into another broader development trend?
The initial focus of MBaaS was as an extension to cloud computing to facilitate the support of a broad community of mobile devices. Cloud services -- databases in particular -- had to be made accessible to mobile applications, and features of modern applications like push notifications had to be delivered. Early mobile cloud users purpose-built all of their apps, meaning that there was no common approach and little consistency in features or capabilities. Worst of all, changes to support different mobile devices were difficult and expensive.
MBaaS platforms, largely from startups, created what could be categorized as the "back end of a front-end process." Basic cloud services could be incorporated in the MBaaS platform and exposed to developers in a consistent way, and features like push could be supported generically. These platform capabilities could then be made specific to the mobile platform or platforms to be supported. That means that an MBaaS application would sit between cloud tools in the back and BYOD-customized graphical user interfaces (GUIs) in the front.
MBaaS quickly polarized, with a cloud-centric consumer model and a developing hybrid enterprise model. When this separation took place, there was considerable hype around the notion that MBaaS would disrupt or destroy the mobile enterprise application platform (MEAP) model. There is no question that enterprise MBaaS is affecting MEAP thinking, but there's also no question that MEAP experience and practices are affecting enterprise MBaaS -- and MBaaS itself.
Three tiers of mobile architecture emerge as a standard
First, the notion of three tiers of mobile architecture -- GUI, MBaaS and back-end platforms -- is emerging as a standard for all MBaaS models, even those designed for consumers and for operation completely in the cloud. Vendors give different names and spins to these three tiers, but most now recognize them.
Second, the cloud is increasingly seen as one of several resources that the back-end tier of MBaaS can support. That means that cloud, hybrid cloud and data center application models -- MBaaS and MEAP, if you like -- are converging. In time, the cloud and enterprise mobile application models will certainly fully converge.
Third, MBaaS is taking on the appearance of a platform as a service framework, but a framework that has two distinct levels of application. MBaaS applications are built on what's becoming a standard set of platform APIs, and they are also built to create a GUI interface that's then a standard structure for building mobile-device-specific apps or browser screens. This application structure is increasingly important as mobile use increases, to the point that some businesses are already treating desktop application development as a special case of mobile development. The desktop or laptop is essentially a "nailed-down mobile device."
Some see mobile backend as a service as a component of PaaS
The emerging MBaaS model takes the MBaaS tier of the three-tier application structure into the boundary between a user-centric front end and an IT-centric application back end. That role is pivotal in hybrid cloud applications because it's usually the front-end (GUI) processes that are distributed and scaled to manage workloads. And MBaaS must then harmonize these multiple instances of front-end support into a manageable number of application threads that might be hosted in the data center or in the cloud.
It's not surprising that cloud software vendors, particularly PaaS vendors like Microsoft, see MBaaS as a component of traditional cloud PaaS. Recent mobile alliances -- Apple/IBM and Samsung/Red Hat -- are likely to extend this trend, and that extension will drive the greatest changes in MBaaS, generate the most competition and create the most risk for buyers.
Vendor and platform independence in MBaaS is an asset in that it allows developers and planners to shift underlying IT or mobile devices and have a common central agent harmonize their choices. However, there is no question that if MBaaS features are pulled into cloud PaaS offerings, the result will be more facile development of mobile-friendly and converged mobile and desktop applications. Users will have to assess their commitment to a vendor platform to decide whether MBaaS independence is a net asset or limitation.
Cloud providers like Amazon are also likely to expand their Web services in support of MBaaS missions, creating a cloud-virtualized PaaS-like framework. Just as Microsoft Azure would be a proprietary development framework that subsumed MBaaS features, so such a cloud offering would be proprietary and limit user mobility among cloud providers.
MBaaS unlikely to remain domain of startups
In the long run, it's unlikely that MBaaS will remain a domain of independent startups and cloud-advocating vendors. Already more users say they've adopted a major IT vendor's MBaaS, and the trend seems to be accelerating. Mergers and acquisitions are likely to consolidate the MBaaS field over time, as well, and the next several years may be tumultuous for vendors and users alike.
The tumult is familiar, though. There are many programming languages, many middleware frameworks and many cloud application models. MBaaS will end up incorporated into all of these, changing both mobile development concepts and development practices and planning overall.
Discover the link between MBaaS and legacy modernization
Find out how MBaaS has helped speed game development
Learn the difference between cloud and open source MBaaS