Preparing for My “Build Your Own Serverless With Knative” talk at All Day DevOps
I’ll have the honour to present an introduction to Serverless, Knative and the Ambassador API Gateway at the next All Day DevOps on November 12th, 2020.
It’s an exciting opportunity for me to showcase this talk at a global world-wide event. As I’ve put together a similar session over a year ago and presented it a few times at events in my local community — I’m based out of Montreal, Canada — , I recently had to refresh some of the content as technologies have matured over time and inspired my proposal to All Day DevOps (ADDO).
While I can’t always fit a live demo in my allocated time, I do enjoy giving the audience a real tour of Knative, with a proper interactive feel, that goes beyond the usual “Hello World” application. And when the time does not permit, I want people to leave with something… not an assignment, but a path forward for them to actually play around with this cool tech if I’ve piqued their curiosity.
Building a Demo Environment
Picking an appropriate target Kubernetes cluster can make or break your demo. Given the constraints of the setting: WiFi availability and stability, network restrictions, latency, public or private access, etc., it might be safer to run the demo in a public cloud and have a fallback local cluster setup using Minikube or KIND in case anything goes unexpectedly wrong. For Knative specifically, since the installation process involves DNS, public IPs and trusted TLS certificates, I would prefer targeting a public cloud for my sandbox environment… but we never know!
Since I also encourage attendees to trial my demo themselves, I don’t necessarily want them to incur costs for leveraging a cloud provider. I want my experimentations to be cheap. Having the ability to set up a local or remote demo gives me, and the audience, the best of both worlds.
We know the constraints, so I settled on one or more target Kubernetes clusters. Now, how do we install the application components: I’m thinking Kubernetes CRDs, Deployments, Services and Ingress resources? Looking at installation options, we have a plethora of choices: from raw YAML files and kubectl apply commands to Helm charts, operators and CLI installers. We all have our preferences, don’t we? When I present installation instructions on slides or in my terminal, I want them to be straightforward and readable from afar. No lengthy YAML sample, no multi-step dependencies, just common tools.
Finally, for my Serverless demo, I wanted to go beyond the kubectl apply steps and actually configure the Knative and Ambassador installations for observability with metrics and distributed tracing. Enabling these features are typically more, manual, error-prone operations that do take away from a streamlined, documentation-free installation process.
So, how did I go about creating an easy, repeatable and quick installation process for my Knative demo sandbox? Well, lucky me, I was already building a tool for a similar job: the K8s Initializer. Simply answering the same questions I was asking myself for building my demo environment, I can select my target Kubernetes cluster and public Ingress options along with a pre-configured and integrated Knative, Ambassador, Prometheus and OpenTelemetry stack. That will be my choice this time around when I come forward with my playground at All Day DevOps.
Update!
The recordings from the 24-hour marathon of DevOps-related talks at All Day DevOps on November 12th, 2020, were posted!
Have a look at the final cut: https://content.sonatype.com/2020addo-mi/addo2020-mi-gervais
