serverless computing

• IBM, Google and Lyft give microservices a ride on the Istio Service Mesh

Today, IBM and Google announced the launch of Istio, an open technology that provides a way for developers to seamlessly connect, manage and secure networks of different microservices—regardless of platform, source or vendor.

Istio is the result of a joint collaboration between IBM, Google and Lyft as a means to support traffic flow management, access policy enforcement and the telemetry data aggregation between microservices

Its design, however, is not platform specific. The Istio open source project plan includes support for additional platforms, including CloudFoundry, VMs.

Key Istio features

    Automatic zone-aware load balancing and failover for HTTP/1.1, HTTP/2, gRPC, and TCP traffic.

    Fine-grained control of traffic behavior with rich routing rules, fault tolerance, and fault injection.

    A pluggable policy layer and configuration API supporting access controls, rate limits and quotas.

    Automatic metrics, logs and traces for all traffic within a cluster, including cluster ingress and egress.

    Secure service-to-service authentication with strong identity assertions between services in a cluster.

How does Istio work?

Improved visibility into the data flowing in and out of apps, without requiring extensive configuration and reprogramming.

Istio converts disparate microservices into an integrated service mesh by introducing programmable routing and a shared management layer. By injecting Envoy proxy servers into the network path between services, Istio provides sophisticated traffic management controls such as load-balancing and fine-grained routing. This routing mesh also enables the extraction of a wealth of metrics about traffic behavior, which can be used to enforce policy decisions such as fine-grained access control and rate limits that operators can configure. Those same metrics are also sent to monitoring systems. This way, it offers improved visibility into the data flowing in and out of apps, without requiring extensive configuration and reprogramming to ensure all parts of an app work together smoothly and securely.

https://developer.ibm.com/dwblog/2017/istio/

• Istio

a platform, including APIs that let it integrate into any logging platform, or telemetry or policy system.
completely open source service mesh that layers transparently onto existing distributed applications.
lets you successfully, and efficiently run a distributed micro-service architecture, and provides a uniform way to secure, connect, and monitor micro-services.
operators are managing extremely large hybrid and multi-cloud deployments.
Developers must use micro-services to architect for portability
Istio helps reduce the complexity of these deployments and eases the strain on your development teams.
Istio lets you connect, secure control, and observe services.

What is a service mesh?
Istio addresses the challenges developers and operators face as monolithic applications transition towards a distributed micro-service architecture
The term service mesh is used to describe the network of micro-services that make up such applications and the interactions between them.
Its requirements can include discovery, load balancing, failure recovery, metrics, and monitoring.
A service mesh also often has more complex operational requirements, like A/B testing, canary releases, rate limiting, access control, and end-to-end authentication.

Why use Istio?
create a network of deployed services with load balancing, service-to-service authentication, monitoring, without any changes in service code.
add Istio support to services by deploying a special sidecar proxy throughout your environment that intercepts all network communication between micro-services, then configure and manage Istio using its control plane functionality
Automatic load balancing for HTTP, gRPC, WebSocket, and TCP traffic.
Fine-grained control of traffic behavior with rich routing rules, retries, failovers, and fault injection.
Automatic metrics, logs, and traces for all traffic within a cluster, including cluster ingress and egress.
Secure service-to-service communication in a cluster with a strong identity-based authentication and authorization

Core features
Traffic management
control the flow of traffic and API calls between services
configuration of service-level properties like circuit breakers, timeouts, and retries
tasks like A/B testing, canary rollouts, and staged rollouts with percentage-based traffic splits

Platform support
Istio is platform-independent and designed to run in a variety of environments, including those spanning Cloud, on-premise, Kubernetes, Mesos, and more.
You can deploy Istio on Kubernetes, or on Nomad with Consul.
Service deployment on Kubernetes
Services registered with Consul
Services running on individual virtual machines

Architecture
An Istio service mesh is logically split into a data plane and a control plane.
The data plane is composed of a set of intelligent proxies (Envoy) deployed as sidecars. These proxies mediate and control all network communication between microservices along with Mixer, a general-purpose policy and telemetry hub.
The control plane manages and configures the proxies to route traffic. Additionally, the control plane configures Mixers to enforce policies and collect telemetry.

https://istio.io/docs/concepts/what-is-istio/

• What is a service mesh?

Istio addresses the challenges developers and operators face as monolithic applications transition towards a distributed microservice architecture. 

