{"id":2677,"date":"2019-04-25T08:43:03","date_gmt":"2019-04-25T12:43:03","guid":{"rendered":"http:\/\/www.soul-repairs.com\/blog\/?p=2677"},"modified":"2019-04-21T19:36:07","modified_gmt":"2019-04-21T23:36:07","slug":"knative-what-is-it-and-why-do-i-care","status":"publish","type":"post","link":"https:\/\/soul-repairs.com\/blog\/2019\/04\/25\/knative-what-is-it-and-why-do-i-care\/","title":{"rendered":"Knative: What is it, and why do I care?"},"content":{"rendered":"

Officially…<\/h2>\n

Knative is a Kubernetes-based platform to build, deploy, and manage modern serverless workloads.
\n– Source: Google<\/a>, who “owns” the project<\/p><\/blockquote>\n

…a reasonable follow-up question is okay, but what does “serverless” mean?<\/em><\/p>\n

<\/p>\n

Serverless architectures are application designs that incorporate third-party \u201cBackend as a Service\u201d (BaaS) services, and\/or that include custom code run in managed, ephemeral containers on a \u201cFunctions as a Service\u201d (FaaS) platform.
\n– Source: MartinFowler.com’s serverless section<\/a><\/p><\/blockquote>\n

Most of the time, and especially for Knative, “serverless” refers to that second part of the definition – code that runs in containers that are brought to life just to execute that code, and are then killed when the code finishes execution.<\/p>\n

Knative is native to Kubernetes<\/a> (…get it? Native<\/strong> to K<\/strong>ubernetes? lolz<\/em>), which means that it exists pretty much to take care of Kubernetes things that you most likely won’t want to deal with on your own.<\/p>\n

A note on pronunciation…<\/h3>\n

We joked when we were first looking into Knative that we were definitely going to call it kah-native<\/em> – assuming it was actually pronounced like “native,” because silent K’s. We were going to run with kah-native instead because…well, probably because we’ve seen Monty Python and the Holy Grail <\/a>one too many times. It turns out we were both right and\u00a0<\/em>wrong – it’s pronounced “kay<\/em>-native.”<\/strong><\/p>\n

So…what does it do?<\/h2>\n

There are three main ways that Knative shines with serverless architectures, and also with Kubernetes-run applications as a whole. The three ways are all in the definition we already mentioned – build<\/em>, deploy<\/em>, and manage<\/em>. It does this via custom resource definitions<\/a>, and some associated API’s (Build, Serving, and Eventing).<\/p>\n

The purpose of the API’s, and of Knative as a whole, is to handle some of the fuzzier areas that fall under the semi-gray umbrella of “middleware<\/a>” for applications intended to run on a Kubernetes (or Kubernetes-based, like OpenShift) cluster. Middleware here refers to the generic definition, “software that runs under the application layer,” not<\/em> application runtimes<\/a>. Overloaded IT terms are fun, you guys<\/em>.<\/p>\n

The Knative API’s can also be used independently, so if only the Build portion interests you, that’s all you have to install.<\/p>\n

Build<\/h3>\n

Purpose: build and package application code from within<\/em> the Kubernetes cluster.<\/p>\n

Associate API bundle: Build<\/strong> (…seems legit<\/em>, Documentation<\/a>, GitHub source<\/a>), allows you to…well, build. It also has functionality for the common things people will probably want to do related to a build – like building the source code into a container, or pushing the resulting image to a registry.<\/p>\n

Deploy<\/h3>\n

Purpose: Deploy and serve applications. Also handles spinning the applications up to run as needed and then spinning them back down, which is one of the fundamental pieces of serverless architecture.<\/p>\n

Associated API bundle: Serving <\/strong>(Documentation<\/a>, GitHub source<\/a>) – among other things, handles custom routing and autoscaling. (note: this uses Istio<\/a>!)<\/p>\n

Manage<\/h3>\n

Purpose: Event-handling, manages defining event sources and subscriptions.<\/p>\n

Associated API Bundle: Eventing<\/strong> (Documentation<\/a>, GitHub source<\/a>), handles event sources and event delivery, also\u00a0Serving<\/strong> applies here too.<\/p>\n

Who should care a lot<\/em>\u00a0about Knative?<\/h2>\n

Per Google, there are two main groups of people who are likely to find Knative helpful (most of these words are a summary of what we learned doing the CodeLab on Google, the link is at the bottom of this post).<\/p>\n

1. I want to deploy to a Kubernetes cluster easier.<\/h3>\n

Because of the Build API, which…well, builds<\/em>, Knative can make it easier to handle\u00a0that<\/em> part, starting from a code repository. Routing and autoscaling, part of the Serving API, are also probably <\/em>things applications on a Kubernetes cluster will want – routing lets the outside world in, and autoscaling (especially spin up and spin down for serverless) is one of the very coolest parts of running on Kubernetes. It also some slick capabilities to make blue\/green deployments<\/a> easier.<\/p>\n

2. I want to build my own PaaS\/FaaS on Kubernetes.<\/h3>\n

If you really wanted to write your own internal Paas\/FaaS (like Heroku<\/a> or AWS Lambda<\/a>) on a Kubernetes cluster, some of the Knative components would help you do that.<\/p>\n

Why\u00a0we\u00a0like it<\/h2>\n

Knative provides middleware functionality in modular pieces to help support serverless applications on Kubernetes-based clusters. Several of these modular pieces also can help with getting\u00a0non<\/em>-serverless applications on a Kubernetes cluster.<\/p>\n

The ecosystem around Kubernetes is growing at a giddy pace, and as one of us is an avid<\/strong> automation nerd (spoiler alert: it’s Laine<\/em>), Knative is one of the most interesting pieces to pop up recently.<\/p>\n

MORE Resources! Learn all the things!<\/em><\/h2>\n