Managing FaaS Services Deployed Across Different Cloud Providers

Introduction

Sometimes you have to pick the best of the breed solution for different needs. This is true among the services provided by the different cloud providers as well. For instance, when it comes to cognitive services, Google, Amazon, and Microsoft rule the roost. Even among them, Google does natural-language translation, landmark recogintion, and text extraction from images, and content-based search the best. Amazon is the leader in facial recognition. Similarly, I found Microsoft’s image labeling the best among the breed.

No longer do you have to settle with one cloud provider to solve your needs. With frameworks such as the Serverless Framework, you can develop services across various providers, deploy and manage them in a cloud-agnostic fashion. With a single environment, you can develop, test and deploy to most of the big cloud providers without having to worry about their idiosyncrasies and react to cross-cloud events.

Demonstration

This is a simple tutorial to demonstrate how to deploy multiple services on different cloud providers using the Serverless Framework.

More specifically, this tutorial walks you through deploying an image detection service on Google Cloud Platform (GCP) and managing it using a proxy service running on Amazon Web Service. Both the services on either platform is 100% serverless.

The image detection service running on GCP uses Google’s FaaS solution viz., Cloud Functions and the proxy running on AWS uses Amazon’s FaaS solution viz., Lambda.

In a typical scenario, you will use a service such as this to detect the contents of an image uploaded to a S3 bucket and take appropriate actions based on the result. For instance, you could use it to blur/reject the image based on the vulgarity or get the image labels and chain it to other services that will translate the labels to multiple languages to cater to your customer needs.

Code Repository can be found here.

Setup

Setup Amazon AWS

  1. Sign into your AWS account or sign-up for one.

  2. Setup your AWS credentials by following the instructions from here.

Install node.js and Serverless framework

Serverless framework is a node.js application. To use Serverless framework and run the tutorial you need to install node.js. Follow the instructions from Serverless website to install both node.js and the Serverless framework.

Ensure your Serverless framework is operational using the following:

$ serverless --version

Testing your Serverless Setup

Now that you have setup AWS, it is time to test your Serverless setup by creating a mock function using the Serverless framework.

Create a test directory. In the test directory, create a Lambda function from the default template as follows:

$ mkdir sls-tester
$ cd sls-tester
$ sls create --template aws-python --name sls-test

This should create two files in the current directory:

serverless.yml

handler.py

The serverless.yml declares a sample service and a function. The handler.py returns a message stating that your function executed successfully.

To deploy the function, simply type:

$ sls deploy --verbose

This should deploy the function. The verbose option provides extra information.

To test your function, type:

$ sls invoke --function hello

If you get the following message, your Serverless setup is working.

{
    "body": "{\"input\": {}, \"message\": \"Go Serverless v1.0! Your function executed successfully!\"}",
    "statusCode": 200
}

To check the logs for your function, type:

$ sls logs -f hello

To keep a continuous check of the logs for your function, type:

$ sls logs -f hello -t

Setup Google Cloud

  1. Sign up for a new Google account at http://accounts.google.com. If you already have an account you can skip this step.
  2. Sign up for a Google Cloud trial at http://console.cloud.google.com/start. If you already have Google Cloud privileges on your Google account, you can skip this step.
  3. Create a new project and call it serverless-project (or a name of your choice).
  4. Select Credentials in API & Services section of the Google Cloud console.
  5. Under Create Credentials, create a new Service Account Key. Download the JSON key file to a secure place as you will need that in subsequent steps.
  6. In the API & Services dashboard, enable Google Cloud Vision API, Google Cloud Functions API, Google Cloud Deployment Manager API, Google Cloud Storage & Stackdriver Logging.

Image Detector

gcp-label-image

The gcp-label-image is the service that will deployed on GCP. It is a node.js based service that takes an image url passed through the HTTP request and sends it to Google Vision to detect the contents of the image and return a list of tags describing the content of the image.

The image URL should be passed as an HTTP parameter named imageUri. If this parameter is missing the service uses a default image to detect and return the contents.

