The Decision as a Function or DaaF, solves a big challenge of managing infrastructure for running decision services. Preparing servers (i.e., VMs), configuring security and required components, installing the service application, configuring the service application, enabling firewalls, exposing the service endpoint to the public, securing the endpoints, and so on… phew! And that’s not all, now on the pick time, you need to scale up and in the normal time you don’t want to pay for what you don’t use, so you need to scale down again… well, and then there are activities related to the patching and maintenance of the operating system (OS) and the rest of the components of it.
Serverless architecture is an approach to address this big headache. But designing and deploying your service application still is the operation activity for the DevOps and operation team. So updating your application, managing parallel versions, configuring patches and updates for your applications still remains! And that’s why some organizations look at SaaS solutions to not deal with any of these operation activities, and they just use the platform and perform the business activities that they care about. However, nothing is perfect; SaaS comes with some drawbacks depending on different situations, for instance, data governance and compliance challenges, customer data privacy, network latency, data transfer, and so on…
A Simple Decision Scenario
Let’s have a look at this scenario, imaging you are a domain expert (or business analysts) that is building a decision model to identify and classify people based on their age, whether they are infant, kid, teenage, etc. And you model the below decision table:
In FlexRule Designer, you can simulate and debug the rules, and have a look at the results to make sure, everything behaves as you expected.
As illustrated above, with a person with age of 20, your model classifies them based on business rules as an Adult.
Once you are happy, the next step is to deploy this model as a service, meaning all other applications and processes can consume this whenever they need to classify a person, e.g., a customer, user, consumer, etc.
The Decision as a Function or DaaF empowers you to deploy the model you build above as a service, so other applications and processes can consume it. Not only that, DaaF will mitigate many of the challenges and requirements that we explain at the beginning of this post as well.
You enter the cloud instance configuration for your Azure account and your press Publish. That’s it! FlexRule Designer will take care of the rest:
It will start a Background Task to deploy your model as a Function. You don’t need to worry about any other steps for integration to cloud SDK for building functions nor deployment activities. Everything is done for you. You can sit, relax, or continue your other tasks in the FlexRule Designer because this process is happening in the background and is not blocking you.
And voila! Your service is ready. Below is a screenshot of a Postman session communicating to the deploy, ready-to-use REST API service:
Benefits of Decision as a Function
We just briefly talked about DaaF and showed a very quick example of how it works, but there are more capabilities you can expect:
- Service version management
- Service discovery
- Service input/output metadata information
- Parallel versions availability
- Support for both transient and long-running decisions
- Support for both sync and async execution
In short, FlexRule take on DaaF enables domain experts and non-technical people to deploy their model as a service with just a click of the button. Organizations can empower SME teams to manage and build the whole services ecosystem for internal and external consumers. And Operation team can stop worrying about how to run and manage the services in up peak and down peak.
Published March 17th, 2021 at 02:06 pm