With the rise of Docker, we have seen an unprecedented interest in container technologies where small companies and big enterprises bet their future on these technologies. This trend bases on an immense adoption of containers from software developers. And it has been agreed upon that they are considered highly beneficial for modern engineering practices like Agile and DevOps. But there is a new kid in town that proclaims a more radical approach: Serverless or FaaS: Function-As-A-Service. This paradigm suggests that a developer should only write functions and react to events.
The functions are written in high-level programming languages like Javascript, Java or Python, and the underlying compute infrastructure like containers or VMs is transparent to the user. That raises the question: Is the container revolution already dead before it really started? And who now needs container technologies in a serverless world?
In this talk we discuss these questions from both a containers advocate and serverless fanboy viewpoints. We confront these two approaches, show the differences, individual strengths and weaknesses and where they complement each other. This talk will also discuss motivations from different involved parties so that the audience can build their conclusion.
Vaclav Pavlin (Containers & OpenShift guru): Containers will rule the world!.
Matthias Luebken (Developer tools PM): Serverless is the Visual Basic for the cloud-native generation.
Using IESVE for Loads, Sizing and Heat Pump Modeling to Achieve Decarbonization
Who needs containers in a serverless world
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
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
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
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
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
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...
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
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
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
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