# Introduction

## Credit Last Week’s Demo (Lionel)

* Moving some OpenWhisk’s basic concepts using Kube/Knative providing
* **“Runtime proxy” approach**
  * ***Invisible proxy*** (Docker layer) in runtime to simplify/normalize functionality to functions
  * Mostly ***platform agnostic*** no added code needed" approach
  * ***Parameter passing***, ***Parameter binding***
* **CRD** - that acts as a *basic "controller"*
  * Simplifies Kube/Knative interactions (from CLI)
  * Config mgmt. - binding configs to params for function
  * Launch Knative Services "ksvc” - for named functions
* **Compositions**
  * *Supported by backend (state) were important*
  * *Fundamentally, agreed with "tree/branching" use case (Max), but more…*

## OpenWhisk Approach

### Developer-centric

* ***Everything we do is for** Developer simplicity\*\**
  * ***Developer only codes functions in their chosen language***
    * *No directives | pragmas | annotations*
    * Utilize normal language module/package imports
      * May provide platform callbacks/intrinsic functionality (as functions)
  * ***Developer has NO knowledge of***
    * Operating System (OS)
    * Platform (implementation)
      * *Kube | Knative | Firecracker, etc.*
    * Container (VM tech.)
    * (Micro)Service Framework
  * \_Minimalistic archive “zip” packaging from CLI

### Observer Pattern: Event driven / Reactive

It's all about an eventing framework that scales as fast as possible!

* **Observer pattern** reflected in Programming Model
  * Informs design of control and data plane (for FaaS platform)
* **Reactive**
  * as expected by microservices; these developers will migrate to FaaS
  * moving "up the stack" for the developer... no more Pflask... etc.
  * Cold start reduction is paramount!
* **Event format agnostic**
  * Cannot force everyone to single event format; either impractical to change
    * cannot suffer performance (transforms)...
    * functions are often coupled with specific data (e.g., from IoT sensor events or data sets), e.g.,

      **NASA PIXL**, raw NoSQL data, analytics models, genetic model data)

      * [**NASA Rover PIXL**](https://mars.nasa.gov/mars2020/spacecraft/instruments/pixl/)
* **HTTP / Web accessible without APIs**
  * *functions creating/modifying/serving http `content-type` web data*
* **Edge accessible**
  * IoT events (network response time sensitve)

## Driven by Serverless Use Cases

* Informed by experience of OW and production usage for \~4 years

## Serverless Patterns - Unpredictable, sporadic

* *Even aperiodic embarrassingly parallel workloads*

![Patterns](/files/-M3AJnUc_W-xIWYVgIGP)

### Anti-pattern - High volume, continuous requests

![Anti-patterns](/files/-M3AK7yQAv_rmMqPcNFv)

### Key Use Cases

Reflect the top reasons Developers move "up-the-stack"

* Minimize compute costs (smallest possible per-invocation charge)
  * Manage unpredictability, sporadic loads (events sporadic)
  * Horizontal Scaling to N (up to account limits), to 0

#### Alarm | Periodic

* "batch jobs"

  ![Serverless APIs](/files/-M39T9yK03TOXRSbLEg0)

#### ETL Pipelines

* Changes in Data-at-Rest, Data-in-Motion "trigger" functions

  ![ETL Pipelines](/files/-M39T9yMg5fjb1Go7M6N)

#### Serverless APIs

* OpenAPI, Security, Rate limiting pushed to edge,
* Easily interfaced with host IAM systems

  ![Serverless APIs](/files/-M39T9yOhR2l5_jKHaa9)

#### Embarrassingly parallel workloads

* Time/Cost of additive cold start compute times considerations

  ![Embarrassingly parallel workloads](/files/-M39T9yQKvWpJJThljc4)

## Features NOT covered in today that impact Developer Usability

* Observer pattern (Triggers and Rules)
  * *N Triggers -> 1 Action, 1 Trigger -> N Actions*
* Feed Actions (with Packages)
  * *Using Functions to create Event providers / Feeds*
  * *Alarms, GitHub, NoSQL (Cloudant)*
* APIs – OpenAPI “Swagger” support
  * *Rate Limiting, OAuth, Custom domain names, HTTP Methods*
  * *Binding your own "secure key" token without OpenAPI*
* YAML – deploy  ‘fn deploy’
  * *Packages, Actions, Triggers, Rules, APIs, Parameters (Bindings), Annotations, Client-Server “sync”, +++*
* Compositions
  * *Composer / Conductor (Lionel developer)*
* Logging / Metrics
  * *built-in via File Descriptors in “Go” Proxy*
* Debugging Support
  * *server side, client side (CLI)*
* Docker actions (any binary executable)
  * *Docker SDK*
* Tekton build for OW runtimes
  * *Builds for OpenWhisk or Knative*
* Execution Domain Router *("Kind' Routing)*
  * *OW using Knative, V8 Isolates, Firecracker (runtime concurrency)*
  * *Target: 10K NodeJS invocations in 1 runtime Container*
* Scheduling (pluggable)
  * *General scheduler (default) for all FaaS use cases*
  * *Custom schedulers (for dedicated use cases)*
* Heterogeneous clusters
  * *Pools with diff. Compute CPU/Mem* 


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://mrutkows.gitbook.io/ow-knative-demo/master.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.