Deploying the Image Detector Service

  1. Location: Go to the gcp-label-image subdirectory in the folder where you cloned the Git repository.
  2. Project: Replace the your-gcp-project-id in the serverless.yml file with your Google Cloud project id.
  3. Credentials: Replace the /path/to/your/gcp/credentials/json in the serverless.yml file with the path to the JSON credentials that you saved in the GCP setup.
  4. Deploy: In the service home directory, run the following command to deploy the detectLabel service on GCP. Make a note of the endpoint created. This endpoint is a URL that will end with detect as shown below. shell
    $ sls deploy --verbose
    ...
    Deployed functions
    detectLabel
    https://your-region-your-project-id.cloudfunctions.net/detect
    ...
  5. Verify: You can check your Google Cloud Functions dashboard to ensure that your Cloud Function is deployed.
  6. Invoke@theTerminal: Invoke the function detectLabel as follows: shell
    $ sls invoke -f detectLabel
    Serverless: ekvy90t28px8 Image Results: landmark historic site sky tourist attraction ancient rome ancient history ancient roman architecture medieval architecture night building
    $
  7. Invoke@theBrowser: Copy and paste the URL from the result of your sls deploy into the browser and add the imageUri parameter as follows: Far
    https://your-region-your-project-id.cloudfunctions.net/detect?imageUri=https://goo.gl/27gclq

Image Detector Proxy

aws-gcp-proxy

The aws-gcp-proxy is the service that will be deployed on AWS. It is a Python-based service that will take an image URL passed through the HTTP request and send it to the Cloud Function deployed on GCP.

In a typical use, you will use it to detect the content of an image uploaded to a S3 bucket and take appropriate actions based on the result. For instance, you could use it to blur/reject the image based on the vulgarity or get the image label and chain it to another service that will translate the labels to multiple languages to cater to your customer needs.

The image URL should be passed as an HTTP parameter named imageUri. If this parameter is missing the service uses a default image URL to detect and return the contents.

Deploying the Image Detector Proxy Service

  1. Location: Go to the aws-gcp-proxy subdirectory in the folder where you cloned the Git repository.
  2. Environment Variable: Edit the setEnv.sh file to point update the GFUNC_URL to point to your image detector service running on GCP.
  3. Deploy: In the service home directory, run the following command to deploy the proxy service. Make a note of the AWS Gateway endpoint created. You will use this endpoint to test your service. shell
    $ sls deploy -v
    ...
    GET - https://urmileagemaydiffer.execute-api.us-east-1.amazonaws.com/dev/detect
    ...
  4. Verify: You can check your AWS Lambda dashboard to ensure that the Lambda function was created and the environment variable is being passed.
  5. Invoke: Copy and paste the AWS Gateway API URL into the browser and add the imageUri parameter as follows: Far
    https://urmileagemaydiffer.execute-api.us-east-1.amazonaws.com/dev/detect?imageUri=https://goo.gl/27gclq

Conclusion

Serverless Framework makes it painless to deploy services across multiple cloud providers without having to deal with the idiosyncrasies of various providers allowing you to focus on your application. Additionally, the framework allows you to use the right provider for the right service, cuts the time spent on deployment while allowing you to manage the code and infrastructure across multiple providers.

Serverless Architecture & Serverless Framework

Per Gartner, by 2022 most cloud architectures will evolve to a fundamentally serverless model rendering the cloud platform architectures dominating in 2017 as legacy architectures.

Serverless is a cloud-native platform model and reflects the core-promise of cloud-computing by offering agility and capability on demand at a value price.

The introduction of function PaaS (fPaaS) as Lambda by Amazon in re:Invent, Nov 2014 (and out of beta in late 2015) created a momentum for “serverless” platform architecture. AWS Lambda was soon followed by most major cloud platform vendors, including IBM, Microsoft, Google and, more recently, Oracle.

Amazon started the trend with Lambda

Separating the Wheat from the Chaff

Serverless computing model is an emerging trend and quite often misunderstood because of the hype and build-up surrounding the topic.

The term Serverless refers to building applications without having to configure or maintain the infrastructure required for running your applications. In reality, servers are still involved, though they are owned and controlled by the platform providers. On the other hand, there are frameworks used for exploiting the serverless architecture uninspiringly named Serverless Framework and therefore increasing the confusion.

Serverless - No need to configure or maintain infrastructure

Serverless Architectures

