1 Introduction

 

This chapter covers:

  • What Knative is and why you should use it
  • The places where Knative shines (and doesn’t)
  • The basics of serving and eventing
  • Where to get started

One of my north stars is the Onsi Haiku Test [haiku]:

Here is my source code.
Run it on the cloud for me.
I do not care how.

This is actually a radical notion of how software can best be developed, deployed, upgraded, observed, managed and improved. It must be, because so often it emerges long after we’ve tried everything else first. It implies:

  • That a fast, reliable path to production is a shared goal for everyone
  • That there is a crisp contractual boundary between folks who provide platforms and folks whose work will consume the platform
  • That building software that handles other software is, for most developers, not the most urgent, most valuable work they could be doing.

Kubernetes, by itself, does not pass the Onsi Haiku Test. The boundary between development and operation is unclear. Developers can’t walk up to a vanilla kubernetes cluster, hand it raw source code, and get all the basic amenities of routing, logging, service injection and so on. Kubernetes gives you a rich toolbox for solving the Test in your own particular way. But a toolbox is not a machine. It is a toolbox.

1.1  What is Knative?

1.1.1  Deploying, upgrading and routing

1.1.2  Autoscaling

1.1.3  Eventing

1.2  So what?

1.3  Where Knative shines

1.3.1  Workloads with unpredictable, latency-insensitive demand

1.3.2  Stitching together events from multiple sources

1.3.3  Decomposing monoliths in small increments

1.4  It’s a hit

1.4.1  Trouble in paradise

1.5  Changing things

1.6  What’s in the Knative box?

1.6.1  Serving

1.6.2  Eventing

1.6.3  Serving and Eventing

1.7  Keeping things under control

sitemap