Anatomy of a Serverless InsureTech Suite

The podcast link of the blog if you like to listen.

In this blog, we will discuss how to build a complete InsureTech application suite using 100% serverless approach. Even if you are never going to develop an insurance application, it should make a useful read as the concepts apply to other domains. We picked InsureTech due to its high demand and, it is a reasonably complex use-case to cover all aspects of a serverless design. The entire code is available on Github under friendly MIT license. You can clone it and customize to your needs. You can run serverless code on GCP, AWS, Azure, private clouds or data center using the corresponding application server (also often referred to as the runtime platform).

There are mainly two concepts in the serverless development

• Models — metadata of the application such as data models, external service definitions, orchestration flows, security, UI screens specification.
• Serverless functions — for application behavior.

In this blog, we will go over the concepts and show a few examples of models and serverless functions. The Github links to a document site for the details.

Let us define the serverless for this discussion.

“Serverless application is the code which runs on a server but you don’t build the server. The code magically gets deployed on a pre-running server and starts to behave according to the coded logic.”

It means that there is an application server in the solution, but you don’t have to worry about the mechanics of building and deploying it. This approach allows you to focus on the core business problem. It also makes the problem modular, and the development becomes more agile and iterative. If the pre-running application server internally uses microservices, then your application automatically benefits from the features brought in by the microservice architecture such as clustering, elasticity, failover, etc.

Applications of the Suite

The InsureTech suite discussed here provides the following functionality.

Applications making up the InsureTech Suite

1. Online Quote to Buy Process: A customer can come to the insurance company website and, buy one or more insurance policies online.
2. Self Service Portal: The customer can later come to the website and manage the policies, submit claims, pay bills, change automated payment methods, create a support request, view or download policy documents, etc.
3. Insurance Admin: This is the application of the suite that lets the insurance company run its business. The employees of the insurance company use it. They use it for reviewing policies, make changes based on customer request, review/work on claims, receive payments, reconcile accounts, etc.
4. Analytics: This application is also used by the employees of the insurance company to generate various reports to monitor, track, and improve the business processes. For example, if a report indicates that when customers try to pay by credit card, payments fail frequently. It means that there is some problem in the UI or the server side logic. Another example, the claims are skewed towards a particular zip-code then it may lead to an internal review to find the root cause.
5. User Management: This is an application to manage the internal (employees) and external (customers) users’ accounts. In a mature organization, it may merely be a frontend to an existing user store or, cloud service such as Okta, Google Authentication or Cognito, etc.
6. Customer Support: It may be also mean integration with an external application. In due course, we will discuss a serverless case-management application.

Implementation Artifacts of InsureTech Applications

In this section, we will list the components of our serverless applications. In the following sections, we will go into the details of these and discuss each by pointing to the code in the Github. To keep it simple, we will focus on what, as an application creator, you have to do. The detailed documents linked from the Github page discuss how they come to life and mixes with a server running on the cloud. Since our suite is, by definition a customizable code, it may not be complete in some cases. Though it provides a solid foundation to start building your own custom InsureTech suite.

Serverless InsureTech Applications Components

1. Database Schema or Object Model: The database schema is the definition of all database tables, their columns, the relationship between tables. You can refer these as the object model or domain model. It also includes other metadata such as the definition of code-value pairs.
2. External Service Integration: Our applications integrate with several external services such as a credit agency, business verification service, Google Place, document generation service, payment service, email service, etc. We will discuss how we integrate with them in a serverless manner and make use of them in our application code.
3. Serverless Functions: The serverless functions are snippets of code or scripts that implement the application behavior. They can easily access database, external services, and library functions through an API toolkit. In the approach followed here, they have more straightforward development and deployment process than AWS Lambda or Google Cloud Functions (and other comparable technologies). They execute in the space of the server. Therefore, they do not require separate billing.
4. Orchestration Flows: The orchestration flows are a graphical and executable flow chart. The integration and long-running processes are primary use-cases of them.
5. Security: The server and model support security policies and Role-based Access Control (RBAC).
6. UI: Our serverless architecture exposes all four components discussed above as restful APIs. UI makes use of these APIs. Besides, our suite follows a declarative model for creating UI. The analogous of the serverless function on the UI side is a controller. In our model, the UI code is limited to — creating HTML for components, laying out them on a page and writing JavaScript controllers. The API calls, navigations, routings, and components layout can be specified declaratively or, using a graphical UI builder. One example of an API call is, say there is a serverless function called “createPolicy”. This function is exposed as a restful API. A UI wizard can collect user input required to sell an insurance policy and invoke “createPolicy” API. As a result, the function will run on the server. It will do all validations, interaction with other services and come to the conclusion of whether to sell the policy or not.

Non-functional Part of InsureTech Applications

You will be wondering what happens to the non-functional aspects such as security, tiering, database, database backup/ replication, failover management, system upgrade, application performance monitoring (APM), etc. In our serverless model, these are taken care of by the application server (which in turn uses microservices). This application server may be running on the cloud or in your data center.

Details of Implementation Artifacts of InsureTech Applications

In the following sections, we will get into the details of the artifacts listed above. We will point to Github and also show code snippets to co-relate concepts with the actual implementation.

Don’t worry about the very fine grained details when you look at the code. Simply, browse through it to co-relate with the concetps. When you are ready to clone the code and customize, the Github repo provides link to the documentation which gets into a greater details.

1.0 Object Model (Data Model & DB Schema)

