After the workshops yesterday today is the day of the Talks!
Hamburg welcomes us with a chilly morning with sun and bluebird sky. The venue is already crowded and we enjoy the delicious breakfast buffet.
After visiting the sponsors' booths and gather every possible gadget my colleagues and I take our seats in the second row.
Laptop open, ready to start and take notes - GO!:
Debunking serverless myths - Yan Cui
Since I started my journey into AWS and Serverless I have been an avid reader of everything Yan Cui published on his blog https://theburningmonk.com/, therefore, I was pretty excited and really looking forward to seeing his KeyNote.
In his talk he decided to share his experience and knowledge talking about some of the false beliefs about serverless that can be read often in blogposts and tutorial all over the web:
-
cold starts happen only when Lambda is called the first time
truth: the first invocation on a container will be a cold start, so coldstarts will always happen every time there are concurrent calls that require a new container to be spawned.
With steady traffic cold start are not really an issue. If your app traffic experiences peaks/spikes (lunchtime, football matches etc) cold starts will happen anyway because of concurrency. Therefore we must do all possible to reduce startup duration:- trim dependencies
- have a single purpose - one lambda should do only one thing ( so less dependency to do its job)
- VPC adds up to 10 secs. Use them only when strictly necessary - lambda is already secured by IAM roles and policies.
more on this topic here
- serverless is expensive truth: since when compared to on-premises solution many costs are not considered ( like costs of hiring dev-ops engineers : expertise is both rare and expensive ) the Total Cost of Ownership of the 2 solutions is not really comparable. Serverless could - and often is - less expensive. But depends on the use case. Controlling infrastructures comes with responsibility and costs See this article to know more
- Vendor Lock-in true danger with lockin is the potential for data lockin. is the return worth the risk. yes
It is serverless the same way WiFi is wireless (Gojko Adzic)
devops & serverless with aws / how serverless can help chat-ops become reality - Selina Magnin
Characteristic of serverless:
- fully managed service
- rapid development
- pay as you go
- auto scaling
Dev-ops processes
- automation first
- simple interaction
- use familiar tools
- multitenancy first
She showed how they used many different AWS services ( among others LEX - a language processor for chatbots) to build a CI/CD Tool integrated with Slack.
Designing testable serverless app with hexagonal architecture - Slobodan Stojanovic
Again some thoughts about Vendor-Lockin:
what we are really talking about is not being really locked-in with a vendor, rather how much it will cost to switch to another provider. (same thing would happen when switching frameworks or language)
Hexagonal Architecture also known as Port and Adapter is a model for designing applications where logic is isolated by its integration. Since with Serverless the Integration part becomes more important (imagine a NodeJs REST API built with Express - the resources/routes are handled in the code, while with AWS API Gateway and Lambda resources are defined in the Gateway and each route might have its own lambda).
integrations can change everytime
tests don't prevent changes. they make sure your changes are not accidental
How ?
- handler does not much. just parse input and define dependencies.
- main logic is injected with dependencies and parameters. on that we can run integration tests with mocked dependencies, like an in memory db.
- the dependencies ( ie mongo-integration.js) will have their own integration tests with the real service.
beforeAll()
{
// dynamoDB create Table
// wait for table create
// pass to test context
}
afterAll () {
// destroy table
}
for those things you cant test, make sure you have monitoring and alarms!
Tools to track backend errors
Tools to track frontend errors
More on this topic in this article
Building stateful applications with serverless - Tiru Marai
Patterns for delegating state
- full context in payload: we are delegating the state to the event management
- use managed services aka serviceful serverless : Twilio - Algolia - Auth
- run lightweight long running proxies: (standalone connection pooler for databases)
- apply state externally: code is statelss, state is applied on output.
- use fast transactional databases
what people usually mean by stateless is idempotency
stateless == idempotency but idempotency => stateless
if you can ensure idempotency our stateful function seems like stateless function.
Serverless is more than you think - Michael McDonald
This was a lightning talk of 8 minutes held by Firebase / Google Product Manager sharing interesting things he has been working / playin with recently like Pulumi and [Serverless containers]
Lost in transaction - Strategies to manage consistency in serverless architectures - Bernd Rücker
This was one of the most interesting and intense talk of the day.
I will definitely dig more in the topics he touched and maybe write a dedicated post. For now, I just drop here my notes plus some reading suggestions:
If we have long chains of operations / transactions these are the possible approaches:
- Merged functions
- Choreography :
- Chained functions
- Event chain
- Orchestration:
- Coordinator functions (long running functions)
- Workflow (intermediate component)
read more about function composition in a serverlss world
Key concepts
- Leverage stateful retries
- Idempotent functions
- All or nothing. Functions are independent, but when one of them fail - rollback everything
read more about fallacies of distributed computing
A C I D
- Atomicity
- Consistency
- Isolation
- Durable
we forfeit C and I for Availability graceful degradation and performance**
B A S E
- Basically available
- Soft state
- Eventual consistency
Available Strategies when somthing goes wrong
- Distributed transaction
- Compensating transactions ( abort / rollback app level )
- Apologies ( detect and fix constraint violations )
Grown-ups don't use distributed transactions but eventual consistency
Life beyond Distributed Transactions:
an Apostate’s Opinion by Pat Helland
SAGA Pattern / compensation as strategy
Event driven Choreography
- very easy to lose the idea of the flow
- in case of changes in the process you have to adjust all service and redeploy at the same time
Orchestration
- AWS Step functions ( serverless plugin to describe the steps )
- BPMN ( graphical way --> xml)
Serverless commmunities - Michael Oshita
Lightning talk from this guy flew in from Japan to tell us about the Serverless Community in Japan and provide useful info on how to make a tech community grow.
Security: the serverless future - Gabbi Fisher
This code was about a Cloudfront solution that allows to execute on Cloudfront edge:
- network based serverless
- serveless workers
- run FaaS on the edge
Escape the lock in - Christoph Neijenhuis
Again some thoughts about Vendor-Lockin:
The lock-in occurs only when the cost to switch provider is too high. This cost is expressed by the time required to refactor your implementation.
Serverless functions from AWS Azure and Google Cloud share same fundamental concepts but proprietary APIs are quite different.
define a unified api, and use adapters for proprietary api.
use hexagonal architecture
structure code so that logic is isolated and use adapters for handlers of each cloud provider. Mostly it is just the event / context and input data that are passed differently from one vendor to another.
can an adapter be written for a given product?
- yes if simple and features are similar across providers ( like blob storage, key value store )
- nope for Function Orchestration or Api Gateways or advanced database features..
Serverless Testing - Avishai Shafir
When moving to serverless architecture the component / integration layer of the test pyramid becomes wider and more important (pyramid loos like more a mayan pyramid)
Testing approaches
Local
We can use Serverless framework or SAM to run test locally.
Those tests are fast - cheap - easier to debug but configuration might be different and not everything can be mocked
Hybrid
Some services ( like cognito and DB ) are tested on the cloud. More reliable than mocking or mimicking locally and costs to run tests are still minimal
Cloud
Production like
Of course you incurr in costs but they are still minimal to the production costs and you will save lots of time on the development/debugging costs.
Deploy time is longer and debugging harder.
It is important to automate and deploy only what changed in the architecture not the entire stack.
Again some thoughts about the costs:
128 mb memory took 11 seconds cost 0.0243
1gb memory took 1,5 seconds cost 0.248
** lower memory take longer therefore end up paying same **
Recap:
- check configuration
- add tracer id / correlation id to track components and help debugging tracer.io
- test on cloud. in long run save times and money. because its more similar to production
- use Lambda layer if large packages
- use Serverless Artillery to run load tests (be carefull with load tests on production since you might occur in limitation when afdterwards your product is live and used by users.
- split environments to avoid mess
Zen and art of beer fermentation observability - Ilia Lybin
Funny and interesting talk where he describe is Pet Project.
He combined his passion for home-brewing with serverless solutions and built an App to monitor Beer fermentation and be notified when it's ready.
He used a Tilt Based measurement tool and then sent data every 2 seconds to a REST Api to insert data in DynamoDB, used DynamoStreams to aggregate some data and Cloudwatch + Simple Notification Service to be notified.
He also mentioned the costs of this project - which had hundred of thousands of ApiGateway/Lambda/DynamoDb invocations: about 5 € a month..
Besides all the talks we have seen, i would really like to mention the girl sitting in the first row, just ahead of me, that while i was typing like crazy on my laptop taking notes, was calmly drawing the most interesting and funniest parts of each presentation. I approached her and she turned out to be a cartoonist / sketchnoter and i really suggest you take a look at her twitter account because she is very talented.
sketchnotes by Clairikine
Top comments (0)