Should you use a backend-as-a-service for your enterprise mobile app?

Whether you’re creating a mobile solution for internal (enterprise) use, or a consumer-facing B2C app, one of the fundamental architecture questions you need to ask is whether to build your mobile back-end from scratch on your own — or use a mobile backend-as-a-service (MBaaS) provider.

Whether you’re creating a mobile solution for internal (enterprise) use, or a consumer-facing B2C app, one of the fundamental architecture questions you need to ask is whether to build your mobile back-end from scratch on your own — or use a mobile backend-as-a-service (MBaaS) provider.

Why do mobile apps need back-ends?

A few types of apps don’t need a “backend” — for example, a calculator app is self-contained and needs no back-end at all. But most apps depend on backend services of some kind. Backend services provide essential functionality to many mobile apps:

  • Storing preferences in a central location so users have consistent experiences on different devices
  • Storing documents in a central location to enable collaboration with other users
  • Displaying information and media not deployed with the app
  • Processing transactions (e.g. purchases, orders, communications)

Most users don’t think about web service layers underneath their favorite apps, but users do expect applications to be responsive. Backend services need to be scalable, reliable and able to deliver sub-second responses to many concurrent users.

Build your own backend or use a backend service platform?

In the mid-1990s, when the Internet was young, it was common for companies to build their web site using internal web servers racked in their own data centers. Hosting services weren’t yet ubiquitous, and web sites were built and managed much like any other business application.

Today it’s less common for a company build its website from scratch and host it on-site. Content management systems are now the standard building block for a web site, and external hosting providers generally provide higher levels of scalability and availability than most in-house data centers could at a fraction of the cost.

Backend services for Internet-connected mobile devices is beginning to follow the same pattern — even for enterprise applications. Backend services scratch-built as general-purpose web sites are giving way to specialized mobile backend service architectures. Much like web services, mobile backend services can be purchased and used on-premises, or built entirely on public cloud infrastructures in a platform-as-a-service (PaaS) model, or architected using a hybrid approach that blends both internal and cloud-hosted components.

Choosing the Right Option for your Project

As mobile services become more in demand, many providers are rushing into this crowded space. MBaaS offerings are available in an array of architectures — each one suitable for a different kind of application. Would your project be better served by a platform provider’s MBaaS offering, or by an MBaaS provider with a tightly integrated application development tool? Or something in between?

Understanding the different MBaaS segments is the first step in finding the best match for your requirements. Let’s consider the general categories.

General Purpose Cloud Platform Providers

If you’re an enterprise with a strong IT-led software design competency, the most comfortable fit may well be your cloud platform provider of choice. These providers include (but are not limited to):

  • Microsoft Azure Mobile Services
  • IBM BlueMix
  • Amazon Mobile Services (AWS)
  • SalesForce’s Salesforce1

These types of MBaaS providers offer mobile services as a part of a larger suite of offerings. They can provide not only mobile backend services, but other types of application services that can be leveraged as well to build large, comprehensive enterprise architectures.

If you have broader IT architectures to build along with your mobile project, a general-purpose provider with a strong MBaaS on offer may be an obvious choice. But even if you don’t need a broad platform today, the stability and future-proofing you get by using an experienced platform vendor are appealing.

On the downside, platform providers provide broad platforms that can be more complex to understand and learn to use. This shouldn’t be too surprising — platforms that have more knobs to turn, give more control to the application developer, and have more ways to meet the same requirements inherently have a steeper learning curve.

Mobile-Centric MBaaS Providers

If your primary goal is to support your mobile app — and particularly if it’s a narrowly-targeted consumer focused app — you might first consider a cloud provider that’s narrowly focused on its MBaaS offering. Examples of these include:

  • Parse (recently acquired by Facebook)
  • Kinvey
  • FeedHenry (recently acquired by RedHat)

There are advantages to using a provider like these. These providers are more focused on providing MBaaS services as their core product, whereas platform providers typically offer MBaaS as a feature of their overall portfolio offering. Developers without enterprise application experience may find that the more narrow product focus of these MBaaS providers leads to a lower learning curve for them.