The term service mesh is used to describe the network of microservices that make up such applications and the interactions between them. As a service mesh grows in size and complexity, it can become harder to understand and manage. Its requirements can include discovery, load balancing, failure recovery, metrics, and monitoring. A service mesh also often has more complex operational requirements, like A/B testing, canary releases, rate limiting, access control, and end-to-end authentication.

Why use Istio?

Automatic load balancing for HTTP, gRPC, WebSocket, and TCP traffic.

Fine-grained control of traffic behavior with rich routing rules, retries, failovers, and fault injection.

A pluggable policy layer and configuration API supporting access controls, rate limits and quotas.

Automatic metrics, logs, and traces for all traffic within a cluster, including cluster ingress and egress.

Secure service-to-service communication in a cluster with strong identity-based authentication and authorization.

Security

Istio’s security capabilities free developers to focus on security at the application level. Istio provides the underlying secure communication channel, and manages authentication, authorization, and encryption of service communication at scale. While Istio is platform independent, using it with Kubernetes (or infrastructure) network policies, the benefits are even greater, including the ability to secure pod-to-pod or service-to-service communication at the network and application layers.

https://istio.io/docs/concepts/what-is-istio/

• Integrating Calico and Istio to Secure Zero-Trust Networks on Kubernetes


the ZTN model means not allowing access to anyone unless they are authenticated and their request to a specific network resource has been authorized. ZTN builds on the following principles:


    Networks should always be assumed to be hostile.
    External and internal threats exist on the network at all times.
    Network locality is not sufficient for gaining trust.
    Every device, user, and workflow should be authenticated and authorized.
    Network policies must be dynamic and calculated from as many sources of data as possible


How can Calico and Istio help?
Calico is an open-source project designed to remove the complexities surrounding traditional software-defined networks and securing them through simple policy language in YAML. Calico is compatible with major cloud platforms, such as Kubernetes, OpenStack, Amazon Web Services, and Google Compute Engine.
Calico’s implementation of the Kubernetes Network Policy API enables granular selection and grouping. Policies are configured based on Kubernetes labels.


Istio, another open-source project, resides on the concept of a service mesh by installing an Envoy sidecar proxy as close as possible to an application. This enables management of both the proxy and the application.In the context of security, Istio provides authentication and encryption through mutual TLS—where both client and server use certificates to verify identity—and cryptographic certificates issued to each serviceAccount.


https://www.altoros.com/blog/integrating-calico-and-istio-to-secure-zero-trust-networks-on-kubernetes/
• What’s a service mesh? And why do I need one?

A service mesh is a dedicated infrastructure layer for making service-to-service communication safe, fast, and reliable. If you’re building a cloud native application, you need a service mesh.In practice, the service mesh is typically implemented as an array of lightweight network proxies that are deployed alongside application code, without the application needing to be aware.

WHAT IS A SERVICE MESH?

The concept of the service mesh as a separate layer is tied to the rise of the cloud native application. In the cloud native model, a single application might consist of hundreds of services; each service might have thousands of instances; and each of those instances might be in a constantly-changing state as they are dynamically scheduled by an orchestrator like Kubernetes.

IS THE SERVICE MESH A NETWORKING MODEL?

The service mesh is a networking model that sits at a layer of abstraction above TCP/IP. It assumes that the underlying L3/L4 network is present and capable of delivering bytes from point to point. 

Just as the TCP stack abstracts the mechanics of reliably delivering bytes between network endpoints, the service mesh abstracts the mechanics of reliably delivering requests between services.

Like TCP, the service mesh doesn’t care about the actual payload or how it’s encoded.

The application has a high-level goal (“send something from A to B”), and the job of the service mesh, like that of TCP, is to accomplish this goal while handling any failures along the way.

WHAT DOES A SERVICE MESH ACTUALLY DO?

A service mesh like Linkerd manages this complexity with a wide array of powerful techniques: circuit-breaking, latency-aware load balancing, eventually consistent (“advisory”) service discovery, retries, and deadlines.

Linkerd can also initiate and terminate TLS, perform protocol upgrades, dynamically shift traffic, and fail over between datacenters.

WHY IS THE SERVICE MESH NECESSARY?

Consider the typical architecture of a medium-sized web application in the 2000’s: the three-tiered app. In this model, application logic, web serving logic, and storage logic are each a separate layer.The communication between layers, while complex, is limited in scope—there are only two hops, after all. There is no “mesh”, but there is communication logic between hops, handled within the code of each layer.

When this architectural approach was pushed to very high scale, it started to break. 

Companies like Google, Netflix, and Twitter, faced with massive traffic requirements

the application layer was split into many services (sometimes called “microservices”), and the tiers became a topology.

