In a Twitter thread between Vito Botta, Alex Ellis, and myself, we talked about how expensive DigitalOcean can be for personal projects. You often start off small with just a cluster for compute. Eventually you need a database to store your user’s information. As time goes on, these needs only continue to grow. In this post, I share some cost-saving techniques I’ve used to reduce my bill.
In this post, I bring a conclusion to my recent series on tracking impressions on repositories. While it’s the last in the series, I will likely continue to post updates as time goes on. For now, I feel my current approach has yielded a wealth of information that I’m still fully digesting. In this conclusion, I will walk through how several of my metrics have changed since my original approach.
Last week, I put a tracking pixel on my GitHub repositories. And I’ve got to say, the results have been really interesting. In this post, I follow up on what I’ve learned since last week, changes I’ve made, and improvements I’m working through.
Join me on the WomenInTech show. In this episode, Espree and I discuss my journey into tech. From my early days working on things in high school to the work I do today. I hope you enjoy the show!
In November 2018, I decided to return to Indeed.com. The decision to return did not come easy. Since then, I have frequently been asked about my reasons for rejoining. In this post, I hope to cover my interviewing process and some reasons that I had for returning.
Over the last year, I’ve been heavily working on deps.cloud. deps.cloud draws it’s inspiration from a project that I worked on at Indeed.com. Since it’s original inception, there had been a heavy push to move it into the open source space. In this post, I’ll discuss the process and rationale I applied as I rewrote this project in the open.
Join me on the Software Engineering Daily podcast. In this episode, Jeff and I discuss my personal project deps.cloud. We discuss benefits and tradeoffs to leveraging monorepos as well as challenges mainting source control at a large organization. I hope you enjoy the show!
Back in July, I found myself needing to better coordinate deployments of my applications to Kubernetes.
After searching around, I found many ways that people where trying to solve this problem.
Some used shell scripts to apply multiple YAML files with a fixed time sleep between them.
Others used shell scripts and tailed the rollout using
kubectl rollout status -w.
Now, I manage a lot of my deployments using GitOps and Flux.
So leveraging these shell scripts to manage my rollouts into clusters wasn’t really an option.
It wasn’t until I came across Alibaba Cloud’s blog post on solving service dependencies that I felt like I had something to work with. The article described two techniques. The first was inspecting dependencies within the application itself. At Indeed, we leverage our status library to do this. The second was to enable services to be checked, independent of the application.
In this post, I’ll demonstrate how to use my service-precheck initialization container (built off of the Alibaba blog post) to ensure upstream systems are up before attempting to start a downstream system.