MongoDB moves up the stack with backend-as-a-service platform Stitch
- Summary:
-
We speak to Sahir Azam, VP of cloud products at MongoDB, about how Stitch is aimed at making lives easier for developers.
As MongoDB World kicks off in Chicago this week, the key announcement coming out of the event is aimed at taking this philosophy further, with the release of a new backend-as-a-service platform called Stitch, which provides a uniform, document-centric API to database operations and service integrations.
Essentially it provides a more easy to use interface for building mobile and web applications, with direct access to the database, that pulls in standardised third party services, allowing developers to spend less time coding integrations.
Stitch sees MongoDB’s first attempt at moving further up the stack, a savvy move aims for it to enable to not only create further stickiness between developers and the database, but also provide a higher margin revenue stream for the company.
Ahead of the announcement I got to speak to MongoDB’s VP of cloud products, Sahir Azam, who explained the thinking behind the announcement. He said:
The goal of Stitch is really to make it much easier for developers to get out of the business of writing undifferentiated, boiler plate integrations, security coding, that goes into writing an application. Especially given that the majority of new, modern applications are really a composition of both custom code and third party services.
A lot of the work that goes into these new apps is just connecting things together in a secure fashion, writing the workflows of how these services communicate together, and we feel we can do a much better job of doing that in an automated fashion, allowing developers to focus on the part of the application that really differentiates the user experience.
A growing trend
Azam explained that MongoDB saw a growing demand for a backend-as-a-service product, of which there are already products in the market. However, MongoDB’s perception is that the current offerings available to developers also came with a number of limitations. Azam said:
What we saw was there was a really interesting idea here around saying, you don’t need to worry about your back-end, a single API to write to, an orchestration of services and workflows behind the scenes.
But what we also saw is a lot of limitations, meaning they obfuscated a lot of the power of MongoDB behind a sort of platform API and that ended up being limiting for many customers. Because it’s rare that an application is so repeatable or bound to only a certain set of use cases, that there isn’t still a need to go directly to the database.
As a result, MongoDB decided to build Stitch, it’s own backend-as-a-service solution, which focused on three differentiating factors from what was already available on the market, whilst making it suitable for mission critical applications. The first being access to the database itself. Azam said:
One [differentiator] is the fact that it is based and exposes the core MongoDB query language and doesn’t lock you into a platform API. So you can leverage all the benefits of a platform API that Stitch exposes, connecting a bunch of third party services in the database, but it doesn’t lock you into that. You can still get access to the underlying database for some custom functionality or something that isn’t necessarily available at the platform layer.
Secondly, security was front of mind when creating Stitch, as Azam believes that the other products on the market still rely too much on developers coding in what can be made available to whom, making it an incredibly complicated task. He provided the following example:
A lot of what we have heard from customers is that it’s annoying and complicated and error prone to have to figure out the robust sort of role based, access control structure that an end user application needs and have to layer that on top of any database.
If you think of a banking application - the customer of the bank would have all of the information about the account, the teller may have a limited set of information around a particular customer that’s allowing access, but they don’t have controls to change all that information, versus someone that’s doing analytics on aggregated information across particular branches.
Writing all of that into the middleware and front-end of an application is complicated and it’s error prone. So we have built in a very robust, role based, access control model, multi-tiered, that’s declarative in nature. So you basically define via rules who has access to which data in the underlying database and what they can do with it. That’s a much simpler model to enable than having to write all that code behind the scenes.
Finally, the other key component to Stitch is Mongo’s intention to pull together a number of key third party services, for which it will manage the orchestration, taking the pressure off of developers that spend their time writing specialist integration code.
At present developers can choose from a number of pre-built integrations with services that include Google, Facebook, AWS, Twilio, Slack, MailGun and PubNub. Additional cloud or microservices can be added easily using the Stitch HTTP service. Azam said:
If you wanted to build a new app, you would probably need to tie into some sort of a billing system, and send push notifications, integrate into social, potentially integrate into other cloud services.
A lot of the code we see developers writing is purely just connection and orchestration across those services. We’ve partnered with a lot of companies to build a set of third party services that are native. We are going to make that extensible that users can create and integrate others into the platform. And we will manage the orchestration and guarantees around those workflows, all behind a single API.
The outcome
I was keen to find out from Azam two key points about the thinking behind Stitch. Firstly, how does it see Stitch initially be being used? Is it simply going to be for lightweight mobile and web apps? Or can MongoDB see it be being used for mission critical apps? Azam believes it is perfectly feasible that both will occur. He said:
Certainly we expect that we will see a lot of net new, lightweight mobile applications, web services and such. There’s certainly an easy, obvious fit there.
But part of the reason we exposed and doubled down on two things - the extensibility to go around the platform layer, so to be not as limiting as some of the existing players are, and also the security angle - is that those were purely built with the idea of mission critical in mind, to be able to really scale up.
And secondly, what benefits does MongoDB envision Stitch bringing for MongoDB’s long-term strategy? Ultimately it’s about greater traction with the database and a higher margin revenue stream. Azam said:
We definitely think the fact that this is built on top of a database that already has a huge footprint, and it adds more value, and it pushes the market forward in a more modern way of development, and it exposes more developer productivity for the customer, will make MongoDB a more valuable and sticky platform.
But it also certainly helps on the margin side. I run the cloud side of the business and this adds very little additional cost at all for us to run, but it’s super high value and we certainly think we can monetise it. And it will drive more MongoDB usage as well.
My take
I’ve been saying for a while now that for NoSQL database providers to not become commoditised, they need to move up the stack and provide a more ‘value add’ proposition for customers. I believe that the providers that do this successfully, will be the ones that in in the long term.
