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.

Not until the early did the concept of a container-based application emerge to transform the IT world. For the first time, the software was deployed consistently and reliably regardless of the target environment’s changes (private or public cloud, personal computer, etc.). With the development of containers, container orchestration has become a trending topic in recent years, with successful applications from the likes of tech giants Facebook, Google, Netflix, among others.

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.

Deciding whether to run applications in containers or virtual machines used to entail analyzing which trade-offs you could accept in exchange for certain advantages. With Firecracker, we can leverage the benefits of both technologies. In this blog post, we are going to talk about why exactly Firecracker is setting the serverless computing world on fire and what you need to know about this emerging technology.

When making changes to applications these days, it’s hard to understand and predict the impact of those changes before you deploy. API connections are multiplying, and with new cloud platforms such as containers/serverless, it only add to the complexity. Some people have trouble remembering whether they closed the garage door or turned off the coffee maker. Can you remember all the details of your latest API contract change? Let alone who would be impacted and needed to be notified?

Nowadays developers are in the driver’s seat regarding a lot of decisions for the tools they use. In this update from Tyler Jewell, he covers what he sees are the Top 5 trends that will take place this year. While it’s a bit of a crowded chart, he plots the companies that he sees driving these trends. If you drill into the Service Catalog trend, Jewell sees a couple of different groups working on ways to help developers deal with the deluge of Services (aka APIs).

Innovation in hypervisor technology in the early 2000’s from both commercial and open source projects was the genesis for the public cloud as we know it today. Virtualization and Moore’s law, together with advances in storage technology, mobile and wireless, created a data explosion that continues to accelerate through today.

In a recent blog post, one of my teammates, Josh, shared a few techniques for deploying Java agents in Kubernetes applications. We have been getting a lot of interest in the concepts we have shared and, per popular request, decided to raise the bar. Is it possible to add a Java agent without changing a single line in either the Dockerfile or the Kubernetes Manifest? Well, the answer is most definitely yes (!), and here’s how.

Over the last few years, we have seen an avalanche of tools to enable easier software development on Kubernetes (let’s face it, it is quite hard out of the box). As often happens in growing ecosystems, some tools grow and adapt, while others get left behind, or at the very least, merged into new offerings. What’s a better way to open 2021 than with an up-to-date review of the options we have?