The document discusses the roles of containers and serverless architectures, emphasizing that both have unique advantages and can complement each other. It outlines the characteristics of serverless computing, such as its event-driven nature and cost efficiency, while also highlighting the flexibility and architectural diversity containers provide. The authors advocate for a hybrid approach using tools like Apache OpenWhisk to leverage the benefits of both paradigms.

1. Who needs containers in a
serverless world?
Vasek Pavlin & Matthias Luebken
@vpavlin & @luebken

2. Talk history
● 2017:
○ July https://www.meetup.com/de-DE/Bonn-Agile/events/240782503/
○ September:
https://www.codetalks.de/de/2017/programm/who-needs-containers-in-a-
serverless-world
Work in
Progress

4. ● serverless = faas & backend services
● pro container:
○ you can achieve similar characteristics with containers
○ containers are more versatile
○ they enable different architectures: monolith, µservices, faas
○ BTW containers are the enabling infrastructure
● pro serverless:
○ opinionated architecture
○ focus on writing application logic
○ precise cost based pricing powers new architectures
● OpenWhisk to the rescue
tl;dr

5. Outline
● Intro
● Setting the context
● What is serverless?
● Developers’ Workflow
● Opinion time: Serverless Camp vs Container Camp
● OpenWhisk
● Open discussion & demos

6. @vpavlin & @luebken

8. App

9. Mr. Developer

10. Two sides of the same coin
Development Infrastructure

11. Containers in Infrastructure
● Preferred solution even for serverless
● Like VMs without all the VMs shortcomings (cough..)
● Brings new shortcomings:)
● Generally awesome, great, terrific, everyone loves it
BUT...

12. Two sides of the same coin
Development Infrastructure

13. What is serverless?

15. Defining serverless
● BaaS: Backend-As-A-Service
○ Off-the-shelf services
○ Popular in Mobile (MBaaS)
○ On different levels e.g.:
Authentication, Messaging, Databases,
Speech / Text Analysis ...
● FaaS: Function-As-A-Service
○ App logic in small functions
○ Event driven

18. 5 common traits
1. Does not require managing a long-lived server
or application instance
2. Self auto-scales and auto-provisions, based on load
3. Offers costs based on precise usage
up from and down to zero usage
4. Has performance capabilities defined in terms other than
host size / count
5. Has implicit high availability
http://bit.ly/symph-defining-1 by @mikebroberts

19. A typical serverless architecture on AWS
user client
S3: static
artefacts
Cognito
User
Authentication
API
gateway
S3: cache
Lambda
function
Cloud Watch
Logs / Metrics
SNS
Event
Lambda
function
External
APIs
Route 53
DNS

20. Error response
Triggered by an
(HTTP) event
Try to get data from
cache
Publish event for
missing data
Return JSON payload

21. TODO: Sum up how great serverless is

22. Serverless & Containers
Developers’ workflow

23. Developers’ Workflow

24. Developers’ Workflow - Write Code
● Use IDE of choice
○ You can try VS Code with plugins (interesting links: this or this or this)

25. Developers’ Workflow - Build
● Ideally “one click” solution
Containers
● Dockerfile
● Source To Image
● Ansible Container
● Draft
● ...
Serverless
● Zip:)

26. Developers’ Workflow - Run
● Locally or Remotely?
Containers
● docker run …
● docker-compose up
● oc cluster up && oc new-app ...
Serverless
● serverless invoke local
● serverless offline

27. Developers’ Workflow - Test
● Unit? Integration? Acceptance? Local? Remote? Automated?
Containers
● There are projects
● Generally it is just another
container
Serverless
● Unit testing is important
● Integration & Acceptance testing
over unit testing

28. Developers’ Workflow - Deploy
● Automate the hell out of it!
Containers
● Build is the same as in dev or test
● You’ll need orchestration
○ Kubernetes
○ OpenShift
○ Mesos
○ Swarm
○ …
● There are CI integrations
Serverless
● Serverless Framework
● Now

29. Opinion Time
Serverless
Camp
Containers
Camp

30. The “serverless architectural style”
● Serverless is opinionated:
○ Ephemeral application logic
○ State in backing services
○ Everything is distributed
You can rebuild it with container technologies.
● Limitations for this style:
○ Less options for managing state
○ Latency between components
○ Local development / testing
● Sometimes less is more. Limited options may drive productivity and change.

31. Managed vs Control
● You can host your own serverless platform
but note serverless leverages economy of scale
● Most orgs will choose some cloud vendor and give up control
So, how important is control to you?
● Ops is different with serverless

