Anywhere buried in all of this, is there a warning for TWLO’s APIs? In other words, can a serverless model someone be used to make TWLO’s apis obsolete? …
I’m glad you asked.
Answer: Absolutely not. This is neutral for TWLO’s APIs, or if anything slightly positive as it decreases friction in using their APIs for cloud-only developers. If TWLO API services are used by a developer, whether the calling code is on a serverless platform or on hosted on self-managed infrastructure doesn’t matter.
Serverless platforms are about making it easier to create web and mobile applications, by not having to maintain your infrastructure and having tooling in the platform for monitoring and to communicate with the various tools you need to inter-operate with.
The front-end applications are already light. Web applications can be hosted. (They are nothing but static files.) Mobile applications are hosted by platform stores (Apple Store, Google Play). It’s the back-end that requires infrastructure. Systems to house intermediary APIs, and systems to house all the protected back-end services that API utilizes, like database engines or file systems. The old method required a large upfront outlay for server equipment for your data center, and then required ongoing maintenance and patching and monitoring from there.
First the cloud compute, and now these serverless platforms developed on top of them, eradicate ALL OF THAT INFRASTRUCTURE and just lets the software company focus on what they need to - make a software that provides a solution, instead of figuring out the mechanics of how to make it run and maintain it. It is so much simpler.
Serverless platforms are the new paradigm for SaaS development, and, IMHO, where the bulk of modern app development is heading. MDB w/ Atlas and now Stitch have strongly caught up to platforms that cloud providers have created and been strengthening for years.
https://firebase.google.com/
https://aws.amazon.com/amplify/
https://azure.microsoft.com/en-us/overview/serverless-comput…
These serverless app platforms aim to be a one-stop shop for developer, locking them into that cloud provider’s services.
MDB is different in that it’s aiming to be that but for just the data. You can use other tools for the rest (like TWLO). Stitch increases the flexibility – users can use whatever preferred platforms they want, hosted themselves or in the cloud. MDB is cloud-neutral, and can work with any single or combination of the providers as needed. That is pretty huge in that enterprises are favoring multi-cloud approach, so as to not have too much reliance on a single provider. Add to that my primary takeaway - MDB is differentiating itself from those cloud-provider serverless platforms in trying to work more directly with mobile databases.
-muji