这是我参与「第五届青训营 」伴学笔记创作活动的第 38 天

本节课将重点介绍 FaaS Native 的基本概念、应用与实现，帮助同学更好地了解 PaaS 到 FaaS 演进历程，并在此基础上，进一步分享公司未来在 FaaS Native 这一产品上的发展愿景及未来规划。

FaaS Native: The idea

ldea #1 Building native apps on ByteFaaS

• What do you mean Native?
• Customer's application:
  • Different languages
  • Different frameworks
  • Different protocols
  • Different dependencies
• The goal:
  • Users can run their apps as-is on ByteFaaS, with no code change

ldea #2 One code base, connected to many event sources

• For a complicated system:
  • Web API, Backend RPC, MQ consumer, Timer/Cronjob, mysql binlog ...
  • KiteX. Hertz. Ginex.
  • Euler, Pie. Lust...
• ByteFaaS could be the one stop solution.

ldea #3 The evolution from PaaS to FaaS

• A complement to PaaS：
  • Fast to deploy
  • Zero ops
  • Save on budget $$
  • Not a one way door

Question 1

• But how about TCE? We already have a PaaS, sounds like you guys are re-inventing the wheel.

Yes and No

• An extension to PaaS platform. ldeally customer no need to care about the difference.
• Integration with differnt event source.
• In lot of scenarios (stateful apps, do not want autoscaling)
• TCE is still your best friend.（针对于不适用于FaaS的场景）
• ByteFaaS itself is built on top of TCE.

Question 2

• Hey have you guys heard of Knative? The idea just sounds familiar =D

You are right =D

• We do have considered Knative as an option
• Known gaps here:
  • Cold start performance
  • RPC protocol support

这里的底层是自己自研的，拥有很多的新特性昂！！！

Under the hood

The Starting Point

The original ByteFaas data plane: all in http

Inside function pod

Step #1: native http

• ByteFaaS was all in http, native http apps support is easy-peasy
• FaaS Native HTTP
  • Hertz, Flask, Django, Spring...

So why http? So why everybody (kind of) stuck with HTTP? what does HTTP protocol bring to us?

• Multi-tenancy: identify request from different sender, without parsing the body
• More fine-grained metrics & traffic control: concurrency limit/cold start/overload protection, etc
• (Good to have) connection re-use (and multi-plexing for http/2)

HTTP一定是有一些适合于FaaS的特性，我们把这些特性抽出来。如果其他协议，也同时满足这些特性，其实这个协议也就是可以FaaS化的昂！！！

Step #2: gRPC

• The first RPC protocol ByteFaaS supported

• gRPC @ FaaS: native gRPC, KiteX stream

• So what does gRPC look like?

  • A open source high RPC framework initially started by Google
  • Commonly using protobuf for data serialization/deserialization
  • Using HTTP/2 as the transfer protocol

• HTTP/2

  • A binary protocol (compared with HTTP/1.1)
  • Request/Response are transfered in binary frames
  • Stream & Multiplexing

• gRPC itself is built on top of the http2, so......

• Different warming pool

Step #3: Thrift

• Why Thrift?
  • This is the underlying protcol for KiteX/Euler/Lust
• But it's also a little bit trickey....
  • Not HTTP anymore
  • It's just too flexible
    • Different serialization/deserialization protocol: buffered/framed/json...
    • Different transport protocol: buffered/framed/even http...

Thrift 101

• The layered thrift stack
• The "Protocol" layer:
  • serialize/deserialization
• The "Transport" layer:
  • Reading/writing to network

• The problem:
  • lt's just too flexible
  • Even internal frameworks(Kitex/Euler/Archon/Lust) they decided to use different protocol/transport combinations
• What we want:
  • An easy way to retrieve user's identity (PSM/functionlD), without parsing the actual request .

• What we want:
  • An easy way to retrieve user's identity (PSM/functionlD), without parsing the actual request
  • TTHeader comes to help =D

TTheader =D

• TTHeader protocol is an internal effort driven by Framework team
• The good thing for ByteFaaS:
  • Header fields for service identity
  • Unified transport wrapper layer

Multi-protocol Support

• Differentiate control plane port & data plane port
  • Control plane: function load/initialize/healthcheck
  • Data plane: function invoke
• Same control plane logic, different data plane proxy servers for different protocol

• Data plane: Seperate TTHeader gateway

• 支持的东西：

Step #4: The Client Side

• Client side issues:
  • How to discover a FaaS Native app?
  • How to migrate existing client side applications?
  • (For Thrift) What if client side is not using TTHeader?
  • ......

ByteMesh comes to help

• Specialized service discovery

• Protocol translate

• If you wanna use consul...
  • bytefaas supports consul trigger
  • consul alias

Step #5: Trigger Support

• Just like vanila ByteFaaS
  • Time support for Thrift
  • MQ trigger support for Thrift

About the future plan

Customized lmage（lt's coming soon）

• Customized execution environment
• Cold start? Image lazy load

Performance

• Current benchmark result
  • 6400 QPS, single CPU core on B04
• Keep improving
  • Improved http request processing with Hertz
  • level 4 proxy?

Developer Experience

• Customized command
• Better integration with popular frameworks
• Debug port support & Lidar integration
• And more (we need your feedback =D)

Wrap-up

• Why we build FaaS Native:
  • Migrating to ByteFaaS with no code change
  • Eventsoure integration
  • Reduced budget & ops burden
• Under the hood:
  • Native HTTP
  • Native gRPC
  • Thrift (with TTheader)
  • Client side integration (with Consul & Mesh)
• Future Plan:
  • Performance
  • Developer experience

Last but not least....

• veFaaS is coming =D: console.volcengine.com/vefaas
• ByteFaaS on VolcEngine