Serverless Architectures are based on models where the application’s logic provided by the Developer is run on stateless, compute containers that are provisioned and managed by a provider. Typically these compute instances are ephemeral (short-lived for the duration of the request-response cycle) and triggered by an event. As the load on the application increases, additional infrastructure is automatically deployed to meet the need. Due to this on-demand provisioning nature of this architecture, the systems built using Serverless technologies are inherently scalable and highly responsive under load.

**FaaS – Function as a Service **

The technique of building applications using Serverless architecture.

  • Pay-per-execution – Pay per execution model is most efficient at managing costs.
  • Ephemeral – Short-lived process triggered via event.
  • Auto-scaling – Compute resources are provisioned granularly per request.
  • Event-driven – Functions respond to events such as http, file drop, alerts, timer, topics etc
  • Microservices – Modules built to satisfy a specific goal and uses a simple, well-defined interface.
FaaS – Applications Built with Serverless Architecture

FaaS vs PaaS

Some people in the industry refer to the technique of building applications using Serverless architecture as FaaS (Function as a Service). The reason becomes clear when you contrast FaaS applications with the traditionally built applications or PaaS (Platform as a Service) where there is a perpetual process running on a server waiting for HTTP requests or API calls. In FaaS there is no perpetual process (for the most part) but an event mechanism that triggers the execution of a piece of code, usually just a function. You still need a perpetual gateway that will field your API calls to start the events to cascade.

The other key operational difference between FaaS and PaaS is scaling. With most PaaS solutions you still need to worry about scale. With FaaS the compute resources are provisioned at a request level. You cannot get the same level of granularity with PaaS applications even if you set it to auto-scale. As a result of this, FaaS applications are extremely efficient when it comes to managing cost.

Limitations of FaaS

State Due to the ephemeral nature of the FaaS architecture, the state of your application should be managed externally from the FaaS infrastructure or off-loaded to a cache or database. This could be very limiting for certain type of applications running on thin clients or untrusted devices where the application orchestration has to extend through multiple request-response cycles.

State between Requests must be maintained outside of FaaS

Duration Because of the on-demand provisioning and low-cost nature of the FaaS solution there is a restriction on how long your functions are allowed to run. To keep the price low – as you are billed by minutes of usage, some providers such as Amazon AWS and Microsoft Azure restrict the duration of time a function is allowed to process a request.

 Duration of time a function is allowed to run is restricted

Deployment & Resource Limits Some providers such as AWS have deployment limits on the size of the deployment package, size of the code and libraries that can be deployed in the package. This could be severely limiting for some applications such as image processing functions that depend on large libraries that have to be packaged along with the code. Additionally, there are limits on the number of concurrent function executions, ephemeral disk capacity (temp space) etc. While some of these limits are soft limits and can be reconfigured per function by working with the providers, others are hard limits and will force you to reevaluate the choice of your design.

Resources are limited - Use wisely

Latency Due to the on-demand provisioning nature of the FaaS infrastructure, applications that use languages such as Java/Scala that require a long start time to spin up JVMs may encounter longer runtime. Having said that, providers optimize the infrastructure spin-ups based on the usage patterns of the functions. Due to the interpreted nature of Python and Javascript, functions written in these languages may not see a significant difference in latency between a PaaS and FaaS offering.

Test the performance of your applications thoroughly

The Players

While there are new providers entering the market to exploit the Serverless wave, the significant players are Amazon with its AWS Lambda, Microsoft with its Azure Functions, Google with its Google Functions and IBM with its Openwhisk rule the roost with AWS Lambda being the dominant player.

Amazon's AWS Lambda is the dominant player

Serverless Framework

While not having to manage infrastructure by using serverless functions is nice, having to deal with hundreds of functions in a project between multiple providers, managing buckets, messaging and permissions become an issue in itself. Additionally, organizations want to diversify risk and hence do not want to be bound to a single provider.

Add to this mix the idiosyncrasies of the provider when it comes to their FaaS offering. Not only do you have to learn the different terminologies used by the various providers, you will have to learn how to use their offerings on their respective consoles or CLI (Command Line Interface).

