Almost every enterprise uses the cloud these days, and most of that use comes from cloud-based front-end portals designed to provide web or app access to legacy core-business applications. The applications are there already, and the goal is to make them accessible. But many enterprises are also looking at mobile apps that don’t have any specific connection to those legacy apps but still need some out-of-app processing. That’s the goal of an important and emerging topic, back-end-as-a-service or BaaS.
The cloud has created a revolution in the way enterprises interface with customers, prospects, partners, and even workers. It’s created a front end to legacy applications, limiting the impact of web-oriented and app-oriented technologies on the data center. The interest in web-and-app-based technology doesn’t always have a data center connection, so there may be no back-end system to connect with. That’s the point behind BaaS, which isn’t about moving the back-end systems to the cloud as much as about providing a back-end framework where there isn’t one already.
The most familiar BaaS are
Google’s Firebase and
AWS Amplify, which are mobile development platforms designed to create applications that live entirely within the cloud. The two form two pieces of what’s a kind of back-end continuum, the third piece being the data center. Where cloud applications are tightly coupled with legacy applications, as is usually the case for enterprises, the current front-end model applies. Where they are not, you need a BaaS. Amplify is probably the most flexible and sophisticated choice, and Firebase is best for BaaS applications that are simpler and involve less specialized processing.
BaaS typically handles things like authentication and analytics rather than supporting transaction processing. The databases used are thus static and are normally changed by simply replacing them with a new version. That can be done at any interval, in theory, but as the interval of updating increases because current information is critical, it’s likely that at some point it’s better to simply link to the legacy data center application that’s the data source and access it there.
A good example of a BaaS application is an app that lets remote users quickly validate basic customer information. If it were necessary to know the exact state of a customer account, this application would require access to legacy apps that are almost surely still run in the data center, so this would be a cloud front-end model. But in many cases, all that’s needed is to know whether the customer has an active account and the average activity that’s generated. In this case, it would be easy to load a simple customer database into the cloud and use BaaS to do the work. This is actually one of the main drivers of the growth in cloud database technology.
The big advantage of BaaS versus a link to the data center is the elimination of charges associated with pushing data in and out of the cloud when a single simple upload would suffice. That means the benefit will be greatest where there’s a lot of access to the BaaS data but not a lot of changes. The big advantage of BaaS versus a pure mobile app that doesn’t use the cloud at all is that the data needed is stored in one place.
This all-in-one-place approach is important for two reasons. First, all mobile users can share that single database, and if it’s updated occasionally from the data center, everyone will see the changes. Second, mobile users can use the database and other BaaS facilities to support at least a limited form of collaboration.
The database choices for BaaS vary, but they don’t have to be read-only. That means that worker updates, or even customer updates, to the database can be seen by all. Workers could use this to indicate they had customer activity in progress, for example, or simply wanted others to check with them regarding this customer. In most implementations of BaaS, they could also launch communications with a co-worker if they saw such an indicator.
With BaaS, it’s possible to build applications that look like traditional data center applications in that they’re shared among users but don’t involve the data center. As companies use the cloud more and more to build data center front ends, they’re likely to run into cases where BaaS would either be a more efficient way of supporting users of legacy applications or simply a way of building a new application.
That could be critical in cloud development because today’s enterprise use of the cloud tends to divide into the cloud-front-end-data-center-back-end model. BaaS opens a layer in between, and that new layer could be the key factor in a shift of applications outward, toward the cloud.
Right now, cloud architects don’t tend to plan for movement of applications from data center to cloud; the cloud is a super-GUI, and the data center is where transactions are handled. BaaS creates an intermediate strategy that you can see as an evolution of cloud apps that takes on a bit more processing responsibility. And even my example of customer account validation shows how easily we could transition from inquiring into a data center application for customer data into a BaaS validation database.
Enterprises haven’t paid enough attention to BaaS, and because of that they’re at risk of selling the cloud short. We’re not ready to move everything to the cloud, but we’re certainly ready to think about moving more, and BaaS may be the path we need to follow to make that happen.
