The simplest scenario for using a BaaS approach occurs when we create single page applications (SPA), or mobile apps that interact with services available in the cloud.
It's common to find applications wherein the authentication process is delegated to third-party services, using standard protocols (such as OAuth), persisting information in cloud databases (such as Google Firebase), or sending notifications via SMS services (such as Twilio).
BaaS can help us with several concerns out of the box so that we can deploy into the production environment without having to worry about the server or virtual machine of the application. In addition, BaaS also provides us with a whole infrastructure and nodes, such as the following:
- Load Balancer
- Database to store our data (NoSQL or RDBMS)
- Filesystems
- Queue servers
BaaS also takes care of the following requirements:
- Backup
- Replication
- Patches
- Scale
- High availability
On the other hand, BaaS has increased the birth of new products as services, including the following:
- Firebase: This provides us with features such as analytics, databases, messaging, and crash reporting
- Amazon DynamoDB: This key-value of the store is a non-relational database
- Azure Cosmos DB: This is a globally distributed, multi-model database service
With all of these changes and new tools, we have to embrace a new way of thinking and break the paradigms of how we build our applications. As serverless is a new technology, it is recommended to experiment, starting with using a small piece of an application. Think of three examples from your current applications that would be interesting to refactor using a serverless approach. Now, confer with your team and organize an Architectural Clash (http://architecturalclash.org/) workshop to identify whether or not your ideas are feasible.