To avoid vendor lock-in and allow to deploy your FaaS solutions to various providers, Serverless Framework comes to your rescue. The Serverless Framework allows you to deploy auto-scaling, pay-per-execution, event-driven functions to any cloud. They currently support AWS Lambda, IBM Bluemix OpenWhisk, Microsoft Azure, and are expanding to support other cloud providers.

The Serverless Framework is an MIT open-source project, actively maintained by a vibrant and engaged community of developers and provides robust plugins for various FaaS providers and allows to extend it when needed.

The Serverless Framework allows you to provision and deploy REST APIs, backend services, data pipelines, and other uses cases by providing a framework and CLI to build serverless services across many providers by abstracting away provider-level complexity.

The Serverless Framework is different than other application frameworks because: – It manages your code as well as your infrastructure – It supports multiple languages (Node.js, Python, Java, and more)

Serverless framework allows choice of FaaS providers across a single project

Core concepts of Serverless Framework Serverless Framework consists of the following core concepts:

  • Service
  • Function
  • Events
  • Resources
  • Plugins

Service A Service in the Serverless Framework is the unit of organization. It’s where you define your Functions, the Events that trigger them, and the Resources your Functions use, all in one file titled serverless.yml. More information at https://goo.gl/9SKBvx

An application can have multiple services and hence multiple serverless.yml files.

Functions A Function is an independent unit of deployment or micro service. It manifests itself as a Lambda or Azure Function depending upon the provider. It’s merely code, deployed in the cloud, that is most often written to perform a single job such as:

  • Saving a user to the database
  • Processing a file in a database
  • Performing a scheduled task

Events Anything that triggers a Function to execute is regarded by the Framework as an Event. Events on AWS are:

  • An AWS API Gateway HTTP endpoint request (e.g., for a REST API)
  • An AWS S3 bucket upload (e.g., for an image)
  • A CloudWatch timer (e.g., run every 5 minutes)
  • An AWS SNS topic (e.g., a message)
  • A CloudWatch Alert (e.g., something happened)

When you define an event for your functions in the Serverless Framework, the Framework will automatically create any infrastructure necessary for that event (e.g., an API Gateway endpoint) and configure your Functions to listen to it.

Simply put, events are the things that trigger your functions to run. If you are using AWS as your provider, all events in the service are anything in AWS that can trigger an AWS Lambda function, like an S3 bucket upload, an SNS topic, and HTTP endpoints created via API Gateway.

Upon deployment, the framework will deploy any infrastructure required for an event (e.g., an API Gateway endpoint) and configure your function to listen to it.

Resources Resources are infrastructure components which your Functions use. If you use AWS as your provider, then resources are:

  • An AWS DynamoDB Table (e.g., for saving Users/Posts/Comments data)
  • An AWS S3 Bucket (e.g., for saving images or files)
  • An AWS SNS Topic (e.g., for sending messages asynchronously)

Anything that can be defined in CloudFormation is supported by the Serverless Framework. The Serverless Framework not only deploys your Functions and the Events that trigger them, but it also deploys the infrastructure components your Functions depend upon.

Credentials Serverless Framework needs access to your cloud provider account credentials to deploy resources on your behalf. For AWS you can use AWS CLI (aws configure). Azure is more involved.

Following links provide excellent guidance on setting up the credentials for various providers currently supported on the Serverless Framework.

  • AWS – https://serverless.com/framework/docs/providers/aws/guide/credentials/
  • Azure -https://serverless.com/framework/docs/providers/azure/guide/credentials/
  • Openwhisk – https://serverless.com/framework/docs/providers/openwhisk/guide/credentials/

Deployment Serverless Framework translates the service declaration in the serverless.yml file into a Cloud Formation or Resource Manager template depending on the provider you choose.

To deploy your service, functions, and provision the resources all at once, enter:

serverless deploy --verbose

To deploy a single function after making changes to it, enter:

serverless deploy function --function <myfunction> --verbose

Invoking Serverless Framework allows you to invoke a function locally for testing or invoke a deployed function.

To invoke your function locally, enter:

serverless invoke local --function <myfunction> --log

To invoke a deployed function, enter:

serverless invoke function --function <myfunction> --stage <my stage> --region <myregion>

If you omit the stage and region option, the default stage (dev) and region specified in your provider configuration will be used.

CelebritySleuth – A Sample Use case

