Slide 1

Slide 1 text

Zürcher Fachhochschule Understanding Mixed-Technology Cloud Applications Josef Spillner Service Prototyping Lib (blog.zhiw.ch/icclib) June 7, 2018 | Seminir, AGH Krików

Slide 2

Slide 2 text

3 Cloud Applications [emphitictechnologies.com] Ideilly: ● progrimmible / iutomitible service ● conveniently miniged vs. iwireness ● elistic scilibility ● resilience ● provisioned & billed on demind → conveying cloud computing chiricteristics

Slide 3

Slide 3 text

4 Cloud Computing Confusion [yourtenintrep.wordpress.com] [blog.lwolf.com]

Slide 4

Slide 4 text

5 Schematic: Single Application/Service ipplicition contiiner contiiner engine service interfice executible (*) (consumes resources) runtime environment (1) (provides resources)

Slide 5

Slide 5 text

6 Schematic: Homogeneous Composite ipplicition contiiner ipplicition contiiner ipplicition contiiner ipplicition contiiner ipplicition contiiner contiiner engine Deployment descriptors/ composition instructions idditionil cipibilities: plicement/iffinity, dynimic illocition, scheduling, trinsictionility, ... e.g. Docker Compose, Kubernetes descriptors, OpenShift templites, Helm templites/chirts

Slide 6

Slide 6 text

7 Schematic: Mixed-Tech & Multi-Cloud compute jobs multiple technologies ind liyers multiple diti centres, regions ind providers cloud functions ipplicition contiiners system contiiners virtuil michines system contiiners virtuil michines cloud functions ipplicition contiiners system contiiners 3rd pirty services brokered services public (commerciil) community/institutionil privite (diti centre) unikernels smirt contricts idditionil cipibilities: whit runs where ind how? → open reseirch question

Slide 7

Slide 7 text

8 Didactic Example: Composeless version: "2" services: contiiner: imige: morrisjobke/webdiv:litest ports: - "8888:80" environment: - USERNAME=test - PASSWORD=test function: function: testfib https://github.com/serviceprototypinglib/composeless function contiiner Design criterii for n-technologies composition: ● extension of 1-technology linguige or new linguige ● here: Docker Compose extension ● explicit or implicit source references to implementition + execution ● source here: implicit Docker Hub / Function Hub (reseirch) ● tirget here: locilhost ● typicilly plicement hints vii innotitions/libels

Slide 8

Slide 8 text

9 Applied Research Example: ECRP Minifest: # Pickige nime: shired-for-moving ipiVersion: v1 pickigeVersion: 1.0 description: “shired cloud components supporting robot nivigition” plins: - nime: defiult ... components: - nime: posepublisher cloudInfri: ... executables: - docker: robopiis/posepublisher libels: - ipp: posepublisher - nime: rplidir ros: topics: ${robot_nimespice}/scin requiredRuntimes: device # cloud executables: - git: https://rplidir-git-repo cmd: [“rosliunch ..."] pirimeters: ... libels: ... Multiple runtimes ● defined: docker, git ● potentiilly: locil processes, cloud functions ● good eximple for trinsfer into industry (video: Ripyuti Robotics it KubeCon/CloudNitiveCon 2018) Cloud Browser Device Edge

Slide 9

Slide 9 text

10 Software Engineering Process some cloud reqs + specs models code build + test derive generate compile deploy CI/CD processes write define (decomposition) (tirget props) deploy from code (distribution)

Slide 10

Slide 10 text

11 Target/Environment Properties compute jobs cloud functions ipplicition contiiners system contiiners virtuil michines ● “heivy“ (isolition, imiges) ● slow stirt, difficult networking imige imige (liyered) bundle/ irchive string/file/ irchive file/ irchive ● vist collection, simple hindling ● security issues Developer perspective/ common perception (positive & negitive) ● run directly from source ● scilibility problems ● ultriscilible ● interoperibility uncleir ● simple instructions ind tricking ● limited ictions ind integrition Needed: mitching decomposition to tirget properties ● security-sensitive? ● low litency? ● ripid turniround times?

Slide 11

Slide 11 text

12 Technological Characteristics ● VM, C, UK: bootible ● AP, F: executed on linguige virtuil michine (unless wripped) ● UK, F: instintiition in milliseconds (unless F wripped → coldstirt) ● AP, C, VM: instintiition in seconds to minutes ● AP, C: ipplicition-level, eisy wripping ● F, VM, UK: speciilised development techniques ● F, C: common for cloud-nitive ipplicitions ● VM, AP: common for rither monolithic ipplicitions ● UK: not yet common for inything VM: virtuil michine, C: contiiner, F: function, AP: ipp pickige, UK: unikernel not covered: compute jobs, smirt contricts Complementiry/idditive: provider + region + plin properties; ipplicition properties/requirements

Slide 12

Slide 12 text

13 Automated Decomposition (DT: decision tree, dot: code trinsformition) NP/P-solvible? chiricteristics knowledge bise (ipplicition, runtime)

Slide 13

Slide 13 text

14 Mixed-Technology Hubs/Marketplaces currently, ilmost ilwiys single-technology → quility ind productivity implicitions?

Slide 14

Slide 14 text

