“Serverless” is the hottest ticket in town right now. But many serverless platforms restrict your choice of language and / or dictate where your code runs. In this talk, I’ll describe how we can go to the serverless ball with open source and the Fn project in particular. “Serverless” aims to improve developer productivity by abstracting, underlying infrastructure layers. The servers are still there, but you just can’t see them. This abstraction allows the developer to focus solely on the functions that deliver value to the business and not on the plumbing. The economics of serverless are also interesting since you only consume resources when your functions run, rather than having applications running continually waiting to server requests. Sadly some leading serverless platforms are not open and restrict choice in terms of: - language - deployment In this talk, I want to show how you can do serverless development with your choice of language, and deployment location. Presentation Summary The evolution of “serverless” Functions as a Service (FaaS) open source serverless frameworks The Fn project (see http://fnproject.io) Fn functions building managing state logging FDKs (Function Development Kits) How we can link individual functions together to create serverless applications Building an example serverless application with Fn.

1. Free the Functions!
Ewan Slater
@ewanslater

2. Agenda
● Serverless
○ What it is
○ Why it matters
● Choose Your Platform Wisely
● Fn Project

3. Cloud Architect

4. Solve Problems

5. Simplicity

6. Abstraction

7. Serverless

8. 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

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 small functions
● Do one thing well
● Easy to Understand
● Easy to Maintain
● Run on Serverless platform (i.e. abstracted infrastructure)

11. “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

12. “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

13. Avoid

14. Serverless Upsides
● Make development 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. Free The Functions!

19. Open Source Serverless

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 a Function

25. Fn CLI
● fn init --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. Community
.Net core FDK

29. 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

30. No FDK, no problem!

32. Hot functions
● Run at least once
● Wait before terminating
○ Default timeout 30 seconds
○ Configurable
● Potentially reusable
○ FDK handles multiple invocations
○ Stateless remember!?

33. Endpoints
● Fn deploy creates 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
● “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

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. Architecture

38. Request Process

39. Orchestration

40. 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)

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
if fail →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
● Fn Project ⇒ Serverless Platform
○ Open Source
○ Portable
○ Language Agnostic
○ Multiple FDKs
● Feedback and contributions welcome!

48. Get Involved
● Learn more: fnproject.io
● Join the conversation
○ Slack: slack.fnproject.io
○ Twitter: @fnproject
● Contribute: fnproject

49. Thank you!
Ewan Slater
@ewanslater