Empfohlen
Empfohlen
Weitere ähnliche Inhalte
Was ist angesagt?
Was ist angesagt? (20)
Ähnlich wie Serverless design with Fn project
Ähnlich wie Serverless design with Fn project (20)
Kürzlich hochgeladen
Kürzlich hochgeladen (20)
Serverless design with Fn project
- 2. @sivachunduru linkedin.com/in/chunduru slideshare.net/sivachunduru 2 $> who am i Siva Rama Krishna Solution Specialist
- 3. Serverless and Fn Project Introduction 3
- 4. Buzz around Serverless ● Serverless is an abstraction of infrastructure and its operations including provisioning, scaling, patching, etc. ● Serverless architecture is when an app is built entirely on Serverless components (compute, storage, networking) ● FaaS is the compute component in a Serverless architecture 4
- 5. Functions - The serverless application programming model 5 In mathematics, a function is a relation between a set of inputs and a set of permissible outputs with the property that each input is related to exactly one output. Function (mathematics) - Wikipedia https://en.wikipedia.org/wiki/Function_(mathematics)
- 6. Characteristics of a Function • Short Running – process live for a short amount of time • Ephemeral – the outer container live for a single invocation • Stateless – does not inherently hold any state • Invoked – by defined events over protocols like HTTP, TCP etc • Single Purpose – have clear & defined purpose with minimal API surface • Autonomous – can run and serve it’s purpose by itself 6 A function packaged in a container gives us a new “atomic unit of computing”
- 7. Atomic Unit – relevant concepts • Functions as Unit of Scaling - Scale Up/Down at much finer grained precision (of single process) than machines - Effective way of scaling of functions coupled with universal packaging/runtime of containers • Functions as Unit of Billing - No baseline on Servers or VMs - Enables huge cost reduction of lightly used applications • Functions as Unit of Design - Functions in containers with their own contract are shareable, so that composite applications can be built and reused - This requires function orchestration tools 7
- 8. The ideal Functions platform • Open Source—no vendor lock-in • Platform Independent—laptop, server, cloud • Approachable—easy for new users, low level controls for advanced users • Docker Based—leverage Docker ecosystem • Scheduler Independent—deploy to Kubernetes, Swarm, Mesos, etc. 8
- 11. 11
- 12. Fn Project - Key Components 12 Fn Server Fn FlowJava FDK
- 13. Fn Project – More and more FDKs 13 FDKs Fn Server Fn Flow
- 14. Example – Hello World A small Java Function 14
- 15. Java Function 15
- 16. Function descriptor – func.yaml 16
- 17. Function deployment – Dockerfile generated 17
- 18. Function deployment process 1. Builds container (multi-stage) + bumps version 2. Pushes container to registry 3. Creates/updates function route (servers lazy load images) 18 MyFunc:0.0.2 MyFunc:0.0.2 MyFunc:0.0.2 Your code Fn Service myfunc → /r/myapp/myfunc:0.0.2 1 2 3
- 19. Hello World Demo Simple Java Function 19
- 22. Fn LB 22 • Simple, fast load balancer that routes functions to certain nodes consistently for hot function efficiency • Scales each function independently based on traffic to any particular function • Can be used to scale Fn servers and infrastructure as well as it has a view of global state of all fn servers
- 23. Request Flow in LB 23
- 24. Fn Server 24 • Handles CRUD operations for setting up routes and functions • Executes sync functions, returning responses to clients immediately • Queues async function calls • Executes async functions when capacity is available • Written in Go, easy to extend via plugin module system
- 25. Request Flow in Fn Server 25
- 26. Supporting services 26 • DB, MQ, blob store are all pluggable modules that are thin wrappers around their respective drivers. – DB: MySQL, sqlite3, Postgres – Queue: Redis, Kafka – Registry: Any Docker v2-compliant, even private • Metrics/Monitoring – OpenTracing API for metrics – Prometheus support, pluggable backends – Logging via syslog
- 27. Metrics and Monitoring 27 Prometheus metrics generated by Fn server, visualized in Grafana
- 30. What is required here? • A coordination service • A state machine • An error handling mechanism • Another language (for composition) and associated tooling • A testing module • A debugging module • A management and orchestration service • A glue code to plumb “response” of one function as “request” to another
- 31. Fn Flow
- 32. An example - Multiple Threads in one JVM in one Container 256px 512px original px 128px resize upload notify notify start resize upload notify resize upload notify upload notify end
- 33. An example - Invoke Seperate Functions 256px 512px original px 128px upload notify notify start upload notify upload notify upload notify end resize resize resize resize 128 resize 256 resize 512
- 34. An example - Invoke Separate Functions 256px 512px original px 128px upload notify notify start upload notify upload notify upload notify end resize resize resize resize 256 resize 128 resize 512 Each function runs in a separate container, resources are automatically obtained
- 35. An example - Invoke Separate Functions When a function completes its resources are deallocated and the calling function thread proceeds 256px 512px original px 128px upload notify notify start upload notify upload notify upload notify end resize resize resize resize 128 resize 512
- 36. An example - Invoke Separate Functions 256px 512px original px 128px upload notify notify start upload notify upload notify upload notify end resize resize resize Each function thread runs until completion
- 37. An example - Invoke Separate Functions 256px 512px original px 128px upload notify notify start upload notify upload notify upload notify end resize resize resize Once all threads are done, a final action is performed
- 38. An example - Invoke Separate Functions When function execution is complete the container is destroyed, freeing resources
- 39. Fn Flow Demo Saga Pattern 39
- 41. Booking Use case
- 44. Possible Metrics – in Prometheus format • Function counts: the # of functions that are currently – queued or are running – have completed successfully or failed since the server was last started • Operation durations: represent the time taken – to perform various operations – to start the docker container in which it runs • Docker metrics: various statistics from that container such as – CPU and memory usage 44
- 45. Monitoring Demo Using Prometheus and Grafana 45
- 46. ● Fn is scheduler agnostic but lots of optimization/management work in process to optimize on Kubernetes ● Helm chart available at https://github.com/fnproject/fn-helm ● Thinking about deeper Kubernetes integrations including CRD’s to model functions Kubernetes support
- 48. Fn Project 48
Hinweis der Redaktion
- Functions are small bits of code that do one thing well and are easy to understand and maintain As a service means no complicated plumbing, the system takes care of provisioning, scaling, patching, maintaining, etc. Each function scales independently.
- Single purpose - meaning it takes a reasonably short input, and provide a reasonably short output. Autonomous - Although it is likely just part of a broader grouping of functions, by itself, it can run independently as long as it gets it’s required input.
- …a lightweight Docker-based serverless functions platform you can run on your laptop, server, or cloud
- OK so have a great way to build small, scalable functions but what do we do when we want to write a more complex app. One that has long-lived workflows and fault cases that we need to handle gracefully? This workflow or composition problem is actually a general one that most serverless applications have once they reach some level of complexity. There are 2 naive approaches: - Write a blocking master function that runs one function, waits for the result, then runs the next etc. This might be easy to understand but we lose a lot of the nice characteristics of a serverless app when we do this. This master function is long-running and consumes resources for the whole time that the individual functions are running. When the booking processes take minutes this can get expensive. It's also not very reliable: if this master function dies then we've got no easy way of recovering. - Chain the next function by directly calling it. This ends up being a maintenance nightmare very quickly as all of a sudden each upstream function has to know about every downstream one so that it can gather and pass the right data down the chain. It's also very difficult to deal with errors. Fan-in / join is tricky. Details: ---------- Built on familiar CompletionStage interface from Java 8 Chain together many functions in an arbitrary graph Fan-out / fan-in, timeouts, exception handling Orchestrate complex workflows in one place Language native function orchestration—natural for developer Java initially with additional language support to follow
- Enter Fn Flow. It occurred to us that Java already has a mechanism for composing asynchronous functions. The CompletionStage API introduced in Java 8 and improved in Java 9 provides a really nice, type-safe promises-style API. This lets us compose a graph of asynchronous computations that lets you specify concurrency, fan-out, fan in and a bunch of other distributed programming primitives. What if could use this API, or something very like it, in our favorite language (Java of course) to compose serverless functions? So we wrote a service (that we call the completer) that can store and trigger the execution of these computation graphs. This is part of the Fn platform and shares the same scalability and reliability properties. We open sourced this along with the rest of the Fn platform. This service backs an API that's almost exactly like CompletionStage that you can use in your Java function to reliably compose other functions. Let's see what it looks like…