Free the Functions!
Ewan Slater
@ewanslater
Agenda
● Serverless
○ What it is
○ Why it matters
● Choose Your Platform Wisely
● Fn Project
Cloud Architect
Solve Problems
Simplicity
Abstraction
Serverless
What is “Serverless”?
“Serverless computing refers to the concept of building and
running applications that do not require server management.
It describes a finer-grained deployment model where applications,
bundled as one or more functions, are uploaded to a platform
and then executed, scaled, and billed in response to the exact
demand needed at the moment.”
- CNCF Serverless Whitepaper
What is “Serverless”?
● Serverless is an abstraction of infrastructure and its operations
including provisioning, scaling, patching, etc.
● Serverless architecture is when an app is built entirely on
serverless components (compute, storage, networking)
● Functions (or Functions as a Service) is the compute
component in a serverless architecture
FaaS
● Write small functions
● Do one thing well
● Easy to Understand
● Easy to Maintain
● Run on Serverless platform (i.e. abstracted infrastructure)
“Researchers have been attracted to Serverless
Computing, and especially to Cloud Functions because it is
a new, general purpose compute abstraction that promises
to become the future of cloud computing”
University of Berkeley,
Technical Report No. UCB/EECS-2019-3
“Customers benefit from increased programming productivity
and in many scenarios can enjoy cost savings as well.”
University of Berkeley,
Technical Report No. UCB/EECS-2019-3
Avoid
Serverless Upsides
● Make development easier
● Improve developer productivity
● Increased agility (Dev & Business)
● Reduce costs (Dev & Operations)
Serverless Downsides
● Shiny
● Lock - in
● Restricted choice
○ Language
○ Run - time environment
○ Unit of abstraction
Freedom
● Language(s)
● Runtime
● Level of abstraction
● Vendor independence
● Portability (multi - cloud / on premises)
● Decentralisation
● Privacy
Free The Functions!
Open Source Serverless
The Fn Project (fnproject.io)
● Open-source serverless compute platform
● Can be deployed to any cloud or on - premises
● Containers are primitives
● Active w/ large core team, 3500+ commits, 75+ contributors
● Native CloudEvents support
● Independently governed with representation at CNCF
● Language-based Workflow (Fn Flow)
Functions as Containers
● Function + dependencies
● Single - purpose
● Self - Contained
● Stateless
● Ephemeral
● Run on Demand
An Fn Function
● Small chunk of code wrapped into a container image
● Gets input via http-stream and environment
● Produces output to http-stream
● Logs to STDERR / syslog
Anatomy of a Function
Fn CLI
● fn init --runtime ruby myfunc
● fn deploy --app myapp
● fn invoke myapp myfunc
→ http://localhost:8080/invoke/01CW8VDK3BNG8G00GZJ000008S
fn deploy details
1. Build container (multi-stage) + bump version
2. Push container to registry
3. Create/update function endpoint(s) (servers lazy load images)
MyFunc:0.0.2
MyFunc:0.0.2 MyFunc:0.0.2
Your code
Fn Service
myfunc →
/invoke/01CW8V...
1 2 3
Function Development Kits (FDKs)
● Makes it a lot easier to write functions
● Developer includes FDK package / library / gem
● Developer writes function to the FDK’s interface
● FDK
○ Provides input data to function
○ Writes output & errors
Community
.Net core FDK
Ruby FDK
● Opens a socket in function container
○ (Fn Server connects to socket)
● Parses input from http-stream
● Executes function
○ Input
○ Context
● Sends back output on http-stream
No FDK, no problem!
Hot functions
● Run at least once
● Wait before terminating
○ Default timeout 30 seconds
○ Configurable
● Potentially reusable
○ FDK handles multiple invocations
○ Stateless remember!?
Endpoints
● Fn deploy creates default endpoint:
○ http://localhost:8080/invoke/01CW8VDK3BNG8G00GZJ000008S
○ Used by CLI
● A bit unfriendly
● Only one per function deployment
Triggers
● Meaningful URLs
○ http://localhost:8080/t/jotb/speaker-trigger
○ http://localhost:8080/t/jotb/delegate-trigger
● Multiple endpoints
○ e.g internal / external
● Creation:
○ CLI
○ func.yaml
Fn Server
● “API Gateway”
● Manages apps and functions
○ app ⇒ group of functions (“namespace”)
● Handles function invocations
● Runs as a Container
● Hosts function containers using Docker - in - Docker
Docker in Docker
● Limited “blast radius”
○ Doesn’t affect outer VM
○ Kill Fn container & restart
● Docker version independence
○ (inner can differ from outer)
● Reduce chance of container name collisions
Architecture
Request Process
Orchestration
Flow
● Promises based Orchestration
○ No new “special” language
○ Composable
○ Flexible
● A Flow is...
○ ...written in code
○ ...written as a function
○ ...deployed as a function (within an application)
Saga Pattern
● Problem
○ Business Transaction across multiple services
○ Need to maintain transaction integrity
○ No 2 Phase Commit
● Saga
○ Business Transaction = set of local (service level) transactions
○ Each local transaction triggers next event
○ On failure compensate (undo) previous transactions
Travel Saga
book flight
if fail →stop else book hotel
if fail → cancel flight else book car
if fail → cancel hotel & flight else pack bag :-)
Flow
● Language Support:
○ Java
○ Python
○ Node
● In the works:
○ Go
● To - do:
○ Ruby
Summary #1
● Serverless
○ Simplicity
○ Developer productivity
○ Lower costs
○ Future of Cloud Computing
● Choose your platform with care
Summary #2
● Fn Project ⇒ Serverless Platform
○ Open Source
○ Portable
○ Language Agnostic
○ Multiple FDKs
● Feedback and contributions welcome!
Get Involved
● Learn more: fnproject.io
● Join the conversation
○ Slack: slack.fnproject.io
○ Twitter: @fnproject
● Contribute: fnproject
Thank you!
Ewan Slater
@ewanslater

