Cloud Service Brokerage: Enabling MBaaS for the Enterprise

API Evangelist Kin Lane has just released a new paper that provides an overview of the Backend as a Service space.  Kin’s research does a great job covering the breadth of tools and services that get lumped in under the BaaS/MBaaS category.  In the paper, he takes a closer look at what constitutes an MBaaS offering, and which vendors provide solutions.  To me one of the key takeaways in the paper (and from other reading about MBaaS) is that these services are all about agility, and about commoditizing APIs.  Just as OAuth eliminates the need to roll your own authentication mechanism, incorporating MBaaS services into your applications can allow you to focus on creating new features rather reinventing the wheel in other areas such as location or notification services.  This ties in nicely with the other work Kin has been doing, tracking Cloud Service Brokerage in the API domain.

Enterprise IT Concerns

Most MBaaS services aim to reduce the barriers to application development.  They’re intended to be easy to use, which includes being easy to adopt.  Some are “freemium”, while others use success-based pricing.  As a result, developers don’t need to execute purchase orders in order to start using them – they just sign up through a portal, click “agree” on some terms and conditions they probably never read, and maybe provide a credit card number.  This is similar to what happened when Amazon and other providers started offering cloud infrastructure — IT initially lost visibility into what was being hosted outside of the corporate data center because it was easier to go around IT than to use IT to engage with these services.

As I said in my last post, APIs will be the next wave of consumerization.  What I mean by this is that just as employees have gravitated towards the devices and cloud services that make them most productive, developers will do the same with APIs.  This will happen whether IT wants it to or not – their choice is to lead, follow, or get out of the way.  (The fourth option, blocking access to non-approved APIs is not likely to be successful, given the ever-increasing number of public APIs).

IT as a Cloud Service Brokerage

Rather than putting our heads in the sand or trying to fight the adoption of these APIs, there is an opportunity for IT to play a leadership role within the enterprise by establishing itself as a cloud service brokerage.  Just as IT shops are extending their service catalogs with SaaS and IaaS offerings, they should consider adding APIs that provide a core set of capabilities.  Done right, this adds value for enterprise developers by reducing cost and complexity.

First, consider the spectrum of public APIs – 9185 according to ProgrammableWeb as of this writing (but that will be outdated by the time you are reading this).  Even if we constrain this to MBaaS providers, Kin Lane’s paper covers dozens of those and there may be even more minor players out there.  By analyzing the landscape of MBaaS providers and framing their solutions in terms that the business can understand, an IT shop can remove a lot of duplication of effort among the developer communities that it supports.  IT can also work with their dev community to look at competing offerings and assess which one has best pricing and functionality.  Just as IT has helped their line-of-business customers standardize on enterprise software suites and cloud providers, the next opportunity will be to align APIs to improve interoperability across apps within the enterprise.

As more enterprise developers adopt MBaaS services for their apps, IT can also help to drive down costs by taking advantage of economies of scale.  Most API providers offer volume pricing — heavy users are charged less per API call than lighter users, except for the very bottom tier of developers who are just kicking the tires.  While any organization can reuse a single API key to pool their usage, an API management layer can provide finer-level detail and billing support.  An enterprise could, for example, assign internally-generated API keys to each developer registering to use an MBaaS API, rolling all of those up into the corporate API key before forwarding to the MBaaS provider.  This indirection provides visibility into how heavily each app is using the API, which could be factored into a charge-back model for the API’s consumption.  The benefit to the develop is that they have visibility into all of the APIs they’re consuming from a single IT-provided dashboard rather than having to look at a different portal for each API provider they’re using.

The API management layer also gives the enterprise’s information security office better insight into how these APIs are being used, and what data is being transferred.  Sensitive data can better be protected by enabling tokenization, data loss protection, or other policies on the API from within the enterprise regardless of what the MBaaS provider offers on their side.

Finally, as more competition emerges in the MBaaS landscape, IT can utilize competing offerings to provide a failover service for API calls (I covered this in a bit more detail in my previous post).  An API management layer allows IT to mediate between two APIs providing the same functionality.  If the preferred provider is down, it can be mediated so that it is interoperable with the second provider’s interface, and the response can be reformatted so it conforms to what the app is expecting.  This increases app resiliency without any additional app code being added by the developer – this benefit is amplified as more of the enterprise’s apps adopt the same core set of APIs.


Make no mistake: enterprise developers will be incorporating MBaaS and other external APIs into their apps.  Many are doing so already.  This can be a good thing, as it allows them to focus on providing new, business-specific functionality rather than getting bogged down in implementation of basic functions.  This improves time to results and adds value to the enterprise.

IT’s opportunity is to engage with their internal dev community early on and do what IT excels at:  procurement, provisioning, security/compliance analysis, and integration.  By adding MBaaS APIs to an internal service catalog, IT can demonstrate that it understands the landscape and has been proactive in onboarding the APIs that the enterprise needs.  By incorporating these external APIs into their API management layer, IT can also employ second sourcing and economies of scale to drive down cost while increasing app resiliency and reliability.

Additional Resources

As I noted above, Kin Lane’s Overview of the BaaS Space is a good place to start.  Our Mobile Middleware Buyers Guide goes into more depth about the API management layer as it relates to mobile app dev scenarios.

Travis Broughton

About Travis Broughton

Travis is an architect with Intel's Data Center Software Division. He has fifteen years of experience with Intel IT, working as an Enterprise Architect.

Comments are closed.