Serverless Days Hamburg 2019 - Day 2
Tags: security, aws, serverless
Published: 2019-02-18 10:11:34

---
title: Serverless Days Hamburg 2019 - Day 2
cover_image: https://thepracticaldev.s3.amazonaws.com/i/twt8phtlmw5i1woc9k8g.jpg
published: true
description: report of tech talks at serverless conference
tags: #security, #aws, #serverless
---

[After the workshops yesterday](https://dev.to/dvddpl/serverless-days-hamburg-2019---day-1-workshops-195o) 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](https://theburningmonk.com/2018/01/im-afraid-youre-thinking-about-aws-lambda-cold-starts-all-wrong/) 

- 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](https://theburningmonk.com/2019/01/you-are-thinking-about-serverless-costs-all-wrong/) to know more

![total cost of ownership](https://thepracticaldev.s3.amazonaws.com/i/3gslcxw9fssnu2i2sfrl.jpg)

- Vendor Lock-in
true danger with lockin is the potential for data lockin.
is the return worth the risk.  yes

![but serverless still has servers](https://thepracticaldev.s3.amazonaws.com/i/rx15j98qmq1j0hu8cbcb.png)
**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. 

![serverless chat-ops app](https://thepracticaldev.s3.amazonaws.com/i/zny6olb4lzt4k035i99c.jpg)

--- 

## 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](https://aws.amazon.com/it/xray/)
- [Epsagon](https://epsagon.com/)

### Tools to track frontend errors
[Desole.io](https://desole.io)

More on this topic in [this article](https://medium.freecodecamp.org/the-best-ways-to-test-your-serverless-applications-40b88d6ee31e)

---

## 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](https://github.com/pulumi/pulumi-gcp) 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:

![stateful retrying](https://thepracticaldev.s3.amazonaws.com/i/iokwog2p0q9tpqlf635y.jpg)

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](https://www.google.de/search?q=function+composition+in+a+serverlss+world&oq=function+composition+in+a+serverlss+world&aqs=chrome..69i57.758j0j7&sourceid=chrome&ie=UTF-8) 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](https://en.wikipedia.org/wiki/Fallacies_of_distributed_computing) 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 )

![unexpected outcome](https://thepracticaldev.s3.amazonaws.com/i/7jzw25eem8ehefdymlbc.jpg)

> Grown-ups don't use distributed transactions but eventual consistency

[Life beyond Distributed Transactions:
an Apostate’s Opinion](http://adrianmarriott.net/logosroot/papers/LifeBeyondTxns.pdf) 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](https://github.com/berndruecker/flowing-trip-booking-saga)
[More on Sagas](vasters.com/archive/sagas.html)

---

## 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**)

![serverless test pyramid](https://thepracticaldev.s3.amazonaws.com/i/dkr3troudshpwshutc87.jpg)

### 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.
 
![home brewing process](https://thepracticaldev.s3.amazonaws.com/i/3ht20r5hqsg0q6eplamd.jpg)

He used [a Tilt Based measurement tool](ispindel.de) 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](https://twitter.com/clairikine/status/1096346818647080960) because she is very talented. 
![Cartoonist - Sketchnoter](https://pbs.twimg.com/media/DzcBmlpW0AE5Jis.jpg:large) _sketchnotes by [Clairikine](https://twitter.com/clairikine)_