KCA

Let’s consider how we deliver the bits around our code and how improving these might help us. From planning, to deprecation and the things in-between. Making small changes in these areas will help us and our team members work better. But first we need to talk about why.

A collection of excellent resources that are in or adjacent to the DevOps(or devOops) space

Now that we have an environment to run GKE clusters in we should probably build out a few clusters. Thankfully this post shouldn’t be as wordy as the last, but there is still a bunch of stuff to cover. We’re going to go over some of the features of GKE and value.

To host our GKE clusters, we’ll use several GCP projects. Projects on GCP provide boundaries around access privileges (Identity and Access Management), network constructs like subnets and similar and act as a collection of resources. Our multi-cluster environment is going to need a few projects and some organisation of the base resources in them.

This series is going to cover the work involved and design decisions made to build a multi-cluster, multi-region Google Cloud (GCP) & Google Kubernetes Engine (GKE) environment. Once created with Terraform, Spinnaker will be deployed and will manage our Kubernetes workloads from one of the GKE Clusters.

Kubernetes is a derp multiplier. With traditional systems it was possible to derp and knock out a box. Kubernetes gives you powers that let you deploy rapidly and in scalable ways. Unfortunately it also means all your derps deploy rapidly and in scalable ways. 🙃

Why I think gRPC is a good choice for your next API.

I like go for building services that people need. This is a quick look at how go is useful

Lifx made a move to kubernetes in 2017\2018 and this is a brief look at why we made that choice

Looking at grpc balancing we see several pitfalls and some rather nice systems that can be used to expand how they work.

Kubernetes has some great helpers that allow us to drop a service in and satisfy most requirements for service discovery and loadbalancing. Service discovery out of the box will make a dns request through Kube-DNS. Kube-DNS is (soon to be coredns) a pod running dnsmasq with a custom integration to watch events straight off the Kubernetes api. Loadbalancing is provided out of the box by Kube-proxy. Which provides TCP stream balancing inside the cluster.

I’ve occasionally run into people who modify and commit to a checked out build repoistory instead of making the changes on their workstation and pushing them in. I noticed that Galen Grover had a fairly neat solution to prevent himself committing to master (one I will probably copy for another workflow.)

So bored and on reddit reading about myki I guess it’s time to do some hypothetical over-engineering. First the challenge: that a reasonably well designed system could not handle frequent updates from the number of buses and trams in Melbourne (trains are a different question because updating the stations is easier and harder.) Goals: Reduce the time it takes to update the card balance. And some assumptions (some of which are there to make the maths easier for me some to over engineer and some because I just felt they were reasonable.