Chapter 1 – Introduction

In the early days having a computer software system to handle day to day operations was not as easy as today. There were only a handful of people who were capable of writing such a system yet alone deploy and manage such a system for a whole organization. Organizations who were able to implement such systems had to deploy those into physical servers within the organization that were carefully managed by a specialized team, but constant maintenance of these servers day and night was not affecting the business in a good way.

Rise of the cloud providers was a result of this nightmare. What they promised was that they would take care of the physical servers and the related hardware infrastructure so we only have to focus on the operating system layer and the application server layer. This removed a great burden from the organizations and individuals and came with even better perks like discarding them at any time they want and forgetting about the depreciation of the physical servers.

This model was robust and professionals liked it but as it says the only constant in IT is the change, a new iteration of this model came into light. In 2008 Google introduced the first commercially available “pay as you go” code execution. This model tried to address a few issues in the previous model. Maintaining the application servers needed some set of a specialized team. Also the end users had to pay for the uptime of the application server even though there were no actual business transactions processed inside. Servers were sitting idle most of the time. What pay as you go introduced was that the cloud providers would take care of the application servers and end users would only have to focus on the business functions and run them on those managed application servers. This completely abstracted the servers from the end user where the end users could basically think it is “serverless”.

In 2014 Amazon introduced AWS Lambda where this serverless concept model became even popular. With the rise of this abstract serverless model Huawei Cloud introduced Huawei FunctionGraph in late 2018 to provide serverless capabilities to their end users. From early 2019 this model began to evolve and today it supports NodeJs, Python, Java, Go, C# and PHP. This allows many types of developers who are specialized in different languages to write business codes and execute them using the Huawei FunctionGraph. FunctionGraph provides a highly available, highly scalable environment with zero maintenance where you only have to pay for what you use.

Chapter 2 – Getting Started

Process

Source – FunctionGraph Help Center : Overview

1. Developers can write the codes in Node.js, Python, Java, Go, C#, or PHP with a special set of request and response parameters

2. Alternatively, edit code inline, directly upload a ZIP or JAR file, or upload a ZIP file from Object Storage Service (OBS).

3. Functions can be triggered by many sources as described in the next sections.

4. During function execution, FunctionGraph scales automatically based on the number of requests without the need for configurations.

5. FunctionGraph works with Log Tank Service (LTS), allowing you to query run logs of your function without the need for configurations. FunctionGraph works with Cloud Eye, allowing you to view graphical monitoring information about your function without the need for configurations.

Supported Triggers

Developed functions need to be triggered by a source to invoke the business logic inside the function. Following event sources are currently supported by FunctionGraph.

SMN

Simple Message Notification (SMN) sends messages to email addresses, mobile phones, or HTTP/HTTPS URLs. If you create a function with an SMN trigger, messages published to a specified topic will be passed as a parameter (SMN example event) to invoke the function. Then, the function processes the event, for example, publishing messages to other SMN topics or sending them to other cloud services.

DMS

Distributed Message Service (DMS) is a message queuing service that enables communication between distributed applications. If you create a function with a DMS trigger, messages automatically polled from a specified queue will be passed as a parameter (DMS example event) to invoke the function.

API Gateway

API Gateway is an API hosting service that helps enterprises to build, manage, and deploy APIs at any scale. With API Gateway, your function can be invoked through HTTPS by using a custom REST API and a specified backend. You can map each API operation (such as, GET and PUT) to a specific function. API Gateway invokes the relevant function when an HTTPS request (API Gateway example event) is sent to the API backend.

OBS

Object Storage Service (OBS) is a stable, secure, efficient, and easy-to-use cloud storage service. You can create a function to process OBS bucket events, for example, creating and deleting objects. When an image is uploaded to a specified bucket, OBS invokes the function to read the image and create a thumbnail.

DIS

Data Ingestion Service (DIS) can ingest large amounts of data in real time. You can create a function to automatically poll a DIS stream and process all new data records, such as website click streams, financial transactions, social media streams, IT logs, and location-tracking events (DIS example event). FunctionGraph periodically polls the stream for new data records.

Timer

You can schedule a timer (timer example event) to invoke your code based on a fixed rate of minutes, hours, or days or a cron expression.

LTS

Log Tank Service (LTS) collects and stores logs, allowing you to query them in real time. If you create a function with an LTS trigger, subscribed logs collected by LTS will be passed as a parameter (LTS example event) to invoke the function. Then, the function processes or analyzes the logs, or loads the logs to other systems.

CTS

Cloud Trace Service (CTS) collects operation records of subscribed cloud resources. If you create a function with a CTS trigger, collected operation records of specified cloud services will be passed as a parameter (CTS example event) to invoke the function. Then, the function analyzes and processes key information in the operation records, automatically recovers system or network modules, or reports alarms to service personnel by SMS or email.

DDS

Document Database Service (DDS) is a MongoDB-compatible database service that provides a variety of functions including DB instance creation with a few clicks, scaling, disaster recovery, backup, restoration, and monitoring. If you create a DDS trigger for a function, any updates to the specified database table will trigger the function.

DMS for Kafka

DMS for Kafka is a message queuing service that provides Kafka premium instances. If you create a Kafka trigger for a function, when a message is sent to a Kafka instance topic, FunctionGraph will retrieve the message and trigger the function to perform other operations.

Cloud Eye

Cloud Eye is a multi-dimensional resource monitoring platform. FunctionGraph is interconnected with Cloud Eye to report metrics, allowing you to view function metrics and alarm messages through Cloud Eye.

Source – FunctionGraph Help Center : Overview

Chapter 3 – Cost

The billing mode for FunctionGraph is pay per use. Price is calculated based on the number of requests and execution duration.

Total price = Price for requests + Price for execution duration

Free Tier

Requests: 1 million free requests every month.

Execution duration: 400,000 GB-seconds free execution duration every month

Chapter 4 – Conclusion

Huawei Cloud is fairly new but they offer a simplified yet complete stack if you get your System into the cloud. FunctionGraph being one of the core features in the Huawei ecosystem reflects the same set of characteristics. Supporting modern languages and giving a competitive price could never go wrong.