Blog

When delivering software to clients, many independent software vendors (ISVs) still rely on methods involving traditional software packaging methods such as downloadable binaries, ZIPs, or other type of compressed delivery. These distribution approaches are often OS specific. As a result, developers are forced to spend precious time on tailoring software delivery rather than innovation. Containerization is already simplifying software delivery for many of today’s mainstream products. Choosing the right container registry that meets ISVs requirements is crucial to satisfy vendors and meet client expectations.

Developing and testing software on Kubernetes usually means building and moving container images from the developer workstation to a container registry, and ultimately, Kubernetes. When considering all the moving parts, the complexity and context switches break the development flow. Gone are the days where developers just hit a command and a few seconds later the newly built software is ready for testing.

What if there was some magical tool that you could simply feed instructions like: “Build this Dockerfile here and replace any existing image on that Kubernetes cluster with the results!” ASAP. Spoiler Alert! That is exactly what BuildKit CLI for kubectl is there to do.

The newly introduced Docker Hub pull rate limit affects everyone working with containers and can cause service disruption. In this post, we look at situations when the download rate limit can catch you off-guard if you are not prepared. We also outline 3 ways to overcome the Docker Hub pull rate limit while also improving security and governance.… Read on