Davide de Paolis

Posted on Feb 18, 2019

Serverless Days Hamburg 2019 - Day 2

#security #aws #serverless

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.

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

XRAY
Epsagon

Tools to track frontend errors

Desole.io

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)

Example Repo
More on Sagas

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

DEV Community