First, what is FaaS?

Functions as a Service (FaaS) have gained immense popularity as a means to design elastic and scalable applications on public clouds. FaaS is a micro-services pattern of designing and deploying cloud applications from building- block functions. Here, users provide the logic of a single stateless function to a cloud provider along with its dependencies. This is packaged using a serverless computing model, typically encapsulated as a container, deployed on the cloud, and accessed from a service endpoint. Any invocation of this endpoint automatically triggers the creation of a container for the function with its dependencies, if an idle instance does not exist. Once the function executes and the response is returned to the client, the instance is retained for a short timeout period, and if no further requests arrive, it is spun down. Instances are automatically created if the function gets concurrent requests, and shrunk during low-demand or idle periods.

FaaS Providers

FaaS is offered by all major cloud providers as a platform service:

• Amazon AWS Lambda functions

• Microsoft Azure Functions

• Google Cloud Functions

• IBM Cloud Functions

Opensource projects like OpenFaas and Knative are designed for use in private clouds

How are functions built and used?

Cloud providers also provide basic capabilities to compose these functions into workflows to design practical and complex applications using the FaaS paradigm.

FaaS functions can be composed as a dataflow by defining a Directed Acyclic Graph (DAG), either visually or programmatically, and deployed for execution.

Internally, these workflows use cloud queues to exchange messages from upstream to downstream functions upon execution.

• AWS Step Functions and

• Azure Durable Functions are such FaaS workflow platforms.

Need of XFaaS

Functions as a Service (FaaS) have revolutionized cloud programming with its simplicity, scalability, and efficient billing. However, there are many limitations of FaaS models which are typically proprietary to cloud service providers(CSP), limiting the portability of function logic across different platforms. This poses challenges when designing FaaS workflows that span multiple clouds or data centers, hindering regulatory compliance, cost optimization, and avoiding vendor lock-in. Additionally, each cloud provider's FaaS execution model introduces diverse performance characteristics and limitations. To address these issues, we have XFaaS

XFaaS Introduction

XFaaS is a cross-platform deployment and orchestration engine that leverages Passage for authentication, enabling the seamless “zero-touch” portable deployment of workflows on AWS and Azure automatically generating necessary code wrappers for each FaaS provider, creating cloud queues to execute workflows across data centers, and coordinating with the native FaaS engine of a cloud provider for management and monitoring

XFaaS Strategy

We provide detailed benchmarks on FaaS workflow execution on Azure and AWS and draw insights on their performance for different types of FaaS workloads. This is used to build simple yet practical performance models for these platforms. We leverage this knowledge to propose intelligent

• workflow partitioning

• workflow fusion

• workflow placement

  algorithms that leverage these models to intelligently rewrite the workflow to maximize performance and automatically deploy this across multiple clouds

Fusion Method

A user may submit a DAG structure where each task may be an atomic unit of work that is easy to implement, modular and tractable. However, the complex billing and platform internals for workflows may mean that the user submitted DAG structure may not be ideal with respect to either cost or latency. With function fusion, we fuse nodes in the user’s DAG structure such that each fusion either reduces the latency or reduces the cost

Partition Method

When the user submits a DAG, the planner may partition the DAG and decide the placement of each partitions and its functions in the appropriate CSP. XFaaS supports partitioning the DAG into two parts, though this can be extended to more than two partitions across additional CSPs or different data centers of the same CSP. The input to the partitioner is the user DAG, the estimated execution latencies for each function, and the inter-function or inter-cloud transfer latencies. Based on these, the partitioner picks the best possible partition point along with the CSPs where each part should be placed. The partitioner may also return a single CSP where the entire DAG has to be placed.

XFaaS Platform

This project is being developed at the Indian Institute of Science(IISc), for which I am presently designing the User Interface to this XFaaS platform to introduce authentication features with the aid of Passage

Passage Integration

With just a few lines of code, Passage allowed me to implement the login/register feature by allowing only authorized users to view the webpage and also employing Passage's useAuthStatus Hook to use the Gmail ID to keep track of the user-submitted functions or workflows!

import { useState, useEffect } from "react";
import {PassageUser}  from '@passageidentity/passage-auth/passage-user';

export function useAuthStatus() {

  const [result, setResult] = useState({
    isLoading: true,
    isAuthorized: false,
    username: "",
  });

  useEffect(() => {
    let cancelRequest = false;
    new PassageUser().userInfo().then(userInfo=> {
      if( cancelRequest ) {
          return;
      }
      if(userInfo === undefined){
          setResult({
              isLoading: false,
              isAuthorized: false,
              username: "",
            });

            return;

      }
      const username = userInfo.email ? userInfo.email : userInfo.phone;
      setResult({
          isLoading: false,
          isAuthorized: true,
          username,
        });

    });
    return () => {
      cancelRequest = true;
    };
  }, []);
  return [result,setResult];
}

Main Page

The main page is where you see all the user-submitted workflows, when you click on a specific workflow Identifier it takes you to that workflow page displaying the workflow details and its corresponding DAG with its deployments list based on the user chosen

• Single Cloud(Deploy common function logic as workflows in AWS Stepfunctions and Azure Durable Functions)

• Single Cloud Fusion(Based on prior benchmarks, deploy modified workflows with function fusion in AWS and Azure.)

• MultiCloud(Based on prior benchmarks, deploy a workflow partitioned across Azure and AWS.)

• MultiCloud with fusion(Based on prior benchmarks, make fusion and deploy a workflow partitioned across Azure and AWS)

Workflow Page

Clicking on the specific deployment ID will take you to the Deployment Page which shows refactored DAG nodes(fusion or partition method or none) and to which CSP it is placed indicated by its palette color.

Deployment Page

Graph View

Function

Clicking on a particular node you can see its function code, Here I clicked on the Resnet node and I can see the function code that's being deployed on AWS

Table View

To check the number of invocations or statistics for that specific deployment, click the invocations button, which brings you to its invocation page. This on a whole is still in developing stage and not so not being deployed yet

Invocations Page

Link to the repository: https://github.com/itsCheithanya/XFaaS/tree/fullstack-classic

Conclusion

I am immensely grateful to 1Password and Hashnode for organizing this hackathon and creating an environment that encourages learning, collaboration, and creativity. It has been a rewarding journey.