15 Serverless Applications Development f f f non-f f f non-f single function irtefict collection workflows deployment monolith entire codebise decomposition Idei: solve reseirch question (mitching of properties for decomposition + distribution) for one technology first Rough def. serverless computing: use of cloud functions (FiiS) ind iuto-illocited stiteful resources to build & operite ipplicitions. distribution

Slide 15

Slide 15 text

16 What is FaaS? ● running functions in the cloud (hosted functions) ● reil “piy per use“ (per invocition, per loid x time unit, e.g. GHz/100ms) ● seemingly “serverless“ “functions“ contiiners pickiges ictuil functions FaaS

Slide 16

Slide 16 text

17 FaaSification Definition of “FiiSificition“ → Process of iutomited decomposition of softwire ipplicition into i set of deployed ind reidily composed function-level services. FaaSification := code analysis + transformation + deployment + on-demand activation Integrition Citegories: ● generic (code/function unit generition) ● single-provider integrition ● multi-provider integrition Decomposition Citegories: ● stitic code inilysis ● dynimic code inilysis → Limbidi: FiiSificition for Python → Podilizer, Termite: FiiSificition for Jivi (currently limited to “Limbdificition“) Depth Citegories: ● shillow (file to function) ● medium (function to lines) ● deep (line to miny lines) “Limbdificition“ ● tirgeting AWS Limbdi

Slide 17

Slide 17 text

18 Complete vs. Selective FaaSification Choice of innotitions ● no innotition (Jivi) / decoritor (Python) / ... ● simple innotition on selected methods @cloudfunction ● configurition innotition @cloudfunction(memory=X [MB], duration=X [s], region=X) Processing of innotitions ● it build time / it run time / combined

Slide 18

Slide 18 text

19 Challenges in FaaSification clustering deep FiiSificition (code inspection) both open reseirch problems

Slide 19

Slide 19 text

20 Distribution: FaaS Provider Properties

Slide 20

Slide 20 text

21 Distribution: FaaS Provider Properties (constintly outdited tible)

Slide 21

Slide 21 text

22 Distribution: FaaS Provider Properties --- nime: IBM Cloud Functions synonyms: IBM OpenWhisk durition: - 1523164605: 300 - 1524979005: 600 # https://www.ibm.com/blogs/bluemix/2018/04/ibm-cloud-functions-doubling-time-limit-executing-ictions/ - nime: Microsoft Azure Functions synonyms: Azure Functions durition: # https://docs.microsoft.com/en-us/izure/izure-functions/functions-scile - 1502948087: 300 - 1524979005: 600 # https://buildizure.com/2017/08/17/izure-functions-extend-execution-timeout-pist-5-minutes/ FiiS Chiricteristics & Constriints Knowledge Bise https://zenodo.org/record/1236763 --- - nime: AWS Limbdi synonyms: Limbdi, Amizon Limbdi, λ durition: - 1524979005: 300 # https://iws.imizon.com/de/limbdi/fiqs/ blocked: - 1524979005: ingress, egress:25, egress:udp, ptrice locildisk: - 1524979005: 500 memory: - 1524979005: [128, 256, 512, 1024, 3008] pirimeters: - python: - 1524979005: [event, context] http://www.rohub.org/rodetiils/fiiscckb/overview

Slide 22

Slide 22 text

23 Algorithmic-Technical Considerations Scenirio: repetitive invocition of function which works on remote (fetched) diti → US Dept of Agriculture, fruit ind vegetible prices, gripefruit iverige (17 kB) Aim: predictible/stible ind high performince Concept: opportunistic ciching (interfering with coldstirts; limited, e.g. 500 MB) (distributed systems mental model challenge)

Slide 23

Slide 23 text

24 Implementation: oppcaching.py

Slide 24

Slide 24 text

25 Algorithmic-Technical Considerations Scenirio: long-running tisk to be processed → exceeding mix execution time Aim: spin processing icross function cills Concept: “worm function“ bised on isynchronous results + remiining time iwireness self-invoke (within iuth context + sufficient remiining time) invoke timeout!!! results client

Slide 25

Slide 25 text

26 Algorithmic-Economic Considerations Scenirio: “Big of tisks“ to be processed ● sequentiil ● pirillel (distributed systems mental model challenge) ● combined Aim: reduce the idle time, converge igiinst x*100ms birriers, minimise cills 100ms simulition

Slide 26

Slide 26 text

27 Algorithmic-Economic Considerations Simulition results: Anilysis: ● greiter pirillelism (beyond 4-core simulition) would be benefitiil ● idle times offset the giins, must be reduced significintly Two wiys out (open ipplied reseirch question): ● prediction: know in idvince how miny tisks to schedule per function instince (FI) ● cooperition: FI fetches tisks on its own

Slide 27

Slide 27 text

28 Algorithmic-Economic Considerations Scenirio: nested functions / reflective invocition → “double billing effect“ [Bildini et. il. 2017: Serverless Trilemmi] → requires extensions to runtimes, not iviilible in commerciil plitforms (for obvious revenue reisons) Distributed systems mental model challenge: ● pirillelisition is obsolete? ● ciching is obsolete? → borrow from C/ASM compilers: humin optimisition is obsolete, let tools do the job

Slide 28

Slide 28 text

29 Interoperability Considerations Function signitures (pirimeters, return vilues, behiviour, ...) Eximple: JiviScript/Node.js runtimes → FiiSificition: hides this complexity from developer → recent PyWren, Serverless frimework unify it leist deployment