Google Cloud Platform

Many people who run Windows containers want to use a container management platform like Kubernetes for resiliency and scalability. In a previous post, we showed you how to run an IIS site inside a Windows container deployed to Windows Server 2019 running on Compute Engine. That’s a good start, but you can now also run Windows containers on Google Kubernetes Engine (GKE).

Support for Windows containers in Kubernetes was announced earlier in the year with version 1.14, followed by GKE announcement on the same. You can sign up for early access and start testing out Windows containers on GKE.

Knative has been evolving pretty quickly. There’s a new release roughly every 6 weeks with significant changes in each release. Knative v0.7.0 was all about changes in Knative Serving (my post). Knative v0.8.0 was about deprecation of Knative Build in favor of Tekton Pipelines (my other post).

Knative Serving v0.9.0 and Eventing v0.9.0 have been released a little over a week ago. In Serving, there’s a v1 API and a number of improvements on autoscaling and cold starts. In Eventing, the way events are read changed quite a bit. I want to outline some of these changes here.

Last year, we published a blog post and demonstrated how to deploy a Windows container running Windows Server 2016 on Google Compute Engine. Since then, there have been a number of important developments. First, Microsoft announced the availability of Windows Server 2019. Second, Kubernetes 1.14 was released with support for Windows nodes and Windows containers.

Supporting Windows workloads and helping you modernize your apps using containers and Kubernetes is one of our top priorities at Google Cloud. Soon after the Microsoft and Kubernetes announcements, we added support for Windows Server 2019 in Compute Engine and Windows containers in Google Kubernetes Engine (GKE).

As you might have heard, Knative 0.7 was out last week. One of the notable changes in this release is that Knative Serving API progressed from v1alpha to v1beta. While you can still use the old v1alpha1 API, if you want to update to v1beta, you need to rewrite your Knative service definition files. The new API also allows named revisions, silent latest deploys and a better traffic splitting configuration. In this post, I want to outline some of these changes.

Introduction

If you’ve heard of Cloud Run, you already know that it’s great for spinning public endpoints inside stateless containers to handle HTTP request/reply type of workloads. And the best part is that you only pay for the duration of the request!

However, HTTP request/reply handling is not the only use-case for Cloud Run. Combined with Cloud Pub/Sub, Cloud Run is very well suited for internal async worker type use-cases because:

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 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.

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.