Computer networking basics every developer should know – As a software engineer, I need to deal with networking every now and then - be it configuring a SOHO network, setting up container networking, or troubleshooting connectivity between servers in a data center. The domain is pretty broad, and the terminology can get quite confusing quickly. This article is my layman’s attempt to sort the basic things out with the minimum words and maximum drawings. The primary focus will be on the Data link layer (OSI L2) of wired networks where the Ethernet is the king nowadays. But I’ll slightly touch upon its neighboring layers too.
SLO alerting for mortals – This post shows the math of creating an alert for a service level objective (SLO), step-by-step (and with animations), including how to avoid alerting for the entire sliding window even after the problem is fixed.
What every software engineer needs to know about the world’s most overhyped technology – The service mesh—some people love it. Some people hate it. Most don’t understand it. William Morgan belongs to the second group. In this post he explains what the service mesh is and why he thinks it’s overhyped.
SRE Capability Map – This map shows all capabilities that fit the SRE domain. Use it to build and guide your org’s SRE function.
5 Linux Network Troubleshooting Commands – Linux provides many command-line tools to help sysadmins manage, configure, and troubleshoot network settings. This article covers five network configuration and troubleshooting tools for Linux.
Learning containers from the bottom up – When I started using containers back in 2015, my initial understanding was that they were just lightweight virtual machines with a subsecond startup time. With such a rough idea in my head, it was easy to follow tutorials from the Internet on how to put a Python or a Node.js application into a container.
Soft Serve – A tasty, self-hostable Git server for the command line.
Logpaste is a simple service you can run for those times when you want to easily share log file snippets or other text.
How to use dig – When I first started using dig I found it a bit intimidating – there are so many options! I’m going to leave out most of dig’s options in this post and just talk about the ones I actually use.
Some reasons to measure – A question I get asked with some frequency is: why bother measuring X, why not build something instead? More bluntly, in a recent conversation with a newsletter author, his comment on some future measurement projects I wanted to do (in the same vein as other projects like keyboard vs. mouse, keyboard, terminal and end-to-end latency measurements) was, “so you just want to get to the top of Hacker News?” The implication for the former is that measuring is less valuable than building and for the latter that measuring isn’t valuable at all (perhaps other than for fame), but I don’t see measuring as lesser let alone worthless. If anything, because measurement is, like writing, not generally valued, it’s much easier to find high ROI measurement projects than high ROI building projects.
Overengineering can kill your product – I believe it because we will talk about one of the most prevalent issues when creating products: overengineering them. In my opinion, overengineering has killed more products than the absence of good development practices.