Happy Birthday Knative

Today is the one year anniversary of the Knative Serverless Platform for Kubernetes. It’s been a great year for Knative. We were very honored to be included in the initial launch in San Francisco during Google Next 2018 and we worked hard to help Knative get to where its at. As we celebrate this one year anniversary TriggerMesh is especially proud to be the #5 company by contributions behind giants like Google, IBM and Pivotal.

TriggerMesh Projects

Our GitHub is full with open source Knative goodies:

• tm our Knative client also features a Serverless framework compatible interface.
• KLR our Knative Lambda runtime allows you to run AWS Lambda functions without change in Knative
• KLASS our Knative Lambda Sources allow you to consume AWS events like SQS or Kinesis and use those events to triggers Knative functions.
• Terraform lovers will enjoy our Terraform Knative provider.
• Our aktion CLI helps you transform GitHub Actions workflows into Tekton Pipelines and trigger execution on GitHub events.

Knative Thoughts

There were are a number of milestones since the Knative launch last year and we are already on version v0.7.1 with an API that is stabilizing. We do not want to review a set of milestones instead we just want to bring your attention to a few things:

Perhaps the most important fact is that Knative is on a fast pace with a release every 6 weeks and similar release management as early Kubernetes days. Things evolve quickly with Google, Red Hat and IBM contributing heavily. Keeping up is sometimes challenging but as always the release notes are a great focused lens on what is happening. One thing is certain though, you can count on the release happening on time.

Second, as a Kubernetes API extension, Knative makes heavy us of Custom Resource Definitions plus a way to re-use API shapes called “duct-typing”. Software engineers will love this talk from Matt Moore and Ville Aikas, two of the Knative tech leads, on duct-typing. This method has allowed Knative to benefit from a lot of existing Kubernetes mechanisms. For example, the Pod specification is now clearer in a Knative Configuration.

Serverless is often reduced to FaaS: deploying a function from source very much like AWS Lambda. But as with Lambda Serverless computing is much more than FaaS and a key mechanism is event management. Nonetheless the ability to deploy a function from source was a use-case from the start and it led to the Knative build project. This project matured quickly and initiated the Tekton project which aims to be a more generic Cloud-Native CI/CD solution. This is why you will see that the Build project is being deprecated and why at TriggerMesh we now integrate directly with Tekton. Our tm client uses Tekton our backend use Tekon and aktion use Tekton.

Then there is eventing. Eventing has probably been the source of the most debates. Finding the correct abstractions for users while doing it in a way that an ecosystem can flourish has proved challenging. We now have Broker and Trigger as core objects with a Broker being backed by messaging systems like Kafka and Google PubSub. Surely we will see more soon. A lot of sources including KLASS have been developed with an important commonality in CloudEvents. Knative as embraced the CNCF CloudEvent spec.

Finding The Open Source Balance

As a young startup hunting for a sustainable business model we do have to keep some of our sauce secret :). We do have more Knative add-ons  behind the scene and while we would love to open source everything we also have to think about growth and how we can build up TriggerMesh.

Like in life, we try to reach a balance and that’s why our own SaaS is open to anyone for free but the actual software is closed source. You can easily check our docs at docs.triggermesh.io and file any issues. As you get on the platform you will see how all our open sources tools are being used and you will surely see Knative and Tekton behind the scene. Some of the early Kubernetes enthusiast might equate this as the Tectonic of Knative

Knative Future

We expect Knative to get generally available (i.e v1.0.0 release) mid to late September 2019. Once GA, Knative will become the de-facto open-source platform for serverless workloads. It will become a Kubernetes extension that everyone will be able to deploy to benefit from a common standard, very much like Kubernetes has now become the standard for containerized workloads. As we get closer to Knative 1.0 we think that there will be a rather large migration of users to this platform. People will use Knative for its built-in scaling capabilities and more PaaS like APIs but thinking about 2020, we expect people to start using Knative fully and benefit from the eventing solution to link Cloud services together and build Cloud-Native pipelines. Stay tuned !

‍