KubeFox distills deployments to unique components only. Your teams deploy at the App level. If an App comprises 40 components and 3 components are changed for a new version, then only those 3 components will be deployed. From a developer's perspective, they are running a different version fo the App. From a provisioning perspective, you're supporting those two versions on the same cluster with the minimum number of resources.

KubeFox can support multiple versions of an App simultaneously on the same cluster, but with the minimum number of components (defined as unique components only). It can achieve this because it routes requests dynamically at runtime. Technical gobblygok aside, that means that KubeFox can use unchanged components for different versions of an App - all the while making it appear that each version is running in isolation on the cluster.

One school of thought is that DevOps is threatened by KubeFox. While it's true that KubeFox handles many DevOps tasks automatically and mitigates or eliminates others, a better school of thought is that DevOps is relieved of day-to-day low-value provisioning exercises and can focus on more strategic endeavors, e.g., building ecosystems that help your teams succeed, evaluating third party value add products etc.

Teams spend a suprising amount of time dealing with provisioning and otherwise coordinating resource utilization - which translates into those teams handling DevOps (smaller orgs) or funneling their activities through DevOps (larger orgs). That time is subtracted from the advancement of your business. KubeFox mitigates this by handling many DevOps tasks without teams really having to think about them.

Instead of teams and developers competing for resources and coping with and managing around DevOps, they can instead focus their attention on Apps. You know - the things that actually generate revenue and help you drive your business forward.

The dirty little secret is that even in orgs with good cultures, an inordinate amount of time is spent on provisioning and coordinating resource utilization. Even good DevOps teams that operate apolitically, are forced to constantly balance the needs of each team and prioritizing, or creating complex namespace structures that themselves become bureaucratic nightmares. The reality is that teams spend far too much time procuring and managing resources - time that would be better spent on innovation.

This just doesn't seem possible, does it? But what we're really talking about here is the effort that must be invested in coordination when that coordination would not be required if developers operated as if they were running on independent clusters. At the same time, imagine if those teams could push their parts of the technology forward, and connect their efforts to those of other teams - sometimes without deploying anything. How fast could they - and by extension your business - move?

Development teams spend a great deal of time coordinating activities around resource utilization and deployment. The best case scenario is to enable teams to function as if they are operating independently. Today that usually means over-provisioning. With KubeFox, teams and even developers on the same team can operate as if they're in independent sandboxes.

Engineering today is funneled through DevOps for resource utilization coordination, and Agile discussions too often revolve around coordination of changes with other teams. Now - that coordination can be a healthy thing if it revolves around well-defined interfaces and moving technology forward. But it's not so healthy if it involves Team A waiting for Team B - particularly if the constraint involves resource provisioning, cluster namespace manipulation or network configuration.

Teams can support your business best if they can function in an environment where rapid prototyping and proof-of-concept exercises are facilitated to the greatest extent possible. And if developers can innovate rapidly, they're generally happy. And if they're happy, then you stand a better chance of retaining them. And if your teams are strong, your business advances faster than that of your competitors.

We wouldn't be doing the topic justice if we attempted to list all of the benefits of Kubernetes here. Suffice to say, it is the best, most powerful and most widely-used orchestration ecosystem in existence. And it's not cloud-only - it's the best ecosystem for on-prem Apps as well. KubeFox eases that transition by providing technologies that obviate the need for developers to learn DevOps at the same time they're getting up to speed on microservices. Developers are freed to contemplate App architecture as opposed to ecosystem configuration.

Moving from monolithic architectures to microservice and function-as-a-service architectures is not a simple exercise. KubeFox can greatly simlify those exercises by dealing with some of the most complex aspects, e.g., interfaces, deployment, versioning, intra- and inter-system routing, zero trust and telemetry. And because teams can prototype and test so quickly, porting is expedited.

Don't take our word for it - you can see if for yourself. Walk through our Quickstart and Hasura tutorial and imagine what the implications would be for application development and provisioning control. The truth is that in a KubeFox environment, developers are largely insulated from Kubernetes management and can iterate and innovate rapidly.

Another dirty little secret... Security - for any App - is not easy. When we first conceived of KubeFox, we felt that zero trust should be built in. Without developers thinking about how they were going to build zero-trust into each component composing their applications. KubeFox handles some of the most complex pieces of this equation for you.

Developers don't need to figure out how they're going to implement AuthN in component-to-component interfaces. Instead, KubeFox performs that authentication.