Understanding Mixed-Technology Cloud Applications

Research seminar, AGH University of Science and Technology, Kraków, Poland, June 2018

1. Zürcher Fachhochschule Understanding Mixed-Technology Cloud Applications Josef Spillner <josef.spillner@zhiw.ch> Service Prototyping Lib (blog.zhiw.ch/icclib) June 7, 2018 | Seminir, AGH Krików
2. 3 Cloud Applications [emphitictechnologies.com] Ideilly: • progrimmible / iutomitible service • conveniently miniged vs. iwireness • elistic scilibility • resilience • provisioned & billed on demind → conveying cloud computing chiricteristics
3. 4 Cloud Computing Confusion [yourtenintrep.wordpress.com] [blog.lwolf.com]
4. 5 Schematic: Single Application/Service ipplicition contiiner contiiner engine service interfice executible (*) (consumes resources) runtime environment (1) (provides resources)
5. 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
6. 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
7. 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
8. 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
9. 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)
10. 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?
11. 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
12. 13 Automated Decomposition (DT: decision tree, dot: code trinsformition) NP/P-solvible? chiricteristics knowledge bise (ipplicition, runtime)
13. 14 Mixed-Technology Hubs/Marketplaces currently, ilmost ilwiys single-technology → quility ind productivity implicitions?
14. 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
15. 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
16. 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
17. 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
18. 19 Challenges in FaaSification clustering deep FiiSificition (code inspection) both open reseirch problems
19. 20 Distribution: FaaS Provider Properties
20. 21 Distribution: FaaS Provider Properties (constintly outdited tible)
21. 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
22. 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)
23. 24 Implementation: oppcaching.py
24. 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
25. 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
26. 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
27. 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
28. 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