This content is part of the Essential Guide: Essential guide to mobile application platforms

A discussion on mobile backend as a service: What developers need to know

Mobility is on the rise, and organizations need to determine how they will keep pace with new technologies. This Q&A takes a look at mobile backend as a service, an approach that could hold the key to today's mobile needs.

Mobile backend as a service (MBaaS) is, in essence, a set of pre-built APIs that are optimized for mobile and used by client-side developers without having to understand how to construct it on the server side. According to Cathal McGloin , vice president of mobile at Red Hat and the founder of FeedHenry, it allows developers to set up certain functions as reusable APIs in a microservices architecture that the client-side developers can use to find and use the APIs they want.

But while there is a strong value proposition behind this approach, surveys show that MBaaS has not gained overwhelming popularity amongst organizations. In this Q&A, McGloin explains why he believes it is not being utilized by developers and offers advice for those interested in leveraging MBaaS within their own organization.

A Red Hat survey indicated that more than half of organizations are still doing it on their own back-end integration solutions -- not using MBaaS. Is this because they're using some sort of other kind of cloud service or is it because they already have internal back-end systems?

Cathal McGloinCathal McGloin

Cathal McGloin: First of all, it's the maturity of the industry. If you look at the Internet when it first started, everybody built their own Web servers, and, eventually, a number of standards emerged and everybody stopped trying to build their own Web server and they just used off-the-shelf Web servers. We have the same thing happening here: MBaaS is a relatively new phenomenon. People didn't know what it was, haven't built it into their architecture, and so, we're really at an early stage of adoption of a mobile architecture, for want of a better word.

The other reason is that when people started with mobile, they tended to start writing mobile apps against existing Web APIs. So, they'd already built hardened APIs for the Web, and all they did was build a mobile app called a RESTful API, which is a very normal way of doing things. So, they built one app that utilized or had similar functionality to the Web app.

Where might organizations run into problems with this kind of approach?

The best apps are about the user experience and the user interface, and it's about reinventing a process.
Cathal McGloinvice president of mobile, Red Hat

McGloin: The problem arises in that this only works for systems where you've already hardened the API to be exposed to the public -- specifically, to the public network. Bear in mind that all apps running on phones, unless it's got some sort of VPN, are running over a public network. Now, those internal systems that I want to access from my app didn't get the five million investments in the services architecture to harden the API because I never envisioned 10 years ago that HR system would need to be accessed from outside the firewall. So, some APIs may already be mobile-ready in terms of security, but they may not be mobile-ready in terms of producing JSON data in the right format.

By and large, that is such a minority of the systems that the companies haven't got the proper architecture to be able to handle apps that were never meant to be accessed from outside the firewall. Only now are they beginning to realize, as they move from that first app to that second app, that they need to do something at an organizational level rather than these one-off solutions.

What kinds of problems do you see people running into in mobile application development in general that might be solved by mobile backend as a service?

McGloin: I'll give you a problem that I think people run into in mobile: They think that using the hybrid toolkit is a silver bullet for their UI problems. I think what a lot of novices have misunderstood is that UI and UX is still something that takes a great designer to do and that there's no tool that can solve it with a silver bullet. The best apps are about the user experience and the user interface, and it's about reinventing a process.

Rethinking a process is really what makes user adoption. What these tools do is they make them on an industrial scale, and they bring down the cost to build and support these kids of apps. But these tools don't, by themselves, create the best-looking app in the world.

What would you say are some key criteria for organizations that are evaluating MBaaS? What are must-have features and what kinds of criteria should they have on their evaluation list?

McGloin: Well, first of all, they should have the ability to support multiple developer toolsets and paradigms -- so building natively, hybrid, HTML5 and support all those different types.

Secondly, they should have a library of integration to back-end systems, because that's really where the hard work is: getting at the data that's in one of those back-end systems. So, they should have a library of components that simplify their getting the data out of those backend systems. Companies should ask, 'Does it have a flexible deployment? Can I start in the cloud, and then, later on, buy the on-prem version if I really need it behind my firewall?' They shouldn't try to think that they are tied into any one way to deploy.

What's your advice to developers for transitioning to mobile backend as a service?

McGloin: When developers build a connection to a back end, or they utilize one of the MBaaS features, they are saving themselves time and setting themselves up for that next app because they've done, for example, user authentication that's tied into their LDAP system. So, all of a sudden, they have one more key function they don't have to build, because they just go, 'Oh, here's the user authentication that the guys from the last app built. Now I can reuse that for this app.'

So, my advice is this: Since you can buy it as a service, don't have to buy a lot of licenses, can use just what you need, and can start for very little money, you should try it out and see. It's a great way to get your feet wet, and the proof will be really be in whether it helps them accelerate their development of that app and future apps.

And then finally, you want to future-proof this. Does it have concepts like containerization? Does it have concepts like microservices? Will it be still be leading edge in four or five years' time? Will the architectures that are chosen today scale? These are the things that I think developers should be looking at.

Next Steps

Take a look at out 2015 Mobile Guide

Learn more about the role of apps in an enterprise mobility strategy

Discover the link between MBaaS and legacy modernization

Learn how MBaaS has helped speed game development

Learn about the difference between cloud and open source MBaaS

Dig Deeper on Mobile app development