In these systems, a generalized communication layer became suddenly relevant, but typically took the form of a “fat client” library—Twitter’s Finagle, Netflix’s Hystrix, and Google’s Stubby being cases in point.

In many ways, libraries like Finagle, Stubby, and Hystrix were the first service meshes.

The cloud native model combines the microservices approach of many small services with two additional factors: containers (e.g. Docker), which provide resource isolation and dependency management, and an orchestration layer (e.g. Kubernetes), which abstracts away the underlying hardware into a homogenous pool.

THE FUTURE OF THE SERVICE MESH

The requirements for serverless computing (e.g. Amazon’s Lambda) fit directly into the service mesh’s model of naming and linking, and form a natural extension of its role in the cloud native ecosystem. 

https://blog.buoyant.io/2017/04/25/whats-a-service-mesh-and-why-do-i-need-one

• What Cilium and BPF will bring to Istio

How is Istio related to Cilium?
Istio abstracts away a lot of networking specific complexity and provides visibility and control to application teams. We couldn't agree more with the move of networking to Layer 7 and the concept to provide the necessary instruments for efficient operation at the application protocol layer.

What is Cilium?

Cilium comes in the form of a networking plugin and thus integrates at a lower level with the orchestration system. Cilium and Istio share a common goal though, both aim to move visibility and control to the application protocol level (HTTP, gRPC, Kafka, Mongo, ...)

Cilium uses a combination of components to provide this functionality:

    An agent written in golang that runs on all nodes to orchestrate everything. This agent is integrated with orchestration systems such as Kubernetes.
    A datapath component that utilizes the BPF (Berkley Packet Filter) functionality in the Linux kernel for very efficient networking, policy enforcement, and load balancing functionality.
    A set of userspace proxies, one of them is Envoy, to provide application protocol level filtering while we are completing the in-kernel version of this. More on this below.

Can I run Cilium alongside Istio?
It is perfectly fine to run Cilium as a CNI plugin to provide networking, security, and loadbalancing and then deploy Istio on top.

How will Istio benefit from Cilium?
We are very excited about BPF and how it is changing how security and networking are done with Linux.

Why is the In-kernel proxy faster than not running a proxy at all?
When changing how to approach a problem. Completely new solutions often present themselves. One of them is what we call socket redirect. The in-kernel proxy is capable of having two pods talk to each other directly from socket to socket without ever creating a single TCP packet. This is very similar to having two processes talk to each other using a UNIX domain socket. The difference is that the applications can remain unchanged while using standard TCP sockets.

The difference in the two lines between "No Proxy" and "Cilium In-Kernel" is thus the cost of the TCP/IP stack in the Linux kernel.

How else can Istio and Cilium benefit from each other?

    Use of Istio Auth and the concept of identities to enforce the existing Cilium identity concept. This would allow enforcing existing NetworkPolicy with the automatically generated certificates as provided by Istio Auth.
    Ability to export telemetry from Cilium to Istio.
    Potential to offload Istio Mixer functionality in Cilium

https://cilium.io/blog/istio/

• Cilium: Making BPF Easy on Kubernetes for Improved Security, Performance

BPF is basically the ability of an application developer to write a program, load that into the Linux kernel, then run it when certain events happen — when a network packet is being received or a system call is being made, when a certain system function is being called. Then this small program can enforce security policies, collect information and so on. It’s basically making the Linux kernel programmable

I wouldn’t say we compete with Istio, we complement each other,” he said. “Cilium is the ideal data path, data layer, beneath Istio. We provide the best performance possible. If you want to run Istio, we can reduce the overhead and make it minimal. A service mesh runs security policy in a sidecar inside of the application pod. That means if that pod gets compromised, the sidecar is compromised as well. We can provide a safety net outside of that.”

https://thenewstack.io/cilium-making-bpf-easy-on-kubernetes-for-improved-security-performance/

• GitOps Workflows for Istio Canary Deployments

Traditionally you may have had two almost identical servers: one that goes to all users and another with the new features that gets rolled out to only a set of users.

by using GitOps workflows, your canary can be fully controlled through Git.
If something goes wrong and you need to roll back, you can redeploy a stable version all from Git.
An Istio virtual gateway allows you to manage the amount of traffic that goes to both deployments.
With both a GA and a canary deployed, you can continue to iterate on the canary release until it meets expectations and you are able to open it up to 100% of the traffic.

