As expected, I was not able to stick to my weekly schedule. As I said before, it’s likely that I will miss the weekly scheduled for a few more weeks but I hope to get back to that frequency soon. We’re all socially distancing ourselves right now, which means I am spending almost all of my time at home right now. Moreover, I am working all nights right now and it has led to some weird midnight snacks. The photo that you see on this post is one of the less weird ones.
My schedule has also limited the time I can spend reading and researching various things. But I am thankful to be exposed to various things occasionally. Even if I can’t go into something in detail right now, I know I can save that for a few weeks later when my schedule should be better. For example, I started learning Go recently and I am still due to start the project I wanted to try out. But I keep reading up about various developments in Rust in various areas (most prominently, Deno). I am tempted to begin learning Rust but that has to wait. There are a lot of things I have started and on my plate right now. I can’t afford to pick up something new.
For now, I’ll jump on what I did manage to document from my learnings this last two weeks.
Authenticity
This is from a WorkLife podcast episode on how authenticity is a double-edged sword. Here, Adam Grant talks about how being authentic can backfire. In one place, he recollects “Be yourself, if you’re not an a*hole”. One of the traits of being authentic is demonstrating vulnerability. But it has to be done tactfully. He recounted the story of a speaker at an event with a tough crowd. In that instance, the speaker started off by joking that he was worried because had hit the previous speaker with bread rolls. He shows vulnerability but only about the situation, not about his competence.
Showing vulnerability is good, but only if you have already demonstrated competence.
This helps because you are showing you’re relatable but you have to already be impressive before that. Authenticity without boundaries is careless. Be careful that the vulnerability you choose to show doesn’t cast doubts on your competence. As a manager, I find this extremely relevant as I keep measuring my words carefully.
The story of LetsEncrypt
I thought I knew what I needed to know about LetsEncrypt until I listened to this Changelog episode. This episode covers the history of how LetsEncrypt came to be through an interview with Josh Aas. LetsEncrypt is a free certificate authority that provides SSL certificates for about 200 million websites as of this writing.
The keyword here is “free”. Before this, SSL certificates were out of reach for most people. When the HTTP/2 protocol was being discussed, there was a discussion about whether TLS encryption should be required for this protocol. It seemed obvious that it should be, but SSL certificates used to be beyond means for most people. Hence, LetsEncrypt started its work on making SSL certificates free.
The episode covered why the certificates are that expensive (because setting up a Certificate Authority is a long expensive process). Which is why LetsEncrypt started that process but also affiliated with a well-supported existing CA (Certificate Authority) to start having their certificates supported immediately on almost all devices. At the same time, the process of LetsEncrypt becoming a root CA is also coming to a close and by next year, LetsEncrypt should be able to offer root signed certificates.
The discussion was highly insightful with topics like values of LetsEncrypt and Internet Security Research Group, their efforts in transparency, why they have policies for frequent certificate expiry, how they partnered with EFF for the tooling to manage certificates, what problems they do not solve, why you might still want to go with a paid SSL certificate vendor, and a lot more. I highly recommend you listen to this episode.
Terraform Workspaces
A couple of years back, I wrote an elaborate system to manage Terraform state for multiple instances of similar infrastructure (multiple websites which need similar infrastructure and multiple environments for each). That system was a bash script and CI scripts that picks the appropriate state file from remote state storage. It worked well for me and there wasn’t really another option for what I wanted to do.
I came across a similar situation recently but not on the same scale. I didn’t want to write bash scripts and started looking around for an easier solution. From a bit of searching and StackOverflow answers, I found Terraform environments and its successor: Terraform workspaces. From that page, it is basically a way to pick a different state file where all subsequent operations would run. In other words, it is same as what I was doing with a bash script but more robust. This is also validation to me that what I did years back was a valid way to manage multiple instances of infrastructure.
Leave a Reply