As enterprises grow more comfortable with cloud-based services, many are turning to mobile backend-as-a-service (MBaaS) solutions to help them quickly build apps that draw on their datasets. As a result, they are also finding they need to better manage their data collection and storage using a database-as-a-service (DBaaS).
So what is driving this adoption of cloud-based services for the enterprise? How does an enterprise choose between using an MBaaS and DBaaS? Is this even an EITHER/OR decision to make, or how can an enterprise complement their MBaaS with a DBaaS offering? We checked in with a couple enterprise-specific MBaaS providers, and our own CTO, Ian Plosker, to look at best practices for how an enterprise can manage the data that sits behind their newly-created enterprise apps.
Enterprises Using Cloud Services
Traditionally, enterprises have been cautious about using cloud-based services to manage their operations. Fear of security risks and inconsistent access to cloud-storage have combined with IT-heavy systems leadership that is more comfortable with managing system architecture internally. However, disruption of many markets across-the-board, and the explosive proliferation of mobile devices amongst an enterprise’s workforce, have made the cloud more appealing.
Some of the drivers influencing enterprise uptake of cloud services are:
- Increased mobile usage amongst enterprise workers who need access to a company’s data remotely
- The need to decouple services to allow for the composable enterprise: more businesses are enabling access to specific data or service capabilities so that these functions can be ‘plugged in’ to the business customer’s supply chain
- Growing trust in the security capability of the cloud
- Outsourcing of non-core business roles (by using cloud-based services) to reduce management and resource costs
- The need to develop new products and services quickly in order to compete with nimble, innovative start-ups.
This is bringing a proliferation of acronyms that all end in “as-a-service,” and in turn is creating some confusion. We’re often asked if we’re a MBaaS, for example. While we are focused on DBaaS, we are complementary to MBaaS, and play particularly well alongside service providers that offer a fast-track to full stack mobile app development.
What is MBaaS?
MBaaS provides developers with access to full-stack development without needing specific technical skills. Everything from the backend server to the front-facing user interface can be built together using components of an MBaaS system, thus speeding up development time quickly. An enterprise may want to quickly develop a conference app for example, for their event delegates, or create a simple CRM app that their mobile sales agents can use while on the road.
A MBaaS system can walk developers through the development and deployment of an app quickly, without the developer necessarily needing to know everything about backend servers, caching, security protocols, or other technical specialities. MBaaS services like AnyPresence and ClearBlade have also addressed enhanced security needs, so that enterprise data is secure when being routed through an MBaaS-created app.
How Enterprise DBaaS and MBaaS can work together
Many MBaaS vendors offer a simple database within their service offering. But enterprise customers must have data residing in multiple databases as various as monolithic, traditional relational data systems, to NoSQL databases and even excel spreadsheets. Rich Mendis, Co-founder and CMO at enterprise-focused MBaaS AnyPresence, explains how he sees the connection between DBaaS and MBaaS:
The way we look at the space is that there are a number of components that come together in an end-to-end app. There is the data layer (the data sources), then the backend that takes those data sources and creates mashups, then the user interface layer. We view DBaaS as a data source for MBaaS. For an enterprise, there will be multiple data sources: legacy systems, and cloud-based systems. DBaaS can help with quickly setting up a cloud-based system to persist data to prototype.
While AnyPresence, like most MBaaS, offers some database functionalities, Rich sees a role for enterprises managing lots of data to use a DBaaS solution, and then linking that data to MBaaS when creating an app. “This is very much a complementary service,” he said.
Aaron Allsbrook, CTO at enterprise-grade MBaaS ClearBlade agrees:
ClearBlade’s ClearData offering has a built-in datastore – we use Cassandra – but it really doesn’t matter from the MBaaS users perspective. What we have done is to provide a generic interface to all of your data, no matter where it comes from. This means that a collection of data defined in our platform may be in our Cassandra instance, or it may come from a customer database. This can all be done within the context of a single app. Our backend handles the connection pooling and such associated with making that type of behavior performant. Today, we target enterprise databases like DB2, but its a straight forward and repetitive task for us to bring in something from a DBaaS as a possible source.
Enthusiastic about the potential of using DBaaS and MBaaS together in the enterprise, he continues:
The pairing of the DBaaS gets exciting when you see that together they allow an organization to potentially keep their deep DBA mastery and tuning while also getting cloud flexibility and support. The MBaaS abstraction then allows the developers to build agnostic of the underlying data store wherever it resides.
Our CTO Ian Plosker explains one of the greatest benefits of using both a DBaaS and MBaaS offering together:
Orchestrate keeps your data disentangled from your MBaaS vendors. This is particularly useful for enterprises where data may be being used for multiple purposes across the organization. It doesn’t make sense to store the data inside a backend service, or to replicate it there, necessarily. By linking the Orchestrate API to the MBaaS, data management is simplified, while still providing sophisticated access to all the power that database searches can provide. Query types with MBaaS are also pretty limited. MBaaS are focused on speeding up initial development. They get you up and running quickly but as a result, they miss things like powerful, full-text search.
Aaron from ClearBlade adds:
To my knowledge, most of the MBaaS solutions are working to abstract away the direct database interaction by putting an API layer on top of a built-in DB that lives underneath them. Mobile developers don’t love learning the nuances of databases, and its a feature to NOT be working with them directly. Obviously, the layer of abstraction has the potential to both greatly simplify the development, but also reduce the database offerings to their lowest common denominator of function.
Choosing an MBaaS provider to work with Orchestrate API
Enterprises should look for the best fit between an MBaaS provider and DBaaS solution. Aaron gave us his thoughts:
Off the top of my head, things I would consider when looking at a DBaaS and MBaaS working together are:
- Ability of the MBaaS vendor to integrate with the DBaaS offering
- Can the MBaaS adequately provide Access Control against an external data source?
- Ability of the MBaaS and DBaaS to run in the same cloud vendor.
His checklist for choosing a DBaaS provider mirrors some of the key strengths of Orchestrate:
When selecting the DBaaS I would also differentiate them based on criteria that were not affected by an end developer, that is:
- Data Security and encryption needs
- Costs and how they scale.
AnyPresence’s Rich Mendis focuses on the pricing advantage of DBaaS solutions like Orchestrate:
MBaaS vendors predominantly charge for database storage by size of database, so a DBaaS could be economical if I am storing a lot of data but it is low-usage.
Our CTO, Ian Plosker, points to a key feature that both AnyPresence and ClearBlade offer – a commitment to data access.
The key MBaaS feature to look for is the same as for any SaaS vendor: The biggest concern is data lock-in. Many cloud-based services will let your business collate and store data but make it difficult when you want to transfer to a different service or download, often only providing data in a cumbersome CSV file. With Parse, for example, businesses tend to outgrow the service but it is very difficult to move away from it. You need to ask who owns your data and how easy is it for you to opt for something else.
An example data architecture model: MBaaS and DBaaS working together
To illustrate how MBaaS and DBaaS might work together to quickly create a customer-facing app, while drawing on multiple datasets stored in a database-as-a-service, Ian shares an example of building an app that would give you restaurant suggestions based on your friends’ suggestions.
This might draw on your given location, identify restaurants and check your social media networks to see what your friends are saying about nearby venues. However, even such a simple app would take at least four databases and can be impossible to do in most MBaaS solutions. You would need to do a geo-search query to get the current location coordinates of the app user. Then you might search a collection of places to identify, say, all the Italian restaurants in the area. Then you would use a contacts collection to identify all friends of the app user. Then, you would conduct a query on a time-ordered collection of data to see which friends have also checked in or liked restaurants in the collection of places.
You can see how quickly a sales app for mobile agents in the enterprise might quickly become difficult if relying on real-time data from a suite of datasets across an enterprise’s data architecture.
This can get really unpredictable if you are doing it in MBaaS, or if you don’t want your users to experience the latency effects of using Facebook social graph directly, for example. You don’t need to let your MBaaS be limited by search. You can use MBaaS for where it is strongest. For example, you could use it when you live in your own world of local data. If the app user then went on to say they liked that Italian restaurant, that data could be saved within the MBaaS app’s database, and it only goes back to Orchestrate when doing that larger social querying. It is like an app of curated data, like a yellow pages business directory. MBaaS could store your business likes and dislikes, or notes within the app and within the MBaaS database. That would let you build the application quickly. But you can then transfer that data stored in MBaaS to Orchestrate when it is time to add new features, or you need to link those notes and personal likes to a wider CRM database for the business, for example.
As companies take more advantage of cloud-based services that help them develop products quickly and outsource service components that are not core to their operations, MBaaS usage in the enterprise will undoubtedly grow.
Being able to complement MBaaS with DBaaS enables faster product development, while also ensuring complete data control and access to sophisticated query design and data search capabilities.