GitOps Workflows for the continuous deployment to Istio:
An engineer fixes the latency issue and cuts a new release by tagging the master branch as 0.2.1
GitHub notifies GCP Container Builder that a new tag has been committed
GCP Container Builder builds the Docker image, tags it as 0.2.1 and pushes it to to Quay.io (this can be any container registry)
Weave Cloud detects the new tag and updates the Canary deployment definition
Weave Cloud commits the Canary deployment definition to GitHub in the cluster repo
Weave Cloud triggers a rolling update of the Canary deployment
Weave Cloud sends a Slack notification that the 0.2.1 patch has been released

Once the Canary is fixed, keep increasing the traffic to it and shift the traffic from the GA deployment by modifying the weight setting and committing those changes to Git.
With each Git push and manifest modification, Weave Cloud detects that the cluster state is out of sync with desired state and will automatically apply the changes.

If you notice that the Canary doesn't behave well under load, revert the changes in Git.Weave Cloud rolls back the weight setting by applying the desired state from Git on the cluster.
You can keep iterating on the canary code until the SLA is on a par with the GA release.
https://www.weave.works/blog/gitops-workflows-for-istio-canary-deployments

• The World’s Most Popular Open Source Microservice API Gateway

Invoke serverless functions via APIs.
Kong is a scalable, open source API Layer (also known as an API Gateway, or API Middleware). Kong runs in front of any RESTful API and is extended through Plugins, which provide extra functionality and services beyond the core platform.
https://konghq.com/kong-community-edition/

• What are containers?

Containers are an executable unit of software in which application code is packaged, along with its libraries and dependencies, in common ways so that it can be run anywhere, whether it be on desktop, traditional IT, or the cloud.
To do this, containers take advantage of a form of operating system (OS) virtualization in which features of the OS (in the case of the Linux kernel, namely the namespaces and cgroups primitives) are leveraged to both isolate processes and control the amount of CPU, memory, and disk that those processes have access to.
Containers are small, fast, and portable because unlike a virtual machine, containers do not need include a guest OS in every instance and can, instead, simply leverage the features and resources of the host OS.

Containers vs. VMs
Instead of virtualizing the underlying hardware, containers virtualize the operating system (typically Linux) so each individual container contains only the application and its libraries and dependencies. The absence of the guest OS is why containers are so lightweight and, thus, fast and portable.

Benefits
Lightweight: Containers share the machine OS kernel, eliminating the need for a full OS instance per application and making container files small and easy on resources.
Portable and platform independent: Containers carry all their dependencies with them, meaning that software can be written once and then run without needing to be re-configured across laptops, cloud, and on-premises computing environments.
Supports modern development and architecture: such as DevOps, serverless, and microservices—that are built are regular code deployments in small increments.

Containerization
Software needs to be designed and packaged differently in order to take advantage of containers—a process commonly referred to as containerization.When containerizing an application, the process includes an application with its relevant environment variables, configuration files, libraries, and software dependencies. The result is a container image that can then be run on a container platform

Container orchestration
container orchestration emerged as a way managing large volumes of containers throughout their lifecycle, including:
    Provisioning
    Redundancy
    Health monitoring
    Resource allocation
    Scaling and load balancing
    Moving between physical hosts
While many container orchestration platforms (such as Apache Mesos, Nomad, and Docker Swarm) were created to help address these challenges, Kubernetes quickly became the most popular container orchestration platform, and it is the one the majority of the industry has standardized on.


Docker and Kubernetes
Kubernetes, created by Google in 2014, is a container orchestration system that manages the creation, operation, and termination of many containers.
Docker turns program source code into containers and then executes them, whereas Kubernetes manages the configuration, deployment, and monitoring of many containers at once (including both Docker containers and others).

Istio, Knative, and the expanding containers ecosystem
the ecosystem of tools and projects designed to harden and expand production use cases continues to grow
Istio
As developers leverage containers to build and run microservice architectures, management concerns go beyond the lifecycle considerations of individual containers and into the way that large numbers of small services—often referred to as a “service mesh”—connect with and relate to one another. Istio was created to make it easier for developers to manage the associated challenges with discovery, traffic, monitoring, security
Knative
Knative’s big value is its ability to offer container services as serverless functions.
Instead of running all the time and responding when needed (as a server does), a serverless function can “scale to zero,” which means it is not running at all unless it is called upon. This model can save vast amounts of computing power when applied to tens of thousands of containers.

https://www.ibm.com/cloud/learn/containers

• What Is AWS Lambda?

AWS Lambda is a compute service that lets you run code without provisioning or managing servers
You can also build serverless applications composed of functions that are triggered by events and automatically deploy them using AWS CodePipeline and AWS CodeBuild.
https://docs.aws.amazon.com/lambda/latest/dg/welcome.html

