Serverless computing or Function as a Service (FaaS), a model first established by AWS in 2014 for the creation and execution of applications in the cloud, is increasingly becoming an attractive option in customer communications as well. The reason for this is the increasing share of transactional processing in document and output management.
Standardized batch jobs, in which hundreds of thousands of documents are collected and produced by deadline X, no longer exclusively determine what happens. Instead, companies, organizations and public authorities are increasingly dealing with a kind of defragmented customer communication on various analog and digital channels, which requires a high degree of speed and flexibility.
In other words, customers' individual inquiries must be processed quickly using their preferred media. Today, consumers want to be able to choose which channel they want to use to contact their insurer, their bank, their telecommunications provider, and their government agency. If, for example, he wants to read the message on his iPhone or his tablet - then the corresponding document is needed in responsive HTML format for optimal display. If, on the other hand, it is a sensitive or haptically valuable document such as the sales contract or the insurance policy, then print and thus classic letter mail certainly play a role.
What makes FaaS interesting for communications is that many document-related tasks are performed sporadically in companies. This means that the applications required to perform the tasks are only needed at certain times or for a limited period of time. One example is the standardization and migration of archives (often a consequence of mergers and acquisitions and the resulting heterogeneous IT landscape), where documents from different sources with sometimes very proprietary formats need to be transferred to a central archive and converted to the PDF/A format required for audit compliance.
Purchasing a completely new conversion software for this purpose (on premise) or via a cloud is certainly the easiest way, but not necessarily the most cost-effective. After all, costs are also incurred when the software is not used.
How nice it would be to be able to develop and deploy dedicated functions for such jobs on an ad hoc basis or as needed at peak times, without having to maintain your own resources (server, database, storage, etc.)! With the FaaS model, a corresponding application could be programmed as a microservice in a serverless environment, scaled according to the document volume and operated until all documents have been converted (example: archive migration). The service is then scaled down to zero. You only pay for the computing and storage capacities actually used, which the cloud provider makes available.
The following example shows how FaaS is used in communication. A telecommunications provider is confronted with the situation that customers repeatedly request itemized bills for their telephone calls. However, this only a very small percentage. Now, the service provider could produce and send such proofs for every customer across the board and the problem would be solved. But why produce them on spec when the vast majority of customers don't even need them? It would be better, because it would be more cost-effective, to generate these documents only for specific inquiries - but then quickly and without having to implement separate software for this purpose.
For this reason, the company developed a microservice based on FaaS, which can be used to create such itemized bills quickly and easily on demand. The DocBridge® Gear software developed by Compart is used for this purpose. It provides so-called reusable worklets that stand for very specific processes or functionalities and can in principle also be used as FaaS functions. The telephone data is retrieved from the specialist application via an ID (e.g. customer number or name), validated, formatted into a document and sent to the customer - either electronically or as a paper document.
There are several business scenarios like these in customer communication that can be implemented very well as FaaS processes or functions in a serverless environment. One need only think of classic operations such as formatting (creating) and converting documents, of outbound integration (connection to the interfaces of the corresponding communication channels such as mail, SMS, messaging, customer portal, archive, print spooler, etc.) or the integration of technical processes within business workflows (AWS Step Functions, Azure Logic Apps, etc.).
Here, a distinction is made between purely technical business workflows and technical workflows, which are understood more as individual steps. The FaaS offerings of the cloud providers now provide options for connecting a number of independent functions along a flow using (functional or operational) logic, similar to traditional business automation tools, but more lightweight and simple.
Vendors such as Compart are actively driving the issue and will offer more and more tools in the coming years that make it easy for customers to deploy and deploy in production technically meaningful and self-contained functions based on Compart technologies on the various popular serverless platforms offered by cloud providers, including Knative.
The technological means for this are available at Compart, and the first inquiries from customers in this regard have already been received. A central role is played by the DocBridge® Gear platform with the aforementioned worklets (low-code/no-code functions), which can be used as FaaS for typically small-scale processes within document and output management and can be combined to form any workflow.
The advantage: Instead of having to program this FaaS completely as code, it can simply be mapped as a worklet. In principle, a worklet can be generated automatically with DocBridge® Gear, "packaged" as a container and made available on a serverless platform (deployment).
The fact is that FaaS is here to stay in customer communications. However, the advantages and disadvantages should be weighed up carefully. FaaS are granular, dedicated functions that are only suitable for small, temporary specialist tasks. The more a company has to do with them, even sporadically, the more attractive the FaaS model becomes. In contrast, the FaaS model is not recommended for complex processes and stateful operations.
In addition, since the cloud provider makes many resources available, FaaS seems expensive at first glance. On the other hand, you save money because you only pay for the actual use. The question of costs is not easy to answer, because you always have to consider the personnel costs as well. The basic consideration should therefore be: How expensive would it be to develop and implement an application with your own personnel capacities, including the provision of middleware and hardware?
Another disadvantage with the FaaS model is the lack of control over low-level aspects, special optimizations and options, which are sometimes necessary but also costly. In any case, one should be clear about the general relationship with the FaaS provider. If you use the resources of a certain provider, the programmed code or the serverless function will only work there. An alternative to this cloud lock-in are neutral platforms such as Knative, which offer the same advantages as a FaaS environment, but with self-managed Kubernetes orchestration.
Serverless computing refers to an execution model in the cloud in which users create and execute applications without having to use their own resources (server, database, middleware, storage). In a sense, it is the most consistent form of cloud computing or the highest abstraction conceivable in this context. It is divided into three main categories by analogy with the familiar cloud services Infrastructure as a Service (IaaS), Platform as a Service (PaaS) and Software as a Service (SaaS):
However, since FaaS almost always requires BaaS, serverless computing is often used synonymously with FaaS. Applications designated as Function as a Service are very granular, dedicated functions that are only intended for a very specific process step or small, specific tasks - for example, in customer communication for generating and converting documents, generating barcodes or sending e-mails.
Although the name suggests otherwise: Serverless computing also needs servers. From the user's point of view, however, these are abstracted even further than would already be the case with a Platform as a Service (PaaS). For the developer, there is no need to interact with the API of the platform or to allocate or release additional resources. In other words: Users of serverless computing no longer have to worry at all about how servers are set up or scaled.
Instead, the service provider ensures that sufficient resources are always available for the respective application. This includes availability and fault tolerance. The most important providers include Microsoft with Azure Functions, Amazon Web Services with AWS Lambda and Google with Cloud Functions.
A major advantage of serverless or Function as a Service is billing according to actual consumption. Users do not have to pay for excessively booked or unused resources, but only for the computing and storage capacities actually used. Also on the plus side: simplified operation, so that developers can concentrate on their core competencies.
However, such FaaS applications can have a negative impact on performance: Unlike continuously running code on dedicated servers and in virtual machines or containers, providers can shut down serverless applications and reinitialize them only when needed. Depending on the startup time of the respective runtime environment, this can cause additional and undesirable delays. FaaS is also not suitable for all use cases, for example, not for stateful operations. Also, for high-performance computing, it can be more efficient and cost-effective to set up the required servers yourself.
The decision for or against FaaS is not least a complex one, in which costs naturally also play a role. In any case, the FaaS model is an attractive alternative to traditional cloud models with their monthly basic fees, which also accrue when the resources are not used.
As Chief Architect at Compart AG, I accompany the product strategy for customer communication from a technical perspective, with a focus on the interfaces between products and components, API governance, and the portfolio transformation from a traditional batch-oriented offering to a cloud-native and transactional world. I have over 20 years of experience in the areas of knowledge management, digital publishing, …
As Chief Architect at Compart AG, I accompany the product strategy for customer communication from a technical perspective, with a …