MongoDB's new Stitch service is another approach to delivering serverless compute, but with one big difference: it's got state.
Most serverless computing implementations are stateless: they spin up in response to a trigger and once the function they host has run, they're deleted. There's no need to store state from instance to instance, as they're just part of an overall application. That doesn't stop you storing state elsewhere of course, using tools like Twilio's Sync or a document database.
Sahir Azam, MongoDB's VP of Cloud, describes this as part of an industry trend towards platform services and that "the database is part of delivering developer productivity".
It's an important point, as much of what we build depends on an effective store, and NoSQL document databases like MongoDB provide a flexible schema-less store that's easy to integrate with JSON-based RESTful APIs. Using Stitch as a database-native backend makes a lot more sense in that light, and Azam describes it as "non-disruptive; it gives you a RESTful interface to existing databases with access rules in just a few clicks."
It's an approach that gets you going quickly, especially if you're already using MongoDB. You can quickly migrate existing databases to the Atlas cloud service, point apps at its endpoints, and then add calls to appropriate APIs via webhooks.
Using Stitch's workflow tools you can then build an appropriate workflow for your app, giving you a single surface to work against. You're not limited to Stitch, as Azam notes: "You can call out to other services like AWS Lambda, getting and using results".
There's also a hybrid option, using Stitch in the cloud to handle application calls, and then replicating data back to MongoDB instances running in your own data center for additional analytics. An upcoming update to MongoDB will add new in-database analytic capabilities, with built-in visualisations. You'll be able to quickly build local dashboards to show just what users are doing with your application, giving you a near real-time view.
As more and more cloud-hosted tools make the transition to platforms, it's becoming clear that this is the natural state of the cloud: a developer-centric environment where open APIs have made it possible to have interacting functions and services that can be combined with your own business logic to build complex applications. Why should you have to worry about the underlying infrastructure when data center-scale operating systems like Kubernetes handle scaling and scheduling for you?
Where MongoDB's offering differs from others is its cross-cloud option. You'll be able to stand up an instance of Atlas in AWS, in Azure, and in Google Cloud. With multi-region replication to reduce the risk of downtime, you're going to be in the position of being able to keep services running in the event of downtime in both regions and clouds. An added benefit of this approach is the ability to take advantage of public clouds' data sovereignty features: for example, you'll be able to keep data on multiple Atlas instances without having to leave Germany.
Azam notes that there's a lot of complexity in managing databases across multiple clouds. They all have different virtual infrastructure requirements and different platform services. Having a single provider for cross-cloud services makes sense, as Azam says "we abstract away a lot of the nuance under each cloud infrastructure". Having one billing partner also makes sense.
The longer term aim is what Azam calls "a global intelligent database" based on Atlas. Unlike other global database services, such as Microsoft's CosmosDB or Google's Spanner, it'll be one that builds on Atlas' cross-cloud capabilities. Azam describes it as building on existing building blocks, "with a click of a button, a global scale application still working on the MongoDB platform". That approach ties in to new features that will be coming to MongoDB, including change streams for real-time uses and enhancements to the database's own query language. A three-weekly release cadence for Atlas should see many of these new features roll out quickly.
Change streams are likely to be an important part of Stitch-based applications too, as they can be used to notify and trigger actions based on changes. Instead of driving the database from Stitch, the database will drive Stitch.
By building on existing cloud platforms with dedicated instances, Atlas is able to take advantage of the growing scale of the public cloud. As AWS grows, for example, Atlas can grow, adding regions and geographies without MongoDB needing to do anything. With a multi-cloud approach, it can also take advantage of different clouds approaches to different geographies.
Turning database as a service into platform as a service makes a lot of sense. It'll be interesting to see what MongoDB's customers do with both a multi-cloud Atlas and Stitch.