• AWS Lambda lets you run code without provisioning or managing servers. You pay only for the compute time you consume - there is no charge when your code is not running.

With Lambda, you can run code for virtually any type of application or backend service - all with zero administration. Just upload your code and Lambda takes care of everything required to run and scale your code with high availability. You can set up your code to automatically trigger from other AWS services or call it directly from any web or mobile app
https://aws.amazon.com/lambda/

• Distributed Data Pre-processing using Dask, Amazon ECS and Python

Data Engineers and Data Scientists often use tools from the python ecosystem such as Numpy and Pandas to analyze, transform and visualize their data which are designed to be high performance, intuitive and efficient libraries. Performing such operations on a small dataset in a fast and scalable manner is not challenging as long as the dataset can fit into the memory of a single machine. However, if the dataset is too big and cannot fit into a single machine, Data Engineers may be forced to rewrite their code into more scalable tools such as Spark and SparkML that can be computationally supported by a big EMR cluster.
https://towardsdatascience.com/serverless-distributed-data-pre-processing-using-dask-amazon-ecs-and-python-part-1-a6108c728cc4

• Build highly scalable applications on a fully managed serverless platform

App Engine enables developers to stay more productive and agile by supporting popular development languages and a wide range of developer tools.

Google App Engine (often referred to as GAE or simply App Engine) is a web framework and cloud computing platform for developing and hosting web applications in Google-managed data centers.

Applications are sandboxed and run across multiple servers.App Engine offers automatic scaling for web applications—as the number of requests increases for an application, App Engine automatically allocates more resources for the web application to handle the additional demand

https://cloud.google.com/appengine/

Your First Serverless Microservice on AWS

Intro to Serverless Computing

• Serverless computing is a cloud-computing execution model in which the cloud provider acts as the server, dynamically managing the allocation of machine resources. Pricing is based on the actual amount of resources consumed by an application, rather than on pre-purchased units of capacity.

It is a form of utility computing.
Utility computing, or The Computer Utility, is a service provisioning model in which a service provider makes computing resources and infrastructure management available to the customer as needed, and charges them for specific usage rather than a flat rate.

The name "serverless computing" is used because the server management and capacity planning decisions are completely hidden from the developer or operator. The serverless code can be used in conjunction with code deployed in traditional styles, such as microservices. Alternatively, applications can be written to be purely serverless and use no provisioned servers at all

Most, but not all, serverless vendors offer to compute runtimes, also known as function as a service (FaaS) platforms, which execute application logic but do not store data.

Serverless computing is not suited to some computing workloads, such as high-performance computing, because of the resource limits imposed by cloud providers, and also because it would likely be cheaper to bulk-provision the number of servers believed to be required at any given point in time.

https://en.wikipedia.org/wiki/Serverless_computing

• What is serverless computing?

Serverless computing allows you to build and run applications and services without thinking about servers. With serverless computing, your application still runs on servers, but all the server management is done by AWS. At the core of serverless computing is AWS Lambda, which lets you run your code without provisioning or managing servers. Learn more about serverless computing by visiting here.
https://aws.amazon.com/lambda/faqs/

• Fission is a framework for serverless functions on Kubernetes.

Write short-lived functions in any language, and map them to HTTP requests (or other event triggers). Deploy functions instantly with one command. There are no containers to build, and no Docker registries to manage.
https://fission.io/

• FaaS use cases

Web apps, Backends, Data/stream processing, Chatbots, Scheduled tasks, IT Automation

In other words, serverless aims to do exactly what it sounds like — allow applications to be developed without concerns for implementing, tweaking, or scaling a server (at least, to the perspective of a user).

Instead of scaling a monolithic REST server to handle potential load, you can now split the server into a bunch of functions which can be scaled automatically and independently.

https://medium.com/@BoweiHan/an-introduction-to-serverless-and-faas-functions-as-a-service-fb5cec0417b2

• OpenFaaS® (Functions as a Service) is a framework for building Serverless functions with Docker and Kubernetes which has first-class support for metrics. Any process can be packaged as a function enabling you to consume a range of web events without repetitive boiler-plate coding.

https://github.com/openfaas/faas

• Function as a service (FaaS) is a category of cloud computing services that provides a platform allowing customers to develop, run, and manage application functionalities without the complexity of building and maintaining the infrastructure typically associated with developing and launching an app.

Building an application following this model is one way of achieving a "serverless" architecture, and is typically used when building microservices applications.

