This document discusses migrating a legacy application called OpenSense.network to serverless functions. It begins by introducing OpenSense.network and its architecture. Then it describes the migration goals of reducing costs and improving scalability. The migration process involved regression testing, tracing, and identifying performance issues. Several tactics for improving performance during migration are proposed: precomputing values, reusing state, splitting functions, lazily initializing rarely used features, and replacing heavy libraries. The summary concludes that benefits of serverless require effort and automation can help with regression detection.

1. Information Systems Engineering
Sebastian Werner
Jörn Kuhlenkamp
Frank Pallas
Niklas Anders
Nebi Mucaj
Olesia Tsaplina
Christian Schmidt
Kann Yildirim
Information Systems Engineering
TU Berlin
Diminuendo!
Tactics in Support of FaaS Migrations
ESSCA 2020 @ XP2020

2. Page 2
Promising 2nd Generation Cloud Compute Services
Event-based programming model Value Proposition
- Fully-managed operational tasks
- Workload-driven elastic autoscaling
- Efficient resource utilization, e.g., “Scaling-
to-Zero”Queue
Storage
Function
HTTP
…

3. Information Systems Engineering
Page 3
How “easily” can legacy applications benefit from the capabilities of FaaS
platforms?
Approach:
Explorative research by migrating a real-world application on the example of OpenSense.network to
OpenWhisk.
Research Question:

4. Information Systems Engineering
Page 4
„OpenSense.network is designed to collect open data from diverse sources,
including traditional environmental sensing networks like the German
national weather service Deutscher Wetterdienst, as well as participatory
sensing platforms and communities such as luftdaten.info“ [1]
OpenSense.network
GeoSpeical Queries
Time Series Queries
Aggregation Queries
Data Donations
Bulk Imports
User Management
Features
[1] Borges, Maria C., Frank Pallas and Marco Peise. 2018. Providing Open Environmental Data - The Scalable and Web-Friendly Way. In Proceedings of
the 32nd International Conference on Environmental Information and Communication Technologies (EnviroInfo2018)

5. OpenSense.network: Architecture
Relational database
with geospatial capabilities
Scalable time-series database
End Users
Software Services On Premise Deployment
Cassandra Cluster
PostgreSQL + PostGIS
Flask API

6. Page 6
Migration Goals
Free-up underutilized
resources
Serve volatile workloads Reduce operational
overhead

7. Information Systems Engineering
Page 7
Migration Process
Regression
Detection
Identify
Root
Causes
Reevaluate
Done?
Refactor
Naïve
Migration
YES END

8. Information Systems Engineering
Page 8
1. REST-based regression tests
2. Multiple load-testing profiles (bulk-insert, normal)
3. Evaluated request-response-times
4. Added application-level tracing
Regression Detection and Root Cause Analysis
import datetime
…
def handle(event):
topen(“init”)
topen(”flask_init”)
app = create_app(‘default’)
tclose(”flask_init”)
…
inv = invoke(app, event)
…
tclose(”init”)
return inv
*Conceptual example of application-level tracing

9. Information Systems Engineering
Page 9
1. Flask computes the routing
map [Path->Functionality] on
every request
Observations
Container-Run
Code-Run
Cassandra
PostGis
Route
SQL
Ret.
Flask
Cassandra
PostGis
Request-Response Time (Execution View)
This dose not change, we can
compute it once, serialize it and
reuse it every time.
*Representation not based on real measurements, only for visualization purposes.

10. Information Systems Engineering
Page 10
1. Flask computes the routing
map [Path->Functionality] on
every request
2. Cassandra & PostGis
connections are created
every time
Observations
Container-Run
Code-Run
Cassandra
PostGis
Route
SQL
Ret.
Cassandra
PostGis
Request-Response Time (Execution View)
Store state in memory – so we can
reuse it for warm functions
*Representation not based on real measurements, only for visualization purposes.

11. Information Systems Engineering
Page 11
1. Flask computes the routing
map [Path->Functionality] on
every request
2. Cassandra & PostGis
Connections are created
every time
3. Not all request need
Cassandra & PostGis
Observations
Container-Run
Cassandra
PostGis
Route
SQL
Ret.
Request-Response Time (Execution View)
Route
SQL
Ret.
Code-Run
Split into multiple functions
*Representation not based on real measurements, only for visualization purposes.

12. Information Systems Engineering
Page 12
Observations
Container-Run
Cassandra
PostGis
Route
CQL
Ret.
Route
CQL
Ret.
Code-Run
Container-Run
Code-Run
PostGis
Route
SQL
Ret.
Route
SQL
Ret.
Route
SQL
Ret.
1. Flask computes the routing
map [Path->Functionality] on
every request
2. Cassandra & PostGis
connections are created
every time
3. Not all request need
Cassandra & PostGis
*Representation not based on real measurements, only for visualization purposes.

13. Original Architecture
End Users
Software Services On Premise Deployment
Cassandra Cluster
PostgreSQL + PostGIS
Flask API
Page 13

14. FaaS Architecture
End Users
Software Services On Premise Deployment
Cassandra Cluster
PostgreSQL + PostGIS
Multitenant OpenWhisk Cluster
Sensor APIs
MetaData APIs
Page 14

15. 15
5 Migration Tactics
PRECOMPUTE REUSE STRIP BE LAZY REPLACE

16. [Performance Improving] Migration Tactics
PRECOMPUTE
REUSE
Pre-compute if possible and package
it into the deployment package
Reduces start-up time. But, to large
deployment package also negatively
impacts cold-starts.
Re-use state if possible. Try to
combine multiple functions into a
single package.
Reduces latency of warm functions
but creates a more noticeable
differences between warm and cold
starts.
ACTION TRADE-OFFS
STRIP Split functionality if execution paths
don’t share libraries.
Reduces latency for shorter
execution paths. But, creates a larger
deployment and development
overhead.
TACTIC
Page 16

17. Page 17
[Performance Improving] Migration Tactics
BE LAZY
Don’t initialize for rarely used
functionality.
TACTIC ACTION TRADE-OFFS
Reduces latency by not initialize
rarely used libraries. But, creates
noticeable latency for rarely used
functionality.
REPLACE Consider replacing heavy-duty
libraries if you only use a small part
of them.
Reduced start-up time and latency.
Increased development and
maintenance overhead.

18. Information Systems Engineering
Page 18
▪ FaaS benefits are not free, [but must be earned].
▪ Application-level tracing is feasible for regression
detection.
▪ Consider the 5 migration tactics to mitigate regressions.
Future Work:
▪ Increase automation.
▪ Increase FaaS platforms regression detection capabilities.
▪ Introduce lightweight “FaaS-ready” libraries to reduce
regressions.
Summary and Contact Information
Information Systems Engineering
Contact
ISE
{sw,fp,jk}@ise.tu-berlin.de
www.ise.tu-berlin.de
https://www.ise.tu-berlin.de/youtube
https://www.ise.tu-berlin.de/smile