Mete Atamel

In part 1, I talked about the initial app and its challenges. In part 2, I talked about the lift & shift to the cloud with some unexpected benefits. In this part 3 of the series, I’ll talk about how we transformed our Windows-only .NET Framework app to a containerized multi-platform .NET Core app and the huge benefits we got along the way.

Why?

The initial Windows VM based cloud setup served us well with minimal issues about roughly 2 years (from early 2017 to early 2019). In early 2019, we wanted to revisit the architecture again. This was mainly driven by the advances in the tech scene namely:

In part 1 of app modernization series, I introduced a simple news aggregator and some of the challenges in its initial architecture. In part 2, I’ll talk about the journey to the cloud and some unexpected benefits and learnings along the way.

Why Cloud?

The initial backend had many issues that I outlined in part 1. After about 1 year, in late 2016, we decided to look into moving it to a more stable home. Our main goal was to improve resiliency of the app, as the IIS host kept crashing, but we didn’t want to rewrite or re-architecture the app in a major way. Around the same time, I started working at Google and was learning all about Google Cloud. We decided to give it a try and see what it took to move the app there.

We all have apps running some “legacy code” in some “legacy way”. The term “legacy” means different things in different projects but we know when we see it and we want to get the time to modernize those apps in some way.

I recently went through the latest phase of modernization of a legacy app. Even though it’s a relatively small app, it thought me a number of lessons that’s worth sharing.

It’s hard to keep with Knative releases with a release every 6 weeks. I finally managed to update my Knative Tutorial for the latest Knative v0.12.0. In this blog post, I want to outline some of the differences I’ve observed.

Knative Serving

Knative Serving has been pretty stable in the recent releases and Knative Serving v0.12.0 is no exception. I didn’t need to update my tutorial specifically for this release.

Knative Eventing

Knative Eventing v0.12.0 changed the default yaml for Knative Eventing bundles. Now, they are under eventing.yaml (previously, it was release.yaml) and this is the yaml you need to point to install eventing. This makes sense as it’s more consistent with Knative Serving and its serving.yaml.

The default Knative Installation instructions for Google Kubernete Engine (GKE) is problematic (see bug 2266). In this post, I want to outline what the problem is, tell you what I do, and also provide you the scripts that work for me until a proper solution is implemented either in gcloud or Knative.

The problem

The default Knative Installation instructions tell you to create a GKE cluster as follows:

gcloud beta container clusters create $CLUSTER_NAME \
 --addons=HorizontalPodAutoscaling,HttpLoadBalancing,Istio \
 --machine-type=n1-standard-4 \
 --cluster-version=latest --zone=$CLUSTER_ZONE \
 --enable-stackdriver-kubernetes --enable-ip-alias \
 --enable-autoscaling --min-nodes=1 --max-nodes=10 \
 --enable-autorepair \
 --scopes cloud-platform

Notice the Istio add-on. This command creates a Kubernetes cluster with Istio already installed. This is good because Istio is a dependency of Knative but keep reading.

In my previous post, I talked about Knative v0.9.0 and some of the eventing changes in the latest release. I’ve been playing with Knative v0.9.0 since then to read Google Cloud Pub/Sub messages using PullSubscription and I ran into a rather fundamental issue that baffled me for a while. I’d like to outline the problem and the solution here, just in case it’s useful to others.

Knative Services as eventing sinks

In my PullSubscription, I could define Kubernetes Services as event sinks as follows:

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

Knative 0.8.0 and Build Deprecation

Knative 0.8.0 came out a couple of weeks ago with a number of fixes and improvements. One of the biggest changes in 0.8.0 is that Knative Build is now deprecated according to docs:

Knative Installation docs also only include Knative Serving and Eventing without mentioning Build:

kubectl apply   
\-f https://github.com/knative/serving/releases/download/v0.8.0/serving.yaml \\  
\-f https://github.com/knative/eventing/releases/download/v0.8.0/release.yaml \\  
\-f https://github.com/knative/serving/releases/download/v0.8.0/monitoring.yaml

Good to know but there’s no explanation on why Knative Build was deprecated and any guidance on what is the replacement, if any. After a little bit of research, I have more information on deprecation and also a migration path that I’d like to share in this post.