Serverless computing or Function as a Service (FaaS), a model for creating and running applications in the cloud first established by AWS in 2014, is quickly becoming a popular option in customer communications. The reason for this is the rapidly rise of transactional processing in communication and output management. Standardized batch jobs, in which hundreds of thousands of communications are composed and produced by deadline X, no longer are the mainstream answer to customer communications. Instead, companies, organizations and governments are progressively shifting towards defragmented customer communication on variety of 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 communicate with their insurer, their bank, their telecommunications provider, and their government agency. If, for example, the consumer wants to read a message on their iPhone or tablet - then the corresponding document is needed in responsive HTML format for optimal display. If it is a sensitive or valuable document such as the sales contract or the insurance policy, the consumer may prefer print and thus classic mail delivery service is employed. Bottom line is that in order to build trust and maintain loyalty, today’s consumers demand messaging that is personalized, timely and relevant to their needs.
Reading time: 6 min
Many document-related tasks are performed intermittently in organizations. 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 unification and migration of archives (often a consequence of mergers and acquisitions and a resulting heterogeneous IT landscape), where documents from different sources with sometimes proprietary formats are 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, but not necessarily the most cost-effective approach. After all, costs are also incurred when the software is not used.
Wouldn’t it be ideal if you could develop and deploy dedicated functions for such jobs on an ad hoc basis 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 to zero. Payment is made only for the computing and storage capacities actually used, which the cloud provider makes available.
The following example shows how FaaS can be used in communications. A large telecommunications provider is challenged with the situation that some customers want simple summery billing while others request itemized bills accounting for all of their activity. However, this only accounts for a very small percentage of users. Now, the service provider could produce and send such itemized billing to every customer, but they wouldn’t be meeting the needs of the summary users. It would be better, because it would be more cost-effective, to generate these documents only for specific inquiries, or users - but then quickly and without having to implement separate solutions.
To solve the problem, the company developed a microservice based on FaaS, which can be used to create such itemized bills quickly and easily on demand. DocBridge® Gear automation and workflow software developed by Compart is perfect for this. It provides so-called reusable worklets, which represent very specific processes or functionalities and can be used as FaaS functions. The itemized telephone data is retrieved from the governing 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 in customer communications that can be implemented efficiently as FaaS processes in a serverless environment. Just think of classic operations such as formatting (creating) and converting communications, 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 (business or operational) logic, similar to traditional business automation tools, but more lightweight and simple.
Providers such as Compart are actively driving this approach and will offer more and more tools in the coming years that will make it easiery to deploy technically meaningful and self-contained functions based on Compart technologies on the various common serverless platforms of cloud providers, including Knative. The technology exists at Compart, and projects are already being implemented. A principal 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 communications and output management and can be assembled into 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 carefully. FaaS are granular, dedicated utilities that are only suitable for small, specific or temporary tasks. The more a company has to do with them, even sporadically, the more attractive the FaaS model becomes. For complex processes and more-permanent operations the FaaS model may not be ideal.
Additionally, since cloud providers makes many resources available, FaaS appears expensive at first glance. On the other hand, ultimate savings exist as each situation is unique. The question of costs is not easy to answer, because you always have to consider 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 particular provider, the programmed code or the serverless function will only work there. An alternative to this so-called cloud lock-in dependency relationship are neutral platforms such as Knative, which offer the same advantages of a FaaS environment, but with a self-managed Kubernetes orchestration.
Serverless computing refers to an execution model in the cloud in which users create and run 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 referred to as Function as a Service are very granular, dedicated functions that are only intended for a very specific process step or small, concrete 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 only reinitialize them as 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 (for more on the difference between stateful and stateless applications, see Glossary). Also, for high-performance computing, it can be more efficient and cost-effective to set up the required servers yourself.
Other disadvantages:
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.
Knative is an open source project whose development has involved numerous companies such as Google, IBM, Red Hat and many others. It is a platform for the realization of serverless, cloud-native applications. Knative was first officially unveiled by Google in 2018.
The platform is based on the Kubernetes container orchestration software. It extends this with various functions that can be used to deploy, manage and operate serverless applications. These include the following functions for
Microservices packaged in containers form the basis for the realization of cloud-native, serverless applications. The containers orchestrated with Kubernetes can be operated on any environment. For the serverless application, it does not matter whether the containers are operated in a cloud environment, in a service provider's data center or locally on premise. The various container units are combined into clusters, which consist of physical or virtual nodes and operate in master-slave mode.
The advantage for developers is that they can concentrate entirely on writing the program code and do not have to worry about provisioning and configuring an infrastructure or individual servers and containers. Since containers are almost arbitrarily portable between platforms and environments, there is great flexibility in deploying serverless infrastructure. The benefits of container technology and the serverless application model are combined in the Knative platform.
Other advantages:
Source: Cloud Computing online, June 2020
DocBridge® Gear is a platform that allows all document creation, conversion, modification and output processes to be configured in a customer-specific and simple manner. Typical quality assurance processes (document review/comparison, validation, release workflows, etc.) can also be modeled.
The basic principle of DocBridge® Gear is the use of reusable, so-called worklets, which stand for very specific granular functionalities and sub-processes. Due to their structure (low-code/no-code function), these worklets can also be generated as Functions as a Service (FaaS) and operated in a serverless environment. One advantage is that no complex code programming is required for this. The business logic is automatically stored in the worklet.
Other advantages:
DocBridge® Gear is primarily aimed at companies that deal with omnichannel communication and are looking for a solution to seamlessly integrate various business applications.
More about DocBridge® Gear
Modern applications and legacy applications have one property in common, namely whether they store state or not. Whether you are dealing with monoliths or microservices depends on the needs of the application. Some need to store state (user behavior), while others don't need to care.
So-called stateful applications store the state of client requests on the server itself and use that state to process further requests. They use a database to store data as a backend, but the session information itself is stored on the server. When a user sends a login request, they can log in and the user is authenticated, and on the second request, the user sees the dashboard. Stateful applications do not need to make a second call to the database because the session information is stored on the server itself.
So the advantage of these types of applications is higher processing speed. But they also have disadvantages. For example, in stateful applications there is usually a load balancer (LB) behind which there are two servers running the same application. The first request to log in goes to server 1 and the second request might go to server 2; now, since only the one server has logging in enabled, the user won't be able to log in when the load balancer sends the request to the second server. So it is not possible to scale stateful applications horizontally.
Stateful applications, on the other hand, do not store the state of client requests on the server, but only in a database. This in turn is stateful, i.e. it has a persistent memory.
Typically, a user requests a login with credentials, one of the servers processes the request, generates an auth token, stores it in the database, and returns the token to the client at the front end. The next request is sent along with the token. This means that no matter which server processes the request, in each case the token is matched against the information in the database and the user is granted login. Each request is independent and has no connection to previous or next requests, just like REST.
Although stateful (stateless) applications have additional overhead from calling the database, these applications are surprisingly scalable horizontally, which is critical for modern applications that can have millions of users.
Both stateful and stateless are ubiquitous today. But modern software is usually developed as stateless because, unlike stateful applications, it can scale horizontally - an essential criterion today for the use of microservices in cloud environments, among other things.
The eight main differences between stateful and stateless applications are:
1. Working state: stateful applications respond according to the current state, while stateless applications act independently considering the previous/next request.
2. Stored data: If the web server stores data in the backend and uses it to identify the user as an always connected client, the service is Stateful. Whereas in Stateless, the server stores data but in a database to verify the user/client whenever it needs to connect.
3. Reaction towards clients: In Stateful, the server thinks that the client is just a dumb machine, while in Stateless, the server thinks that the client is an intelligent machine that does not need to depend on any state on the server side.
4. Requests: in Stateless, requests are self-contained, i.e. everything is contained in the request and is processed in two separate phases. ("Request" / "Response") In Stateful, requests are always dependent on server-side state.
5. Generated State: When browsing the Internet, the state is generated and stored somewhere. Although in both types this user behavior is generated when stored on the server, the server generates a session. This is called a stateful application.
6. State stored: when the client's behavior is stored, it generates some data that is used for further requests, although technically it is stateful because it refers to a state. But the state is stored by the client, so it is called stateless.
7. Cookie stores: On the client side, the cookie stores authentication data. On the server side, it creates temporary client data or stores it in a database (this is the typical case). When the user returns to the dashboard to make another payment, it is a cookie that is stored in the browser and establishes the state with the server.
8. User base: Stateful is past when there were monoliths and no dynamic user base. Stateless is future as microservices are around and mostly communicate via REST interfaces and everything is scalable as no state is stored.
Main advantages of Stateless
1. Removes the overhead of creating/using sessions.
2. Scales horizontally for the needs of modern users.
3. New instances of an application are added/removed as needed.
4. Enables consistency across different applications.
5. Statelessness makes an application more convenient and maintainable.
Additional scaling and performance benefits of stateless applications:
1. Reduces memory consumption on the server side.
2. Eliminates the problem of session expiration - Sometimes expiring sessions cause problems that are hard to find and test. Stateless applications do not require sessions & and therefore do not suffer from these problems.
3. From the user's point of view, statelessness allows resources to be linked. When a page is stateless, it ensures that when a user links a friend to that page, the user sees the same view as another user.
Source: Gursimran Singh, Home Healthcare Report, October 2020