Free the Functions with Fn project!

  • 1.
    Free the Functions! EwanSlater @ewanslater
  • 2.
    Agenda ● Serverless ○ Whatit is ○ Why it matters ● Choose Your Platform Wisely ● Fn Project
  • 3.
  • 4.
  • 5.
  • 6.
  • 7.
  • 8.
    What is “Serverless”? “Serverlesscomputing refers to the concept of building and running applications that do not require server management. It describes a finer-grained deployment model where applications, bundled as one or more functions, are uploaded to a platform and then executed, scaled, and billed in response to the exact demand needed at the moment.” - CNCF Serverless Whitepaper
  • 9.
    What is “Serverless”? ●Serverless is an abstraction of infrastructure and its operations including provisioning, scaling, patching, etc. ● Serverless architecture is when an app is built entirely on serverless components (compute, storage, networking) ● Functions (or Functions as a Service) is the compute component in a serverless architecture
  • 10.
    FaaS ● Write smallfunctions ● Do one thing well ● Easy to Understand ● Easy to Maintain ● Run on Serverless platform (i.e. abstracted infrastructure)
  • 11.
    “Researchers have beenattracted to Serverless Computing, and especially to Cloud Functions because it is a new, general purpose compute abstraction that promises to become the future of cloud computing” University of Berkeley, Technical Report No. UCB/EECS-2019-3
  • 12.
    “Customers benefit fromincreased programming productivity and in many scenarios can enjoy cost savings as well.” University of Berkeley, Technical Report No. UCB/EECS-2019-3
  • 13.
  • 14.
    Serverless Upsides ● Makedevelopment easier ● Improve developer productivity ● Increased agility (Dev & Business) ● Reduce costs (Dev & Operations)
  • 15.
    Serverless Downsides ● Shiny ●Lock - in ● Restricted choice ○ Language ○ Run - time environment ○ Unit of abstraction
  • 17.
    Freedom ● Language(s) ● Runtime ●Level of abstraction ● Vendor independence ● Portability (multi - cloud / on premises) ● Decentralisation ● Privacy
  • 18.
  • 19.
  • 21.
    The Fn Project(fnproject.io) ● Open-source serverless compute platform ● Can be deployed to any cloud or on - premises ● Containers are primitives ● Active w/ large core team, 3500+ commits, 75+ contributors ● Native CloudEvents support ● Independently governed with representation at CNCF ● Language-based Workflow (Fn Flow)
  • 22.
    Functions as Containers ●Function + dependencies ● Single - purpose ● Self - Contained ● Stateless ● Ephemeral ● Run on Demand
  • 23.
    An Fn Function ●Small chunk of code wrapped into a container image ● Gets input via http-stream and environment ● Produces output to http-stream ● Logs to STDERR / syslog
  • 24.
    Anatomy of aFunction
  • 25.
    Fn CLI ● fninit --runtime ruby myfunc ● fn deploy --app myapp ● fn invoke myapp myfunc → http://localhost:8080/invoke/01CW8VDK3BNG8G00GZJ000008S
  • 26.
    fn deploy details 1.Build container (multi-stage) + bump version 2. Push container to registry 3. Create/update function endpoint(s) (servers lazy load images) MyFunc:0.0.2 MyFunc:0.0.2 MyFunc:0.0.2 Your code Fn Service myfunc → /invoke/01CW8V... 1 2 3
  • 27.
    Function Development Kits(FDKs) ● Makes it a lot easier to write functions ● Developer includes FDK package / library / gem ● Developer writes function to the FDK’s interface ● FDK ○ Provides input data to function ○ Writes output & errors
  • 28.
  • 29.
    Ruby FDK ● Opensa socket in function container ○ (Fn Server connects to socket) ● Parses input from http-stream ● Executes function ○ Input ○ Context ● Sends back output on http-stream
  • 30.
    No FDK, noproblem!
  • 32.
    Hot functions ● Runat least once ● Wait before terminating ○ Default timeout 30 seconds ○ Configurable ● Potentially reusable ○ FDK handles multiple invocations ○ Stateless remember!?
  • 33.
    Endpoints ● Fn deploycreates default endpoint: ○ http://localhost:8080/invoke/01CW8VDK3BNG8G00GZJ000008S ○ Used by CLI ● A bit unfriendly ● Only one per function deployment
  • 34.
    Triggers ● Meaningful URLs ○http://localhost:8080/t/jotb/speaker-trigger ○ http://localhost:8080/t/jotb/delegate-trigger ● Multiple endpoints ○ e.g internal / external ● Creation: ○ CLI ○ func.yaml
  • 35.
    Fn Server ● “APIGateway” ● Manages apps and functions ○ app ⇒ group of functions (“namespace”) ● Handles function invocations ● Runs as a Container ● Hosts function containers using Docker - in - Docker
  • 36.
    Docker in Docker ●Limited “blast radius” ○ Doesn’t affect outer VM ○ Kill Fn container & restart ● Docker version independence ○ (inner can differ from outer) ● Reduce chance of container name collisions
  • 37.
  • 38.
  • 39.
  • 40.
    Flow ● Promises basedOrchestration ○ No new “special” language ○ Composable ○ Flexible ● A Flow is... ○ ...written in code ○ ...written as a function ○ ...deployed as a function (within an application)
  • 41.
    Saga Pattern ● Problem ○Business Transaction across multiple services ○ Need to maintain transaction integrity ○ No 2 Phase Commit ● Saga ○ Business Transaction = set of local (service level) transactions ○ Each local transaction triggers next event ○ On failure compensate (undo) previous transactions
  • 43.
    Travel Saga book flight iffail →stop else book hotel if fail → cancel flight else book car if fail → cancel hotel & flight else pack bag :-)
  • 45.
    Flow ● Language Support: ○Java ○ Python ○ Node ● In the works: ○ Go ● To - do: ○ Ruby
  • 46.
    Summary #1 ● Serverless ○Simplicity ○ Developer productivity ○ Lower costs ○ Future of Cloud Computing ● Choose your platform with care
  • 47.
    Summary #2 ● FnProject ⇒ Serverless Platform ○ Open Source ○ Portable ○ Language Agnostic ○ Multiple FDKs ● Feedback and contributions welcome!
  • 48.
    Get Involved ● Learnmore: fnproject.io ● Join the conversation ○ Slack: slack.fnproject.io ○ Twitter: @fnproject ● Contribute: fnproject
  • 49.