Comparison with PaaS application hosting services
Serverless computing architectures in which the customer has no direct need to manage resources can also be achieved using Platform as a Service services. These services are, however, typically very different in their implementation architecture, which has some implications for scaling. In most PaaS systems, the system continually runs at least one server process and, even with auto scaling, a number of longer running processes are simply added or removed on the same machine. This means that scalability is a more visible problem to the developer

In a FaaS system, the functions are expected to start within milliseconds in order to allow handling of individual requests. In a PaaS system, by contrast, there is typically an application thread which keeps running for a long period of time and handles multiple requests. This difference is primarily visible in the pricing, where FaaS services charge per execution time of the function whereas PaaS services charge per running time of the thread in which the server application is running.

Use Cases
Use cases for FaaS are associated with "on-demand" functionality that enables the supporting infrastructure to be powered down and not incurring charges when not in use. Examples include data processing (e.g., batch processing, stream processing, ETL), IoT services for Internet-connected devices, mobile applications, and web applications.
https://en.wikipedia.org/wiki/Function_as_a_service

• Nuclio Serverless Functions

Nuclio is an open source serverless platform which allows developers to focus on building and running auto-scaling applications without worrying about managing servers.
https://nuclio.io/

• The Serverless Framework – Build applications comprised of microservices that run in response to events, auto-scale for you, and only charge you when they run. 

https://github.com/serverless/serverless

• What are event-driven programming and serverless computing?

Event-driven programming follows a paradigm in which the flow of an application is determined by events such as user actions, sensor outputs, or messages from other applications or services.
Serverless computing refers to a model where the existence of servers is simply hidden from developers. I.e. that even though servers still exist developers are relieved from the need to care about their operation.
What problems does OpenWhisk solve? What can you do with OpenWhisk?
OpenWhisk abstracts away all infrastructure and operational concerns, allowing developers to solely focus on coding. As part of that abstraction, you no longer need to worry about peak projections or capacity planning as OpenWhisk scales on demand based on the volume and velocity of your events’ requests
https://openwhisk.apache.org/faq.html

• Apache OpenWhisk (Incubating) is a serverless, open source cloud platform that executes functions in response to events at any scale.

https://openwhisk.apache.org/

• Microservice architectures have emerged as the preferred way to engineer robust, scalable cloud-native solutions. Microservices hold application logic in small, loosely coupled distributed services, communicating through language-agnostic APIs.

Despite the benefits, microservice-based solutions are hard to build using mainstream cloud technologies, which often require you to control a complex toolchain and build/operations pipeline.
As a result, developers spend too much time dealing with infrastructure and operational complexities like fault-tolerance, load balancing, auto-scaling, and logging features.
OpenWhisk can help to power various mobile, web and IoT use-cases; for example, it can enable mobile developers to interface with backend logic running in a cloud without installing server-side middleware or infrastructure.
https://developer.ibm.com/code/open/projects/openwhisk/

• Introducing Serverless Composition for IBM Cloud Functions

Mobile Backend Development
Serverless could help developers better decouple front and backend development by helping enterprises create serverless microservices with API backends.
Data Processing
Data processing is a very dominant field for serverless, no matter the platform, and that’s also a key use case trend for OpenWhisk. In particular, image processing, or other tasks like noise reduction in sound files, are most common
Cognitive Processing
Similar to the data processing scenario is cognitive processing, where OpenWhisk is used in conjunction with IBM Watson ML algorithms to perform some cognitive tasks on a multimedia file
Streaming Analytics
He described an integration with Kafka and Bluemix where data posted in Kafka can immediately start being analyzed.
Internet of Things
Nauerz pointed to Abilisense as one business that is using Watson and OpenWhisk in combination to manage an IoT messaging platform for people with hearing difficulties.

GreenQ is optimizing waste disposal truck routes in Tel Aviv, estimating that by using serverless architecture to keep track of the truck locations, weigh waste bins, and analyze photos of waste bin contents, they can calculate optimal routes, lower city carbon emissions and create municipal cost savings of up to 50 percent.

https://www.ibm.com/blogs/bluemix/2017/10/serverless-composition-ibm-cloud-functions/

•  Knative as an open source platform. It supports containers, a form of packaged applications that run in cloud environments. Knative runs on top of the Kubernetes container orchestration system, which controls large numbers of containers in a production environment.

 Kubernetes is a complex product that needs a lot of configuration to run properly. Developers must log into individual worker nodes to carry out repetitive tasks, such as installing dependencies and configuring networking rules. They must generate configuration files, manage logging and tracing, and write their own CI/CD scripts using tools like Jenkins. Before they can deploy their containers, they have to go through multiple steps to containerize their source code in the first place.

