Serverless computing allows developers to run code without managing servers. It is billed based on usage rather than on servers. Key serverless services include AWS Lambda for compute, S3 for storage, and DynamoDB for databases. While new, serverless offers opportunities to reduce costs and focus on code over infrastructure. Developers must learn serverless best practices for lifecycle management, organization, and hands-off operations. The Serverless Framework helps develop and deploy serverless applications.
2. @gerardthefox
Content
● What is serverless?
● So what?
● Serverless products / services
● Get a grip
● Approach
● Demo?
● So why not serverless?
3. @gerardthefox
What is serverless?
● Of course there are servers. It's just not your concern, like the solar farm and
national grid aren't for your wall socket.
"serverless" might be a stupid name but it's just a name. (get over it :-)
● Metered (like a utility) by bytes transferred, bytes stored, CPU seconds used.
Not by storage claimed, upper bandwidth, VMs/containers started.
○ S3 object storage, DynamoDB records vs block device / VHD
○ Egress traffic, CDN vs ethernet port, leased line
○ DB query vs installed database cluster size
● Last piece: Compute. AWS Lambda, Google Cloud Function,
Azure Functions, IBM OpenWhisk
○ Pay per GB-second your code runs
4. @gerardthefox
What is serverless? Or where is serverless?
SaaS
Serverless
PaaS
IaaS
On premise
Full stack;)
Power
Datacenter
Compute
Super-/Hypervisor
OS / container
SW stack / middleware / messaging
Business application
Business rules
Business process
9. @gerardthefox
So what?
● You can save a few € by updating older systems to sls
○ but the € 20k vs € 100 cloud bill won't matter that much on the total budget
Bigger, better reasons:
● Opportunity Cost. What you miss out on
https://en.wikipedia.org/wiki/Opportunity_cost
● Transaction Cost. The reason organizations exist
https://en.wikipedia.org/wiki/Transaction_cost
● Jevons Paradox. How higher order systems are created
https://www.cio.com/article/2384346/cloud-computing/what-economists-can-teach-us-about-cloud-computing.html
● FinDev / Why the fuss about serverless?
https://hackernoon.com/why-the-fuss-about-serverless-4370b1596da0
10. @gerardthefox
So what?
The short short version:
Don't do undifferentiated heavy lifting
http://archive.oreilly.com/network/2006/12/20/web-20-bezos.html
11. @gerardthefox
Serverless products & services
Providers:
● AWS: Lambda, S3, DynamoDB, SQS, SNS, Step functions, etc.
● GCP: Cloud functions, Cloud datastore, Cloud Pub/Sub, etc.
● MS Azure: Azure functions, Blob storage, etc.
On your own servers:
● Apache OpenWhisk
● Kubeless
● OpenFaaS
● Fission.io
12. @gerardthefox
Get a grip. The bad news
It's newish (if we ignore /cgi-bin/, cron, et al)
Can't hire "10 years of experience with Lambda in production"
Can't get industry certifications, trainings
No Best Practices™ to ctrl+c ctrl+v
You'll have to do the work yourselves (or ignore, always an option)
13. @gerardthefox
Get a grip. The good news
You're not alone!
While no Best, there are Emerging Practices and Good Practices to put to use
https://serverlessdays.io/
http://serverlessconf.io/
https://serverless.com/
https://github.com/anaibol/awesome-serverless
And people blog, present, open source, and otherwise share all over the web
15. @gerardthefox
Approach - commit
Yes, you are locking yourself in. Maybe more so than otherwise, maybe less so.
Do the risk assessment. Accept it. Commit to it.
What is the risk of AWS pulling an *racle and raising prices 2000%?
What is the risk of AWS discontinuing a service on short notice?
What is the risk of not moving up? What if your competitors do move up?
Back to the economics of it.
18. @gerardthefox
Approach - standardization
You say: we standardized on Java EE! (or Docker, or Node.js, or ...)
You think people hear: we made a decision! we have things under control! We
benefit from specialization, efficiencies of scale! we're building an ecosystem!
People hear: we make you eat soup with a knife!
19. @gerardthefox
Approach - lifecycle
Built in lifecycle mgmt
● Your app could be killed after milliseconds.
It can be started from scratch at any time.
Initialize fast. Think light
● Your app could be running for hours.
Check if it already initialized. Clean up temp files. Memory mgmt (nullify
references)
● Your first deploy is not "done", it's the beginning.
Deploy, update, discontinue. Make functions / API versioned
20. @gerardthefox
Approach - lifecycle
Built in lifecycle mgmt
● Lifecycle policies for storage. S3 object storage, SQS queues, DB records.
● Phoenix data centers. Recycle your cloud account. Blue/green cloud
accounts. Also an excellent BCP exercise
21. @gerardthefox
Approach - organization
● Compartmentalize (or dare I say... containerize! )
○ Map your system, Wardley mapping
○ Systems, processes, etc. get only one team as
the owner
● You built it, you run it
○ No handoffs. Devops / product team model
○ Freedom + responsibility
● Right size
○ 5, 6 people to a team
https://hackernoon.com/my-basics-for-mapping-a-business-5b20f364b216
https://queue.acm.org/detail.cfm?id=1142065
22. @gerardthefox
Approach - organization
● Right size
○ Bundle related FE functions in 1 git repo, BE functions in another git repo
● Automate
○ Use CI/CD to track, create and deploy
○ CD is the only thing that changes production, try for the other environments too
23. @gerardthefox
Approach - hands off
There is no SSH/RDP'ing in, attaching debuggers/tracers/profilers
Not logging in on production servers was a good practice, now not even an option
Apply your 12-factor, devops, µ-service, etc. practices:
● Log shipping Usually built into the platform. Format your logs in JSON
● Metrics shipping Same.
● Correlation IDs Forward them to the next step. HTTP headers, tags
● Distributed tracing (X-Ray, OpenTracing)
https://12factor.net/
https://hackernoon.com/capture-and-forward-correlation-ids-through-different-lambda-event-sources-220c227c65f5
24. @gerardthefox
Approach - attitude with some platitudes
'If everything seems under control, you're not going fast enough.' - Mario Andretti
MTTR > MTBF
Continuous improvement is better than delayed perfection - Mark Twain
Responding to change over following a plan
"Testing" in production, aka monitoring, observability
https://www.kitchensoap.com/2010/11/07/mttr-mtbf-for-most-types-of-f/
https://en.wikipedia.org/wiki/Continual_improvement_process
http://agilemanifesto.org/
https://opensource.com/article/17/8/testing-production
28. @gerardthefox
So why not serverless?
● Limited available features. Might not fit your use case (cold start latency,
runtime, memory, price, etc)
● Limited available features. Might not fit your organization's current way of
working "we make you eat soup with a knife"
● Metered. Might not fit your organization's budgeting and invoicing
● Few providers. Might not fit your organization's policies or regulatory
requirements e.g. no foreign providers. no providers under US control. running a full serverless stack in your own datacenter
likely not worth the effort vs VMs/containers
● ...
29. @gerardthefox
Serverless (or insert-better-name-here-please-kthxbye)
Do's Don'ts
Recognize as important part of compute-as-utility Ignore
Commit (after due diligence) Half arse it
Maintain a set of standards Set single standard, or set no standards
Lifecycle mgmt Feature factory
Product teams Waterfall, handoffs, and silos
Automate, CI/CD Ambachtelijke IT. Artisanal creative handicraft IT
Apply Agile Apply methods created for other contexts
