Mete Atamel

I previously talked about Knative Build and how it enables you to go from source code to a container image in a repository. You can write your Build from scratch or you can rely on many of the BuildTemplates Knative already provides. For example, in my Knative Tutorial, I show how to install Kaniko BuildTemplate and use Kaniko to build container images.

You normally need to write a Dockerfile, so Knative Build (or Kaniko to be more precise) knows how to build the container image. Wouldn’t it be great if there was a an automatic way to build your app without having to define a Dockerfile ? Well, there is!

In my Hands on Knative series (part 1, part 2, part 3), I showed how to use Knative Serving, Eventing and Build on any Kubernetes cluster anywhere. This is great for portability but with that portability comes the overhead of creating and managing a Kubernetes cluster. Not to mention the complexity of Istio which is a dependency of Knative.

Google Kubernetes Engine (GKE) helps with managing the Kubernetes cluster a little but you still need to worry about all the bells and whistles of a Kubernetes cluster. Wouldn’t it be great to have the Knative Serving experience without having to worry about the underlying infrastructure? Well, you can with Cloud Run!

TL;DR: I recently went through the preparation and exam of Google Cloud’s Professional Cloud Architect Certification. It was great learning experience and I highly recommend it. You can register here to get certified yourself!

Why?

As you might know, I’m a Googler and a Developer Advocate for Google Cloud. Why do I want to be certified by Google Cloud when I already work at Google and know a great deal about Google Cloud? I had 2 main motivations:

In Part 1, I talked about Knative Serving for rapid deployment and autoscaling of serverless containers. In Part 2, I talked about how to connect services in a loosely coupled way with Knative Eventing.

In third and last part of the series, I want to talk about Knative Build and show a few examples from my Knative Tutorial.

What is Knative Build?

Knative Build basically allows you to go from source code to a container image in a registry. For example, you can write a build to obtain your source code from a repository, build a container image, push that image to a registry and then run that image, all within the Kubernetes cluster.

In my previous post, I talked about Knative Serving for rapid deployment and autoscaling of serverless containers. Knative Serving is great if you want your services to be synchronously triggered by HTTP calls. However, in the serverless microservices world, asynchronous triggers are more common and useful. That’s when Knative Eventing comes into play.

In this second part of Hands on Knative series, I want to introduce Knative Eventing and show some examples from my Knative Tutorial on how to integrate it with various services.

I’ve been looking into Knative recently. In this 3-part blog series, I want to explain my learnings and show some hands on examples from the Knative Tutorial that I published on GitHub.

What is Knative anyway?

Knative is a collection of open source building blocks for serverless containers running on Kubernetes.

At this point, you might be wondering: “Kubernetes, serverless, what’s going on?” But, when you think about it, it makes sense. Kubernetes is hugely popular container management platform. Serverless is how application developers want to run their code. Knative brings the two worlds together with a set of building blocks.

The default metrics sent by Istio are useful to get an idea on how the traffic flows in your cluster. However, to understand how your application behaves, you also need application metrics.

Prometheus has client libraries that you can use to instrument your application and send those metrics. This is good but it raises some questions:

• Where do you collect those metrics?
• Do you use Istio’s Prometheus or set up your own Prometheus?
• If you use Istio’s Prometheus, what configuration do you need to get those metrics scraped?

Let’s try to answer these questions.

When learning a new technology like Istio, it’s always a good idea to take a look at sample apps. Istio repo has a few sample apps but they fall short in various ways. BookInfo is covered in the docs and it is a good first step. However, it is too verbose with too many services for me and the docs seem to focus on managing the BookInfo app, rather than building it from ground up. There’s a smaller helloworld sample but it’s more about autoscaling than anything else.

Dialogflow is a developer platform for building voice or text-based conversational apps on a number of platforms such as Google Assistant, Facebook Messenger, Twilio, Skype and more. Earlier this year, we used Dialogflow to build a Google Assistant app and extended it to use the power of Google Cloud. You can read more about it on Google Cloud blog here, see the app code on GitHub here and one of my talk videos about the app is here.

Istio 1.0 is finally announced! In this post, I updated my previous Istio 101 post with Istio 1.0 specific instructions. Most of the instructions are the same but with a few minor differences about where things live (folder names/locations changed) and also most commands now default to kubectl instead of istioctl.

For those of you who haven’t read my Istio 101 post, I show how to install Istio 1.0 on Google Kubernetes Engine (GKE), deploy the sample BookInfo app and show some of the add-ons and traffic routing.