Kubernetes just turned 7 years old, and over the last couple of years, it has risen in popularity to be the key platform for microservices management consistently. The ecosystem around it is also growing rapidly.

In a previous post, we discussed the rise of the developer platform and how developer productivity is one of the main reasons why many organizations are either looking for or building an internal developer platform (IDP). According to a recent global survey done by Stripe, on a scale of 0 – 100%, developers responded that only 68.4% of their time is productive, which means that developers could be nearly 50% more productive than today: (100% — 68.4%) / 68.4% = 46%

Network Policy is a critical part of building a robust developer platform, but the learning curve to address complex real-world policies is not tiny. It is painful to get the YAML syntax right. There are many subtleties in the behavior of the network policy specification (e.g., default allow/deny, wildcarding, rules combination, etc.). Even an experienced Kubernetes YAML-wrangler can still easily tie their brain in knots working through an advanced network policy use case.

I have recently seen quite a few articles and talks covering why organizations are aiming at implementing a developer platform to help speed up the adoption of microservices within their organizations but before we get started on discussing what a developer platform is, the developer experience and productivity on Kubernetes, and how different teams are working through it, let’s define some common ground.

In this video with with Kohsuke Kawaguchi (KK) from Launchable and Viktor Farcic we talk about testing K8s applications. Do we really need to write all the tests every time we make a change to the source code or make a release? That could take minutes or even hours. Wouldn’t it be better to run only the tests related to the changes we are making or the phase of the lifecycle of an application? Is the future of testing in AI and ML?