The following diagram shows the object model. In our implementation, each class is equivalent to one or more tables in the database. Each class and its representation are specified using a JSON file. When the model is deployed on the server, it interprets JSON files and creates database tables, adds integrity checks (length, indexed, non-null, …). The server automatically publishes CRUD API, pagination API, getting and saving associated objects, retrieving object graph. Also, new APIs can be specified using the native language of the database (using SQL for an RDBMS).

The salient points of the above object models are:

• “User” buys a policy. During purchase, the user specifies email.
• If no “Account” exists with the given email, an “Account” is created. The first user is made its admin.
• “Policy” is associated with the Account. An account can have multiple policies.
• “Policy” is associated with “Note”, “Doc” and “Claim” classes.
• …

Review the JSON of the “Policy” class

To learn more about how the classes or database tables are specified in JSON, let us review the JSON of our “Policy” class shown below. Some details are as follows:

• “id” is the primary key and it is auto-generated.
• “parentId” is the id of the Account the policy belongs.
• There are other attributes (mostly omitted for brevity).
• At the bottom, you can see the associations. The spec is used to support API such as “get all notes given policy id”.
• Notice other meta-attributes such as “tableName” etc.
• You can view all other classes on this page on Github.

Policy Class Definition as JSON

Restful API

The server automatically publishes API for each table. These APIs are secure and published using security policies. For example, an API may or may not be permitted to be called by a UI client (or any other internet client). The following shows an example of a “save” API auto-generated by the server and published as a Swagger document.

Table Save (Insert / Update) as Restful API (Swagger Document)

API using Joins of Multiple Tables

You can create an API requiring joins of multiple tables, grouping, ordering, etc by specifying its SQL template. A SQL template may also be referred in the pagination API. The following is an example of one such API.

API Created using SQL Template

Conclusion: For a complex domain like InsureTech, we can specify entire object model in a declarative style (as JSON). It can be deployed on a running server which can interpret it and create DB schema. As the data model changes, the tables are altered to reflect the changes. The server also publishes database operations as restful APIs. An API using SQL statement can be created by specifying in JSON.

2.0 Using External Service

The server has an API Gateway Service as a part of its cluster. This API Gateway supports integration with external services. A service can be imported into the application by merely adding its Swagger file and its definition in a JSON file (security settings mainly). If the service uses OAuth2, the API Gateway transparently manages the life cycle of tokens (“access-token”, “refresh-token”). The server, in turn, publishes API like any other Gateway. Besides, the external APIs become available as callable methods and can be invoked from the serverless functions.

External Service Definition for Integration

The following is an example of an external service, which can be added to the application through its definition in a JSON file. Several attributes are masked as they would have values corresponding to your subscription of the service.

Service Specification as JSON File (with Security Credentials)

Example Swagger File for the External Service

The following is an example of the same service’s APIs as Swagger document. The swagger document can be added as JSON or YAML file.

External Service API Document as a Swagger File

3.0 Serverless Functions

So far, we saw how to create a database, access it, integrate external services, and access them. The next comes how to implement the application behavior, which will make use of several of these services and also specify a control flow. As an example, in InsureTech, policy creation is more than saving a record in the database. It may require to execute the following logic:

• If the “Account” exists for the specified email then retrieve its “id”, else create an account.
• Crate the “Policy” and associate it with the “Account”.
• Create a “Bill” for the policy.
• Invoke the payment service to complete the payment.
• Save “PaymentMethod” for future use.
• Invoke Document service to generate policy document files.
• Associate “Files” of documents with the “Policy”.
• Send email to the user with a link to access the portal.

The following example code would help you co-relate how serverless function is written for the above logic.

A Serverless Function Capturing Policy Creation Logic

Invoking Serverless Functions

A serverless function can be invoked as an API using HTTP post. The body of the API call is passed to the function as a parameter. Another serverless function can also invoke a serverless function. A serverless function can be long-running and suspend its execution while waiting for an external trigger. The execution of a serverless function can also be scheduled.

Conclusion: Complex logic can be written using serverless functions. These functions can make use of external services and database operations using methods provided by a toolkit library. A serverless function can be invoked remotely, by another function. It can be long running and scheduled.

4.0 Orchestration

An orchestration flow is like a Serverless function but expressed graphically. Like a serverless function, the orchestration flow can be long-running and can also be scheduled. The detailed documentation covers them in detail.

5.0 Security

The server supports Role-Based Access Control through security policies. A set of roles and group are created. A user is assigned one or more roles and groups. A policy is created using roles, groups, and rules (specified as serverless functions). The security policy is assigned to one or more resources. If the user’s and policy’s roles/ groups intersect and rules are validated, the user is granted access. A user in this context means a person as a user or an automated client. The resource can be very granular such as — a table, attribute, endpoint, etc. For example, only a system user (automated client) with “Payment” role can read the credit card number. It ensures that the credit card number is opaque to all other users.

6.0 UI

The backend described here can be used with any UI. Our InsureTech suite provides a fully functional UI. The UI provided with the application is low-code, it relies more on the declarative model. Therefore, it is easy to customize. Since UI is a big topic in itself, we discuss it in a separate blog.

Blog — How to Build Customizable InsureTech UI

Final Conclusion

In this blog, we demonstrated the concepts required to build a backend of InsureTech suite. Our backend engine is serverless. It exposes APIs. Any client (UI, phone applications, other services) can use it. We have made the entire source code available under MIT license. Hope that you build your InsureTech application by following the documentation.