Knative helps developers by hiding many of these tasks, simplifying container-based management and enabling you to concentrate on writing code. It also supports for serverless functions

Knative consists of three main components: Build, Serve, and Event.

Build

The Build component of Knative turns source code into cloud-native containers or functions. 

Serve

Knative offers a Serve component that runs containers as scalable services. Not only can it scale containers up to run in the thousands, but it can scale them down to the point where there are no instances of the container running at all.

The first is configuration, which lets you create different versions of the same container-based service. Knative lets these different versions run concurrently,

The second feature is service routing.You can use Knative's routing capabilities to send a percentage of user requests to the new version of the service, while still sending most other requests to the old one. 

Eve

The Event component of Knative enables different events to trigger their container-based services and functions.

Benefits

Faster iterative development: 

Focus on code:

Quick entry to serverless computing:

What challenges does Knative solve?

Knative's benefits can help solve a variety of real-world challenges facing today's developers, including the following:

CI/CD set up

Easier customer rollouts

Serverless

Serverless computing is a relatively new way of deploying code that can help make cloud-native software even more productive. Instead of having a long-running instance of your software waiting for new requests (which means you are paying for idle time), the hosting infrastructure will only bring up instances of your code on an "as-needed" basis.

Knative breaks down the distinction between software services and functions by enabling developers to build and run their containers as both

Istio

Knative's serving component incorporates Istio help manage tiny, container-based software services known as microservices.

Istio provides a routing mechanism that allows services to access each other via URLs in what's known as a service mesh. 

It's essentially a switchboard for the vast, complex array of container-based services that can quickly develop in a microservice environment. 

Knative uses Istio’s service mesh routing capabilities to route calls between the services that it runs.

Istio manages authentication for service requests and automatic traffic encryption for secure communication between services.

It can also gather detailed metrics about microservice operations to help developers and administrators plan infrastructure optimization.

https://www.ibm.com/cloud/learn/knative?cm_mmc=OSocial_Youtube-_-Watson+and+Cloud+Platform_Cloud+Platform-_-WW_WW-_-KnativeYTdescription&cm_mmca1=000023UA&cm_mmca2=10005900

• Serverless Open-Source Frameworks: OpenFaaS, Knative, & More

The main advantage of this technology is the ability to create and run applications without the need for infrastructure management.
In other words, when using a serverless architecture, developers no longer need to allocate resources, scale and maintain servers to run applications, or manage databases and storage systems. Their sole responsibility is to write high-quality code.
There have been many open-source projects for building serverless frameworks (Apache OpenWhisk, IronFunctions, Fn from Oracle, OpenFaaS, Kubeless, Knative, Project Riff, etc).

OpenWhisk, Firecracker & Oracle FN

Apache OpenWhisk is an open cloud platform for serverless computing that uses cloud computing resources as services. Compared to other open-source projects (Fission, Kubeless, IronFunctions), Apache OpenWhisk is characterized by a large codebase, high-quality features, and the number of contributors. However, the overly large tools for this platform (CouchDB, Kafka, Nginx, Redis, and Zookeeper) cause difficulties for developers. In addition, this platform is imperfect in terms of security

Firecracker is a virtualization technology introduced by Amazon.Firecracker offers lightweight virtual machines called micro VMs, which use hardware-based virtualization technologies for their full isolation while at the same time providing performance and flexibility at the level of conventional containers.The project was developed at Amazon Web Services to improve the performance and efficiency of AWS Lambda and AWS Fargate platforms.

Oracle Fn is an open-server serverless platform that provides an additional level of abstraction for cloud systems to allow for Functions as Services (FaaS). As in other open platforms in Oracle Fn, the developer implements the logic at the level of individual functions. Unlike existing commercial FaaS platforms, such as Amazon AWS Lambda, Google Cloud Functions, and Microsoft Azure Functions, Oracle’s solution is positioned as having no vendor lock-in.

Kubeless is an infrastructure that supports the deployment of serverless functions in your cluster and enables us to execute both HTTP and event switches in your Python, Node.js, or Ruby code. Kubeless is a platform that is built using Kubernetes’ core functionality, such as deployment, services, configuration cards (ConfigMaps), and so on.

Fission is an open-source platform that provides a serverless architecture over Kubernetes. One of the advantages of Fission is that it takes care of most of the tasks of automatically scaling resources in Kubernetes, freeing you from manual resource management. The second advantage of Fission is that you are not tied to one provider and can move freely from one to another, provided that they support Kubernetes clusters (and any other specific requirements that your application may have).

