English | EN 
Capgemini has always encouraged exploring and imbibing new technologies and processes to facilitate easy execution. While the world is moving to cloud, Capgemini is also exploring new approaches in serverless architecture.
The cloud providers have serverless event-driven functions, for example, AWS Lambda and Azure Functions. Enterprises may want a serverless event-driven architecture on their premises, which translates to having a framework to create and manage native serverless deployments on-premise or on the cloud, in a cloud-agnostic manner, which would provide the flexibility to move among different clouds without impacting the systems and processes.
Knative is one example of an open-source serverless platform. Built by Google in collaboration with RedHat, Pivotal and other industry leaders using Kubernetes and Itsio, Knative attempts to solve the complexities of building an application and managing its servicing and lifecycle while providing ‘serverless’ style event-driven functions.
However, Knative is not just for serverless. Knative also tries to remove the complexities developers face such as managing dependencies, managing networks within Kubernetes and so on.
Knative had three components: Serve, Event and Build. Build is now deprecated and Knative currently provides only the Serving and Eventing part. Interestingly the Knative components or blocks are kept independent of each other. These components can be used individually as required.
Let us take a look into the Serving and Eventing components.
Serving
This component provides the support to deploy and serve the serverless applications including Scaling, Routing and Snapshots.
As of today, Knative provides three ways to provide the routing functionality:
- Ambassador — an open source API Gateway built on Envoy Proxy.
- Itsio — a service mesh that includes Knative-compatible ingress, built on Envoy Proxy.
- Gloo — an API Gateway built on Envoy Proxy.
Serving component retains revisions and can provide A/B testing of serverless functions and route limited traffic to serverless application or functions.
The serving component provides autoscaling scale from 0..N( and vice versa) and easier deployment of serverless containers. The configuration component (sub-component within serving) provides the externalized configuration and has a clean separation of code and configuration. Serving component provides the integrated service mesh or gateway based on Envoy proxy, which can be anyone mentioned earlier.
Eventing
Eventing component provides loosely coupled architecture for composable event sources and event consumers. You can develop and deploy services using existing event sources, build your own event source to connect with an existing system or create a pipeline of events.
The event producers and consumers are independent. Event producers can emit events even in the absence of consumers and an event consumer can wait for events even in absence of producers. This provides developers to be less depended on other teams. Knative provides cross-service interoperability and follows the CloudEvents specification developed by CNCF Serverless WG.
Knative Eventing component provides:
· Event Brokers and Triggers
This component allows you to filter events. A broker provides a bucket of events that can be selected by attributes. If a matching trigger is found for a subscriber, then event is forwarded to the subscriber.
· Event Channels and Subscriptions
Channels form the event-forwarding and persistence layer. The events are delivered to services or forwarded to other channels using the Subscriptions. The eventing supports 2 forms of event delivery, which is similar to a P-T-P messaging and Pub-Sub type of delivery.
The following figure shows two types of deliveries: a direct delivery consumed by service A and a subscription-based delivery on event types sent to other services. Service C forwards events to another channel that may be consumed by other services.
Build
The build component of Knative is deprecated in Git hub and suggests to use Tekton Pipelines. The build component was basically used to retrieve code from source controls, build container images, run unit/ integration and other tests, push container images to registry or deploy them to a cluster.
Bit of research led me to a blog on Medium which suggests:
There’s a Knative issue (614) with more details, but basically it has been decided that building and pushing an image for a service should not be one of the core responsibilities for Knative.
The team would have thought this part to be more in CI/CD’s scope and not a part of the Knative core focus and hence let other tools provide those services. Tekton Pipeline is suggested by Knative, and perhaps Jenkin X is also an alternative.
What next?
The Knative community is strong with support from the major industry players. There are quite a few platforms that have built layers on top of Knative with the likes of OpenShift from Red Hat, Google Cloud run, project riff from Pivotal and so on. Knative is still maturing and hopefully, there will be more tools that make developers and operation folks life easier. Sogeti is also exploring ways to make their client agile and make their changes faster to their customers.
References:
https://medium.com/google-cloud/migrating-from-Knative-build-to-tekton-pipelines-68fc6de14373