On the other hand, mobile-centric MBaaS providers may not provide as much flexibility as a larger platform provider. For example, a mobile-centric provider may not provide a SQL-based relational database as part of the platform. Large, general-purpose platform providers like the ones typically would provide such an offering within their overall platform — as well as Internet of Things (IoT), Big Data/Hadoop, and cloud-based virtual machines that could be provisioned to support application requirements.

When looking at specialized MBaaS providers, bear in mind that they can be quite narrowly focused on specific mobile app segments. For example, Parse is more focused on delivering consumer apps, while FeedHenry is much more focused on the needs of internal enterprise applications.

As a final note of caution: the narrowly-focused MBaaS space has been recently characterized by frequent acquisition announcements. A few of these acquisitions have led to services being completely discontinued (perhaps the acquisition was to acquire engineers — not customers?).

Since your iOS or Android code will include APIs specific to your MBaaS provider, the last thing you want to do is migrate to a new provider on a forced deadline after an unexpected acquisition. In this regard, a general-purpose platform provider may provide more stability and predictability of long-term support.

Application Building Platforms

Each of the previous two providers types generally offer MBaaS services provisioned as web service layers to your application — but you still build your own application using whatever development tools you choose. This might be XCode for iOS, Java for Android, C# for Windows or PhoneGap for an HTML5 solution. You then use the MBaaS provider’s APIs to connect your application to their backend service layer.

App Building Platforms go much further, and provide not only the web service and data layers, but also a complete application development environment. These providers usually promise tools that let you code an application once (typically in JavaScript) and deploy it to all devices (either by cross-compiling to native applications or by running an HTML 5 app in a proprietary container). This approach promises tighter end-to-end integration between the front-end development and back-end development as well as higher levels of developer productivity.

On the other hand, using an App Building Platform to build and host your application would seem to provide the highest degree of vendor lock-in. Moving your application away from a proprietary development environment — should you ever decide to — would likely be a far more significant re-engineering effort than switching from one platform provider’s MBaaS layer to a new one’s.

Providers that provide this type of full application development and application hosting services include:

  • Appcelerator
  • Telerik
  • Host it Yourself

All of the MBaaS providers in the previous three categories focus on providing public cloud services to back-end customer applications. Some have no built-in facilities to integrate with on-premises services (e.g. Parse), while others have a fully-developed tooling to build hybrid cloud/on-premises architectures (e.g. IBM). What if you want a mobile backend, but for whatever reason none of it should be deployed in a public cloud?

Predictably, there are alternatives for enterprises that want or need to build and deploy their mobile infrastructures entirely on-premises. Some examples include:

  • IBM MobileFirst
  • Built.io
  • Kinvey

I previously listed two of these three providers above in the public cloud segments. In fact all three of these providers offer both on-premises and cloud offerings. The converse is not true, however. Most cloud-based MBaaS providers do not offer on-premises deployment solutions. So, if you know you must deploy on-premises, your options will be fewer (though still excellent!). Always know your constraints before selecting your technology!

Why use a mobile backend platform for on-premises deployment? Why not just crack open your favorite development IDE and build it yourself? The answer revolves around the trade-off between building every nut and bolt in your application stack — or using pre-built components as a way to avoid building and supporting so much complex code yourself.

Using a pre-built stack like IBM MobileFirst provides application deployment and monitoring, as well as pre-built web service integrations for all major platforms — right out of the box. Buying a backend service platform provides a lever to get a solution deployed faster and with higher quality than a completely build-from-scratch development strategy.

As always, deploying on-premises software involves higher up-front capital investment, requires more sophisticated infrastructure support resources in-house (or contracted from an external provider), and more hardware and network investment than cloud provisioning. Yet depending on how application partitioning, information security requirements and service dependencies fall, on-premises may be the best (or only) alternative when considering a mobile application deployment strategy.


Originally published at rekerrsive.ghost.io on February 8, 2015.

Author: Rob Kerr

Consultant and expert in software development for the iOS and Android platforms. Microsoft MVP Alumnus.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.