STANISLAV KOLENKIN, BAQ "K8S: network plugins - issues and performance comparison"

1. Knative: new level of coding or how to
bring serverless inside kubernetes
by Stanislav Kolenkin, Senior DevOps.

2. Introduction
2
Google, together with IBM, Red Hat, SAP and Pivotal, among others, announced
the release of Knative, an open-source framework to run serverless and
service-mesh architecture. This is the same framework that Google used to release
its recent GKE serverless add-on.
Knative is built upon Kubernetes and Istio, an open source service mesh tool, and
is aimed to target different personas including developers, Ops teams and cloud
providers. With Knative, these users can benefit from three main advantages of
cloud-native development: building, scaling and managing containers and functions
all in one platform. The platform also provides built-in templates for ease of use.

3. Defenition of Native
3
Wikipedia states the definition of native as, “In computing, software or data
formats that are native to a system are those the system supports with minimal
computational overhead or additional components. This word is used in terms such
as native mode and native code.”

4. Serverless
4
The functional paradigm makes it easier to reason about software, utilize
concurrency patterns, and implement scale processing and event-driven
architectures.
Major cloud providers quickly adopted the idea of running functions in the cloud
and started to offer platforms for short-lived (a.k.a., serverless) applications that
shield clients from knowing about the details of servers where these applications are
invoked. AWS Lambda, Microsoft Azure Function, and Google Cloud function are
examples of these offerings. Numerous sources compare their pros, cons,
similarities, and differences, including “Serverless Comparison Lambda vs. Azure
vs. GCP vs. OpenWhisk” and “An Essential Guide to the Serverless Ecosystem.”

5. Serverless
5

6. Serverless
6
Serverless applications are enabling a usage-based billing model (no more
payments for idle time) and have the ability to scale in the cloud from zero to
thousands running instances and back within seconds. They are able to
automatically retry after failures and run on demand or in response to the changes
registered by cloud infrastructure components (schedulers, queues, topics, etc.),
and they have gained in popularity. Serverless applications enabled numerous new
ways to accomplish distributed batch, real time, scheduling, stream, and event
processing.

7. Serverless
7

8. Serverless
8
Most of the problems stem from the fact that existing serverless applications are
still hardwired (native) to their vendors’ systems. This has a number of serious
consequences:
● Business serverless functionality is heavily intermixed with infrastructure concerns
(even the term “serverless” refers to the infrastructure and not to the functionality).
This creates additional complexity that negatively affects most systems
development life cycle (SDLC) design, construction, testing, deployment, and
support.
● This additional complexity spills over to executive and business stakeholders,
exposing them to low-level technical details and making them struggle in the
dense forests of serverless choices.

9. Serverless
9
● Cloud function created for one cloud provider is not compatible with other cloud
providers, not to mention its incompatibility with dedicated data centers or
developers’ local machines.
● AWS Lambda, Microsoft Azure Function, and Google Cloud function often need
to be written in incompatible programming languages and binary bundled with
incompatible compile and run-time dependencies.
● Serverless application deployment mechanisms are also vendor specific.
● Any vendor lock-in is a poor fit for function reuse and migration to hybrid clouds.

10. Serverless
10
● Cloud providers have different and often obscure ways (products) of combining
multiple serverless functions into larger execution flows.
● The concept of cloud events, when it exists, is abstracted in terms of
vendor-specific resources and heavily intermixed with messaging semantics.
● Last but not least, none of these cloud functions supports the concept of streams.

11. Serverless
11
There are multiple fragmented offerings that either partially solve some of these
issues of nativeness or address all of them at the cost of adding more complexity.
Spring Cloud Function aims to use existing serverless functions and abstract their
heterogeneity on the source code level by reusing the same common code bundled
with different adapters for different vendors.
Apache OpenWhisk is a nice cloud platform on its own that competes with
vendors’ solutions. It addresses most of the above mentioned issues but enforces its
own design paradigm, requires complex infrastructure, and is not actively supported
by major software companies.

12. Knative
12
It is not uncommon in software circles to see a breakthrough in problem-solving
when developers address a known problem in a way that is completely opposite to
previous attempts. These "Aha!" moments of solving problems using the opposite
approach are often captured as eye-catching “inversion” design principles such as
inversion of control and dependency inversion.