Main Benefits of Using OpenFaaS and Knative
OpenFaaS and Knative are publicly available and free open-source environments for creating and hosting serverless functions
These platforms allow you to:

        Reduce idle resources.
        Quickly process data.
        Interconnect with other services.
        Balance load with intensive processing of a large number of requests.


How to Build and Deploy Serverless Functions With OpenFaaS
OpenFaaS is a Cloud Native serverless framework and therefore can be deployed by a user on many different cloud platforms as well as bare-metal servers.The main goal of OpenFaaS is to simplify serverless functions with Docker containers, allowing you to run complex and flexible infrastructures.There are installation options for Kubernetes and Docker Swarm.Docker is not the only runtime available in Kubernetes, so others can be used.

Function Watchdog
Almost any code can be converted to an OpenFaaS function. If your use case doesn’t fit one of the supported language templates then you can create your own OpenFaaS template using the watchdog to relay the HTTP requests to your code inside the container.

all developed functions, microservices, and products are stored in the Docker container, which serves as the main OpenFaaS platform for developers and sysadmins to develop, deploy, and run serverless applications with containers.

The Main Points for Installation of OpenFaaS on Docker
You can install OpenFaaS to any Kubernetes cluster, whether using a local environment, your own datacenter, or a managed cloud service such as AWS EKS
For running locally, the maintainers recommend using the KinD (Kubernetes in Docker) or k3d (k3s in Docker) project. Other options like Minikube and microk8s are also available.


Pros and Cons of OpenFaaS
In other words, OpenFaaS allows you to run code in any programming language anytime and anywhere.


OpenFaaS uses container images for functions
    Each function replica runs within a container, and is built into a Docker image.
    There is an option to avoid cold starts by having a minimum level of scale such as 20/100 or 1/5
    Scaling to zero is optional, but if used in production, you can expect just under a two-second cold-start for the first invocation
    The queue-worker enables asynchronous invocation, so if you do scale to zero, you can decouple any cold-start from the user


Deploying and Running Functions With Knative
Knative allows you to develop and deploy container-based server applications that you can easily port between cloud providers

Building
The Building component of Knative is responsible for ensuring that container assemblies in the cluster are launched from the source code. This component works on the basis of existing Kubernetes primitives and also extends them.
Eventing
The Eventing component of Knative is responsible for universal subscription, delivery, and event management as well as the creation of communication between loosely coupled architecture components. In addition, this component allows you to scale the load on the server.
Serving
The main objective of the Serving component is to support the deployment of serverless applications and features, automatic scaling from scratch, routing and network programming for Istio components, and snapshots of the deployed code and configurations. Knative uses Kubernetes as the orchestrator, and Istio performs the function of query routing and advanced load balancing.


Example of the Simplest Functions With Knative
Your choice will depend on your given skills and experience with various services including Istio, Gloo, Ambassador, Google, and especially Kubernetes Engine, IBM Cloud, Microsoft Azure Kubernetes Service, Minikube, and Gardener.

Pros and Cons of Knative
Like OpenFaaS, Knative allows you to create serverless environments using containers. This in turn allows you to get a local event-based architecture in which there are no restrictions imposed by public cloud services.
Both OpenFaaS and Knative let you automate the container assembly process, which provides automatic scaling. Because of this, the capacity for serverless functions is based on predefined threshold values ​​and event-processing mechanisms.
In addition, both OpenFaaS and Knative allow you to create applications internally, in the cloud, or in a third-party data center. This means that you are not tied to any one cloud provider.

One main drawback of Knative is the need to independently manage container infrastructure. Simply put, Knative is not aimed at end-users.
It is worth noting that these platforms can not be easily compared because they are designed for different tasks.
From the point of view of configuration and maintenance, OpenFaas is simpler. With OpenFaas, there is no need to install all components separately as with Knative, and you don’t have to clear previous settings and resources for new developments if the required components have already been installed.

https://epsagon.com/tools/serverless-open-source-frameworks-openfaas-knative-more/

What is Serverless?

pay for execution time only but not idle time 

outsourcing managinng, provisioning and maintaining servers to cloud provider

FaaS

faas-functions-events

What is FaaS (Functions as a Service)?

on-premises

abstraction further

hardware-virtualization-operating system-runtimes-application

IaaS(hardware-virtualization)-operating system-runtimes-application

Paas(hardware-virtualization-operating system-runtimes)-application

FaaS(hardware-virtualization-operating system-runtimes-application) - functions