Troubleshooting customer issues in production is a difficult job. These are the issues that impact the business the most, so consequently, stress levels are almost always at a high. And it’s never fun to be measured against an SLA, which feels like you’re stuck in a losing battle. And it’s especially hard in the world of microservices and Kubernetes, because it’s so difficult to recreate a reliable replica of production in your local development environment.

Over the last year, we have witnessed a shift in engineering working habits. COVID-19 forced many of us into lockdown. Instead of working from the office, coffee shops, and airport lounges, I found myself mostly working out of my (hastily built) home office. For many of us, this meant shifting back to a workstation over a trusty laptop. Not surprisingly, this did nothing to abate the heated discussion over which computers and operating systems are best for developing software.

Since the beginning of time, back to before humans invented fire, there were two traditional ways to debug applications: one way -after having invented hieroglyphics, of course - was by reading log lines and the other was by using the common debuggers that surrounded a cave dev’s cave. It’s safe to say that society has progressed since then and, luckily, so too has traditional debugging.

You wouldn’t expect an architect to build a skyscraper with just a hammer and a ladder, right? Then why do we sometimes look at developer tools as something ‘extra’, or as a ‘nice to have’, and simply assume that all that a developer needs is a laptop and an internet connection? A skyscraper is built in a fraction of the time and to a much higher quality if the team has access to top of the line equipment.

As R&D managers, we want to make sure our developers are happy and efficient. We want to ensure that they have the bare necessities they require to develop the best applications, whether it be the right desktops, the right headset, the right brand of coffee, and as many cookies as our budget can afford.

The R&D team at every company is made up of a variety of personalities- developers, tech leads, team leads, you name it. The Product team is also quite a diverse group and is usually made up of creative UI/UX designers and product managers. When you throw them together, you get a meaningful relationship that creates magical features for top-notch products.

Over the last few days, I have been hard at work writing an up to date comparison of Kubernetes tooling (check out the first and second posts if you haven’t already, which cover tools that help you reproduce issues locally). Going through the sprawling Kubernetes ecosystem and curating the knowledge that would be the most interesting to fellow developers and engineering managers has been no small task. That’s why section 3 will cover the heart of cloud-native development: the IDE.

Over the last few blog posts, I have covered critical elements of developer tooling for Kubernetes and how things are looking in 2021. As we continue to dive into that discussion, we must not forget the process of building container images. Of course, most of us create our images by writing Dockerfiles and building them with the Docker engine. And yet, more and more teams are adopting newer alternatives.

If you have been keeping track, I recently started a series of blog posts about the state of developer tooling in the Kubernetes ecosystem in 2021. The first blog post covered the topic of defining Kubernetes applications, i.e., how you go about declaring, packaging, customizing, and deploying them. You can check out that up to date comparison between category leaders Helm and Kustomize right here.

As all developers know, when building software things don’t always go as planned. In fact, most of the time they don’t. With today’s modern distributed architectures it’s more important than ever to have the proper tools in your toolbelt. This allows us to automate as much of the software delivery lifecycle as possible and then be able to immediately triage issues when they arise.