For the past year I’ve been working with the people at GoSource around 3 days per week while also working towards my commercial pilot license (more on that journey separately). GoSource are involved in quite a number of interesting projects, but for the past 5 months I’ve been involved with the United Nations Transparency Protocol, which aims to make product claims easy to verify - claims such as whether the product was produced on land that is deforestation-free, or whether a battery in your EV was sourced with components that meet certain sustainability goals.
One of the great aspects of working at a larger company like VMware is that there are programs like Take 3, designed to help people who meet certain criteria to take 3 months on a different project to learn new skills in other contexts and bring those skills and experience back to their team - rather than potentially looking elsewhere for a similar learning experience. This post documents my own recent learning experience of an exciting Take3 project at VMware, with the hope that others may be able to take up the opportunity to learn and bring new skills back to their teams.
During a career as a software engineer, every now and then you come across a design pattern that becomes your darling for a few years following the discovery. Other design patterns are useful, but not so special that you want to tell the world about them.
Up until recently, my favourite design pattern was the state pattern which allows encapsulating different behaviours (implementations of an interface) in different classes so that an object can delegate its functionality to different state implementations which can be update at runtime. But more recently, while using a lot of concurrency in certain Kubeapps services, I’ve fallen in love with another design pattern - the fan-out/fan-in messaging pattern (or a form of it).
The recent release of Kubeapps marks a milestone for the Kubeapps team in that we are no longer restricted to presenting a catalog of only Helm packages in our UI and, behind the scenes, we’ve addressed a long-standing security issue to remove the reverse proxy to the Kubernetes API server that our UI depended on until now. We’ve done a few overviews of the new Kubeapps APIs service which makes this possible (see Kubeapps APIs: Beyond Helm, or the TanzuTV episode 74 where Antonio gives an in-depth demo of the Carvel support), or more recently, a demo of the Flux and Carvel support together:
We’ve been able to run Kubeapps in a multi-cluster setup on various Kubernetes clusters for a while now, but this was dependent on the Kubeapps’ user being authenticated in a way that all the clusters trust. Up until now, this meant having all the clusters configured to trust the same OIDC identity provider, which is not possible in some Kubernetes environments.
Particularly, this meant we were unable to demonstrate multi-cluster Kubeapps with clusters created by Tanzu Mission Control since we can’t specify API server options, such as OIDC configuration, when creating a cluster in TMC. But that requirement has now changed thanks to a new project called Pinniped.