13. Serverless
13
Knative does this for cloud functions. Instead of requiring serverless applications
to be native to the cloud systems, Knative provides a cloud ecosystem that is
adapted (native) to functions in the cloud. The ecosystem supports multiple SDLC
phases, that is, design, build, deployment, and execution. It comprises pluggable
components that are already supported by all major cloud providers. Moreover, the
plug-in architecture of these components allows for replacement and customization.

14. Knative
14

15. Knative
15
Here are some of the immediate benefits that we see with the introduction of
Knative:
1. A consolidated platform that brings together Kubernetes, serverless and
service-mesh, meaning developers can focus on what they like (and want!) to do,
without the hassle of the underlying network.
2. Serverless is here to stay. In the recent Gartner’s Security and Risk Summit
held in Maryland in June, distinguished analyst Neil MacDonald discussed the
fact that Serverless is on the horizon, as more and more clients are asking about
it. Not surprising is also the fact that serverless was the most searched topic at
the AWS Summit NY held in mid-July, where Alcide also participated.

16. Knative
16
Knative can address business, software design, delivery, infrastructure, and
security concerns separately and in a vendor-independent way.
These concerns map into components of major Knative features: build, eventing,
and serving. These features allow containerization of serverless applications with
their infrastructure, and Kubernetes is used as an orchestration engine. Knative
relies on Istio for network routing, security, and monitoring.

17. Knative
17

18. Knative
18
Knative serving uses a Sidecar cloud design pattern in which service hosts a
function and plays the role of the application container. Containerization enables
functions to be bundled while language-specific run times are programmed at build
time.
With these features, according to Pivotal’s director of technical marketing, Dan
Baskette, “Functions are the next abstraction you need to care about. . . Developers
can focus entirely on their function code to process an event.” Functions could be
written in many programming languages without any additional dependencies or
special run-time libraries. GitHub features Knative functions written in C#, Go, Java,
Node.js, PHP, Python, Ruby, and Rust. Designers can chain multiple cloud functions
into powerful business workflows by connecting serving route-named endpoints.

19. Knative
19
Route supports HTTP and gRPC endpoints. The latter enables endpoints’
distributed streaming. Knative pluggable architecture lets open-source add-ons like
Project Riff invokers connect streaming endpoints with multilingual streaming
functions. The functions need only to have well-known stream primitives as
parameters and return values. This way, Knative provides a native streaming
platform for serverless applications.

20. Knative
20
Events and event sourcing are staples of modern software-distributed
architectures. The Knative eventing feature enables invocation of loosely coupled
cloud services and serverless applications in an asynchronous manner. Its powerful
generic abstractions for cloud events and communication primitives, such as Knative
events, channel, subscription, and bus, allow architects and developers to
concentrate on designing asynchronous flows instead of wrestling with messaging
infrastructures. Knative commitment to the standard CloudEvents nomenclature
protects event-driven design investments from current and future proprietary event
frameworks.

21. Knative
21
Eventing allows apps/functions to
publish to, and subscribe to, event
streams such as Google Cloud
Pub/Sub and Apache Kafka.

22. Knative
22
A Build is a custom resource in Knative that allows you to define a process that
runs to completion and can provide status. For example, fetch, build, and package
your code by using a Knative Build that communicates whether the process
succeeds.
A Knative Build runs on-cluster and is implemented by a Kubernetes Custom
Resource Definition (CRD).
Also consider using a Knative Build to build the source code of your apps into
container images, which you can then run on Knative serving.

23. Knative
23

24. Knative+Istio
24
This is where the inversion of native truly shines. Pods with containerized
serverless applications and infrastructure adaptor containers are automatically
deployed, scaled, and managed with Kubernetes. Kubernetes allows the user to run
serverless flows in hybrid clouds across multiple cloud vendors, on premises, and on
local development machines in the same way.
Istio helps cloud functions achieve enterprise-grade application quality on
unreliable networks. It provides a uniform, configurable, declarative, policy-based
approach; many operational features, such as network routing; retries on failures;
and circuit breaking and security. Istio also enables monitoring as well as Zipkin
tracing for services and serverless applications. In short, Knative brings the benefits
of Istio to serverless applications.

25. Thank you for your attention!
Questions?

26. CONTACTS:
Email: stas.kolenkin@gmail.com
Skype: stas.kolenkin