CelebritySleuth is a celebrity face recognition service built using Serverless Framework, Twilio, Amazon Rekognition and IMDbPy API.

The CelebritySleuth application is an event-driven application taking advantage of the user’s mobile SMS/MMS for the presentation tier, Twilio in the middle-tier to bridge the SMS world and AWS Gateway and a set of AWS Lambda functions written in Python making use of AWS Rekogniton for image processing and IMDB for gathering information on the celebrities.

CelebritySleuth code repository, installation guide, and usage is at https://github.com/skarlekar/faces

How it works To begin with, you have to train the application to recognize the faces by building a collection of celebrities. You do this by sending a random sample of celebrity pictures (image URLs) and their corresponding names. The more pictures of a celebrity, the more accurate the recognition will be. The CelebritySleuth application consists of two services:

  • Twilio Communication Service
  • Face Recognition Service

The services are decoupled to allow for using different presentation tiers in future.

Architecture The CelebritySleuth application uses Lambda functions for computing needs. As a result, the application components are provisioned just before usage and brought down after use resulting in a low-cost, highly-scalable application.

The above picture illustrates the high-level architecture of the application. Details are as follows:

  1. The user sends a picture and commands to add/match a face to a collection. Alternatively, the user can create a collection – in which case a picture is not required. The SMS/MMS is sent to a telephone number hosted by Twilio.

  2. Twilio intercepts the message and forwards it to an API Gateway based on the user’s Twilio configuration.

  3. API Gateway translates TwiML to JSON and calls the Request Processor lambda function.

  4. The Request Processor lambda validates the commands and puts a message on the appropriate topic on SNS. If the validation fails, it returns the error message to the user via Twilio.

  5. When a message arrives in the Create Collection topic, a lambda is triggered which adds the named collection in AWS Rekognition via Boto libraries. A success/error message is put in the Response Processor topic.

  6. When a message arrives in Add Face topic, a lambda is triggered which identifies the most prominent face in the image and adds the metadata for the face to the given collection. If there are no faces identified, it creates an error message and sends the response to the Response Processor topic.

  7. When a message arrives in Match Face topic, a lambda is triggered which identifies the most prominent face in the image and matches the metadata for that face with known faces in the collection. If a match is found, the corresponding person’s name is returned. The Lambda then uses IMDB to look up the biography of the person.

  8. The various lambda-based processors put the response message on the Response Processor topic.

  9. The Response Processor picks up the response and constructs an SMS message and calls Twilio’s SMS service.

  10. Twilio validates the From number and sends the message to the corresponding To number.

Components

The application consists of the following components:

  1. Python – Python is a programming language that lets you work quickly and integrate systems more effectively.

  2. Twilio – Twilio Messaging Service for having the user communicate with the application through SMS.

  3. AWS Lambda – AWS Lambda lets you run code without provisioning or managing servers. You pay only for the compute time you consume – there is no charge when your code is not running.

  4. AWS Rekognition – Amazon Rekognition is a service that makes it easy to add image analysis to your applications. With Rekognition, you can detect objects, scenes, and faces in images. You can also search and compare faces.

  5. IMDb – IMDbPY is a Python package useful to retrieve and manage the data of the IMDb movie database about movies, people, characters, and companies.

Screenshots

Application in Action

Following is a sample animation of the application in action:

Conclusion

Serverless Framework is an accelerator for adopting Serverless architecture. It promises significantly less DevOps, lower cost, high scalability and multiple deployment options across a variety of providers.

Apart from providing a scaffolding to deploy Lambdas the Serverless Framework allows you to manage multiple Lambdas, manage related infrastructure across multiple regions and stages. To top it off, it allows you to manage the equivalent of Lambda functions across multiple providers.

In my testing, I could not deploy the CelebritySleuth application on Microsoft Azure because the Serverless Framework does not currently support deploying functions written in Python. Although, in speaking to Austin Collins the founder of Serverless Framework at the Serverless Conf 2017 in Austin, I gather that his team is working on providing support to as many languages as supported by the cloud providers.

Asides from this, I was able to build the CelebritySleuth application from start to end in a couple of hours using the Serverless Framework compared to half-a-day for setting up the components manually through AWS console.