This article is written by Jason Quek, Global CTO at Devoteam G Cloud
TikTok
I have been interested in TikTok ever since I downloaded the app, the ability to suck you into an endless scrolling of videos tailored to your preferences, mixing it up once in a while, even shaping my music preferences by introducing new viral songs. Even more interesting was the TikTok used Google Cloud services.
So with this talk, they deep dived into how they run such a popular service all around the world, the kind of scale that engineers love to engineer on.
Lo and behold, for this type of scale, GitOps and pull-based configuration to the rescue, with Kustomize as templating tool. And with this brought a pattern that I am familiar with, one centralized ArgoCD deployment pushing to individual clusters, or multiple ArgoCD running in all edge clusters pulling from the central git repository.
From my experience, having multiple ArgoCD deployed into the cluster with private K8S apis, has a superior experience over a central ArgoCD installation, over having to worry how to scale ArgoCD, and making sure all edge clusters are synced. The distributed multi-worker technique has always proven to be more reliable and less prone to a single source of failure. The only downsides are having to spend resources running ArgoCD on each cluster, having network access to the repository, and managing upgrades and lack of central visibility. However these are issues which can be solved using other multi cluster tools such as Anthos to provide multi cluster observability on services, and to roll out ArgoCD upgrades via Anthos Fleet management.
For me how TikTok has solved their problem was really following the adage of keeping it simple, use proven open source technology and run it a distributed fashion pulling from a single source of truth.
Crossplane and ArgoCD
The next talk was about a up and coming CNCF project Crossplane. Now at Devoteam G Cloud, we are fanatics of Infrastructure as Code, with Terraform HCL being our language of choice. However with Anthos, there is a Kubernetes Config Connector, which allows users to define Google Cloud infrastructure as yaml and KCC would provision and maintain the infrastructure throughout its lifecycle, like how ArgoCD does for deployments into Kubernetes. With Crossplane, this now works multicloud. Currently it supports AWS, Google Cloud, Azure, Alibaba, Equinix and Red Hat.
I do like the idea of a controller managing my resources and constantly reconciling to ensure it reaches the desired state. However the issue I can see vs terraform is two fold, planning and single point of failure. These are always two worries in my head when I deploy changes in infrastructure, to see the changes which might occur when I apply the changes. This is due to the stateful nature of most changeable infrastructure like databases, storage buckets that can be impacted. Secondly, I am now dependent on another service which has to be running to change my infrastructure. Terraform is different in the way that I just have to depend that the code is correct, as code is deterministic, I am not dependent on a terraform service. I will keep an eye on this development and try to understand more about the changes in the industry to see if I should correct my opinion in the future.
With that, KubeConEU 2022 is completed, I just wanted to say a big thanks to all the companies who spoke and shared their knowledge with us. It was eye-opening and really a good use of my time.
Do you want to talk to me or one of our experts?
