The promise of Zero Environment Development (ZED) is transformative: develop locally with the speed and tools you love, while seamlessly interacting with your cloud-native applications as if your local machine is part of the Kubernetes cluster. At Codezero, we're passionate about making ZED a reality. But with any powerful new approach, the question often arises: "Where's the best place to start?"
Choosing the right initial use case can help showcase the benefits of Codezero and pave the way for broader adoption within your team. Let's dive into what we consider an ideal pilot project.
Picture this common scenario: your company has a sophisticated multi-service application—perhaps five, ten, or even more microservices, all humming along in a shared Kubernetes development or staging cluster. A developer, let's call her Sarah, needs to jump in to develop a new feature for, or debug an issue in, just one of those services—we'll call it: "Service B
".
Service B
isn't an island; it depends on Service A
, Service C
, and potentially a host of other services and data stores running within that same Kubernetes cluster.
Sound familiar? Now, consider the challenges Sarah faces without Codezero:
significant challenge. Even just running part of the app stack locally is a pain. It's resource-intensive, complex to configure, and prone to the infamous "works on my machine" syndrome.
The "Deploy-to-Test" Slog: Continuously deploying every minor code change of Service B
to the shared Kubernetes cluster just for testing is just s_l_o_w.... It breaks the development flow and can inadvertently disrupt other team members relying on that shared environment.
kubectl port-forward
commands for every single dependency (Service A
, Service C
, databases, message queues) is cumbersome, error-prone, and needs constant readjustment.These hurdles are exactly what Codezero is designed to eliminate.
The ideal starting use case for Codezero directly tackles the scenario above: empowering Sarah to develop and debug Service B
locally, while remaining seamlessly connected to its dependencies running in the shared Kubernetes cluster.
Here’s how Codezero transforms her workflow:
czctl consume
command (or a few clicks in the Desktop app), Sarah instantly makes Service A
, Service C
, and any other required services or resources from the Teamspace available to her local environment. Codezero transparently handles the complex networking, making these remote services appear as if they're running right on her machine. (You can learn more about this in our Consuming Services Documentation).Service A
locally, using her favourite IDE, debugger, and development tools. With another straightforward command, czctl serve namespace/service-A 8000
(or via the Desktop app), she instructs Codezero to intelligently route traffic intended for Service A
, within the context of her development session or based on specific routing rules she defines, from the Teamspace directly to her local instance. (Check out the details in Serving Variants ).Service B
locally and test them immediately. She can interact with the entire application (requests might originate from other services in the Teamspace and flow to her local Service B
), set breakpoints, and debug in real-time. Her inner development loop becomes incredibly fast and efficient.Focusing on this "single local service, multiple remote dependencies" pattern for your first Codezero project offers several advantages:
Service A
. This makes it easier to learn the workflow and understand the benefits without the pressure of a large-scale, team-wide rollout.This focused approach allows your team to experience the power of ZED by dramatically improving the inner development loop for a common, often frustrating, task. It's an excellent way to introduce, evaluate, and build enthusiasm for Codezero.
You can try all this locally with our live Tutorial app or sign up for a Free Teamspace today.
Ready to give it a try and say goodbye to environment complexity?