5. Agenda
• The concept
• Serverless vs FaaS
• Tooling
• Demo
• Cri7cism
• My experience with customer projects
5
6. What is "serveless"
• Serverless is about abstrac0ng away servers, infrastructure and
having to deal with low-level configura0on or the core opera0ng
system
• Code is not run as a full applica0on, but a set of small func0ons
• Next step a@er using containers
6
11. IT-Marke)ng term of the year?
Companies are looking for ways to brand their offerings as
serverless
11
12. Why call it "serverless"?
• It's a bad choice
• The server does not go away
• It gets even more abstracted than with a VM or a container
• Is there a be9er term?
12
14. Let's look at what serverless is trying
to achieve
14
15. Lower opera)ons burden
• Fewer people
• Leaner teams
• Lower cost
• Be2er security
• Be2er resilience
15
16. It's about
• No maintenance
• Micro func0onality
• Simplicity, but is not necessarily simpler
• Rethinking code
16
17. Faster (me to market
Less to build = higher feature velocity
17
18. Focus on business value
What we’re talking about is outsourcing parts of our architecture
and implemen8on that are not core to delivering business value
- Ben Kehoe, iRobot
18
19. Compute in a system should not be
required to be con3nually-living
19
21. A persistent compu.ng resource is
a server no ma2er what form that
resource takes
21
22. Serverless is not FaaS
• Func&on as a Service (FaaS)
• FaaS is an integral component of serverless architecture
22
23. Func%on as a Service (FaaS)
• Deploy any individual piece of code, or func3on
• Code runs and returns a value, in turn ending the process
• Services and endpoints you would keep in one place are now
sliced up into a bunch of snippets
• Goal is to abstract away servers from the developer and bill
based on the amount of 3mes the func3ons were invoked
23
25. Serverless is not event-driven compute
• "Serverless is all about the events" = wrong
• Event-driven compu;ng is a natural fit for serverless
architectures
• Possible and reasonable to build tradi;onal data flows in
serverless
25
27. FaaS is not always F
• Containers can be FaaS
• Container have a stronger "contract" with the developer
• S8ll, decouples developer from pla=orm
• If container run during invoca8ons, and then are frozen/recycled,
the container is ac8ng as a func8on
27
29. FaaS is not always aaS
• Serverless is not just public cloud
• You can be your own FaaS provider
• For big enterprises this makes sense
• Can enable rest of company to "do" serverless
• By running a lot of servers with so@ware on them
29
31. A be%er term?
• Service-Full
• Coined by Patrick Debois, Townheroes
• h=ps://twi=er.com/patrickdebois
31
32. Service-Full
• As a applica*on becomes increasingly serverless, it relies more
on external services to provide the building blocks of the system
• E.g. using Amazon Elas*csearch Service (AES) instead of hos*ng
Elas*csearch yourself
• 12 factor apps
• Immutable infrastructure
32
34. Service-Full FaaS
• FaaS applica*on on cluster using on-premise servers
• FaaS applica*on on cluster using public cloud IaaS
• FaaS applica*on on managed cluster (e.g. Google Container
Engine)
• Managed FaaS
• That are serverless if they use ephemeral compute resources
34
35. FaaS does not have to use
ephemeral compute resources
35
44. Public billing model
• Pay-per-use pricing model
• Pay nothing at idle (except for data at rest)
• Know what part of your applica<on costs the most
44
46. Summing up
• Spectrum
• Serverless != FaaS
• Service-full + ephemeral compute
• Tighter correspondence between resources used and resources
billed
• Smaller and more abstracted control plane
46
48. Reasons
• Easy scaling
• Low maintenance
• Any applica4on you have in produc4on where your user
throughput varies is a valid contender
• Response 4me is not your first concern
48
50. Lastly, if you suck at the Linux shell,
and if DevOps is not your thing, you
have every reason to try Serverless.
- Adnan Rahić, Hackernoon
50
51. Requires us to change our approach
• Serverless architecture is "special"
• Se1ng it up takes a fair share of mental power
• Live with the fact that we do not have overview of our whole
system
51
55. AWS Lambda
• Event based system for running code in the cloud
• "No servers"
• Just code
• Scales automa;cally
• Easy to integrate into CI/CD pipelines
55
56. AWS Lambda Docs say
• It takes )me to set up a container and do the necessary
bootstrapping, which adds some latency each )me the Lambda
func)on is invoked.
• You typically see this latency when a Lambda func)on is invoked
for the first )me or a@er it has been updated because AWS
Lambda tries to reuse the container for subsequent invoca)ons
of the Lambda func)on.
h"p://docs.aws.amazon.com/lambda/latest/dg/lambda-
56
57. How it works
• Lambda maintains the container for some 2me in an2cipa2on of
another Lambda func2on invoca2on
• It freezes the container a8er a Lambda func2on completes
• If no further requests occur, it destroys the container
57
63. The Serverless Framework
Serverless is your toolkit for deploying and opera4ng serverless
architectures. Focus on your applica4on, not your infrastructure.
— serverless.com
63
64. The Serverless Framework
• Removes the manual component of interac4ng with AWS
Lambda / API Gateway
• Node NPM package you control through the command line
• bundles all the tools you need into a manageable package
• Simplifies crea4on and deployments of applica4ons
64
66. Be-Nice API
• Setup a simple data processing pipeline
• Expose one HTTP endpoint that allows use to submit a text note
• The message is processed in the background
• Messages above a certain sen>ment level are "saved"
66
67. Sen$ment
• AFINN-based sen.ment analysis for Node.js
• Returns score for a specific string
var sentiment = require('sentiment');
var r1 = sentiment('Cats are stupid.');
console.dir(r1); // Score: -2, Comparative: -0.666
var r2 = sentiment('Cats are totally amazing!');
console.dir(r2); // Score: 4, Comparative: 1
67
68. AFINN
AFINN is a list of English words rated for valence with an integer
between minus five (nega<ve) and plus five (posi<ve). The words
have been manually labeled by Finn Årup Nielsen in 2009-2011.
The file is tab-separated.
h"p://www2.imm.dtu.dk/pubdb/views/publica6on_details.php?
id=6010
68
69. We also use Amazon SNS
• Amazon Simple No/fica/on Service (SNS)
• Fully managed pub/sub messaging and mobile no/fica/ons
service
• publish-subscribe mode / retries
• Is an event that can trigger a func/on for us
• Helps us "unblock" ephemeral compute resources
69
73. Step 1: Installing serverless
Have NodeJs installed on your worksta4on
$ npm install -g serverless
73
74. Step 2: Create an IAM User in your AWS
Console
• Have an AWS account
• Create an IAM user with programma:c access
• Add permissions according to whatever you want that user to do
• Get Access Key ID and Secret Access Key
74
75. Step 3: Tie your creden1als to serverless
$ serverless config credentials --provider aws --key xxxxxxxxxxxxxx --secret xxxxxxxxxxxxxx
Serverless: Setting up AWS...
Serverless: Saving your AWS profile in "~/.aws/credentials"...
Serverless: Success! Your AWS access keys were stored under the "default" profile.
75
84. What happens during a deployment
• CloudForma+on is used to orchestrate all this
• It creates an S3 (AWS data store) bucket and stores the code in it
• Creates IAM role (permissions) for the func+on
• API Gateway gets created
• Logging
84
87. How we use it in the wild
• ChatOps
• Empowering Devs to manage their own stuff on AWS with min.
permissions
• Alexa Skills / FAQ Bot
• Personally: Mobile API prototype
87
88. This means we can get rid of Ops
altogehter, right?
88
90. DevOps does not go away
• Infrastructure management is not the only task that DevOps is
doing
• Automa;on, deployment, tes;ng, security, and monitoring
90
91. Ops won’t go away in serverless
• Serverless compu.ng is a form of u.lity compu.ng
• Infrastructure completly abstracted from the developer
91
93. Main problems for developers
• Monitoring, debugging, tes0ng, latency, deployment
• Basically everything you need Ops for
93
94. How to test locally?
Serverless offline plugin
h"ps://github.com/dherault/serverless-offline
94
95. We observed some pa-ers
• First, there is a genuine concern about cloud provider lock-in
• Second, there is a desire and hope to avoid or at least minimize
such lock-in by embracing open source abstrac<ons and
pla=orms
• Most notably Docker and Kubernetes
95
96. Complex applica,ons
• An experiences Java Dev may not work on an applica7on with
"just a few func7ons"
• It sounds like a lot of extra work to move something like this into
FaaS
96
97. Architectural complexity
• Tiny func*ons are nice from an architectural standpoint
• Isn't the complexity moved to somewhere else?
• Isn't complex code moved into complex configura*on?
• AWS Lambda, for now, limits you to how many concurrent
execu*ons you can be running of all your lambdas
97
98. That means if someone, somewhere,
in your organiza4on does a load test
and starts trying to execute 1000
concurrent Lambda func4ons you’ll
Denial of service (DoS) your
produc4on applica4ons
98
99. You can probably guess my standpoint
• If you run something that complex, Lambda is not the right
choice
• You should think about running your own FaaS cluster
• FaaS != Public cloud offerings
99
100. Vendor lock-in
• If that complex configura4on is proprietary, aren't we walking
into a venor lock-in?
• Unexpected limits / cost changes
• This is true for IaaS and PaaS as well
100
102. Control
• Dependent on vendors for debugging and monitoring tools
• At least your team will have these tools now ;)
102
103. Integra(on tes(ng is #1
• The units of integra0on with Serverless are a lot smaller
• Integra0on tes0ng becomes your #1 concern here
103
104. Ar#facts
• Problems related to deployment, versioning and packaging also
exist
• You may need to deploy a FaaS ar<fact separately for every
func<on in your en<re logical applica<on
104
105. Does every func-on start a new container?
• Sounds like a lot of used resources
• How does this affect startup 7mes?
105
107. What I would use it for
• Applica(on Prototypes (e.g. for StartUp ideas)
• Applica(ons in produc(on (if not (me sensi(ve)
• Microservices
• Bots
• Orchestra(on and maintenance
• Repor(ng
107
108. What I would not use it for
• Monoliths
• Anything were every milisecond counts
108