32. Old vs new
● Serverless is immature
Implementation, tooling, bugs, vendor
lockin
● Container ecosystem is huge
● Containers are just Linux

33. So ?

34. Matthias: “Serverless is the greatest enabler”
● No costs for not running code is just mind blowing
● Serverless made me think differently:
○ APIs
■ What other APIs are others providing?
■ What can I expose as an API?
○ Modular
■ Does my function do too much?
○ Event driven
■ What are good domain events?
And it’s fun.

35. Vašek: “Containers give you freedom”
● Containers give freedom
○ Have you ever given freedom to developers? ;)
● You need to think on scale
● Orchestration is king
● It does not take traditional “ops” tasks away
● It was fun last 3 years, now it’s just work...

36. What if you could have both?

37. Apache OpenWhisk
● http://openwhisk.org/
● GA : Feb 2016 from IBM
● Red Hat joined Jun 2017
● License : ASL v2
● Polyglot : NodeJS, Swift, Python, Java, PHP +
Docker
● Event Sources : BlueMix services, Watson,
Cloudant, other SaaS
● BlueMix Cloud Functions Pricing : $0.000017
GB-s
● Event Sequencing, Parameter Binding

38. OpenWhisk Architecture

39. OpenWhisk
You can:
● use any interpreted language natively
● use any other language by wrapping code in container
● run on Kubernetes/OpenShift (i.e. scale)
Let me show you...

40. ● serverless = faas & backend services
● pro container:
○ you can achieve similar characteristics with containers
○ containers are more versatile
○ they enable different architectures: monolith, µservices, faas
○ BTW containers are the enabling infrastructure
● pro serverless:
○ opinionated architecture
○ focus on writing application logic
○ precise cost based pricing powers new architectures
● OpenWhisk to the rescue
tl;dr

41. Thanks for listening
@vpavlin @luebken
visit:
● developers.redhat.com
● openshift.io

42. Appendix

43. Lambda
11 / 2014
Cloud
Functions
02 / 2016
Azure
Functions
03 / 2016
OpenWhisk
02 / 2016
Amazon Google MicrosoftIBM
The Big 4 FaaS providers
JavaScript,
Python,Java,C#
JavaScript JavaScript, Swift,
Docker
JavaScript, C#,
F#, Python, PHP
Apache

44. Funktion
More OpenSource

45. More proprietary platforms
webtask

46. The Rails for serverless architectures
.com

47. Lessons learned on getting with serverless on AWS
● Get familiar with console.aws.amazon.com
● Create / update functions with a simple wrapper e.g. https://apex.run/
● Don’t start with higher level abstractions
● Check https://acloud.guru/ for tutorials

48. OpenWhisk

49. Vocabulary
● Trigger: An Event such as an incoming HTTP request
● Rule: Map a trigger to an action
● Action: A function, optionally with parameters
● Package: A collection of actions and parameters
● Sequence: Several actions in a row

50. Create an & invoke an action
function main() {
console.log('Hello World');
return { hello: 'world' };
}
$ wsk action create myAction action.js
$ wsk action invoke myAction --result
$ wsk action invoke myAction --blocking

51. Attic

52. What is container and why? (low-level)
● It’s not virtualisation, but it is a (lightweight) virtualisation
○ Starts in milliseconds
● A process encapsulation tech
● We love them because of portability
○ Works here, works there (not really, but..)
● Containers are like functions
○ they don’t matter in prod, orchestration does

53. How do you encapsulate code? (low-level)
● Dockerfile (or Buildah)
○ Boring shell script
● S2I - https://github.com/openshift/source-to-image
○ Smart way of automatically getting your code in container

54. Containers rock because… (getting higher)
● Local development and testing is easy
○ docker run -v $PWD:/code …
○ docker run … make test
○ docker compose up …, oc cluster up ...
● There are many existing and supported containers out there
○ https://access.redhat.com/containers
● There are many (mature) tools to orchestrate them
○ OpenShift, Kubernetes, Mesos, Swarm
● Containers are universal
○ Web app, embedded, hardware specific...

55. Container orchestration (high-level)
● One container is useless, many containers is hard
● OpenShift/Kubernetes
○ Scale, HA, Hybrid Cloud, Security, Service Discovery, CI/CD, Stateless
○ You can manage your backend service or use external ones
○ On premise matches hosted
● You can try your orchestration locally
○ Docker Swarm
○ Kubernetes
○ OpenShift