# Kuma vs XYZ
When Service Mesh first became mainstream around 2017, a few control planes were released by small and large organizations in other to support the first implementations of this new architectural pattern.
These control planes captured a lot of enthusiasm in the early days, but they all lacked pragmatism into creating a viable journey to Service Mesh adoption within existing organizations. These 1st generation solutions are:
- Greenfield-only: Hyper-focused on new greenfield applications, without providing a journey to modernize existing workloads running on VM and Bare Metal platforms where the current business runs today, in addition to Kubernetes.
- Complicated to use: Service Mesh doesn't have to be complicated, but early implementations were hard to use; they had poor documentation and no clear upgrade path to mitigate breaking changes.
- Hard to deploy: Many moving parts, which need to be running optimally at the same time, makes it harder to run and scale a Service Mesh due to the side-effect of higher operational costs.
- For hobbyists, not organizations: Lack of understanding of the challenges enterprise organizations face today, with poor support and implementation models.
Kuma exists today to provide a pragmatic journey to implementing Service Mesh for the entire organization and for every team: for those running on modern Kubernetes environments and for those running on more traditional platforms like Virtual Machines and Bare Metal.
- Universal and Kubernetes-Native: Platform-agnostic, can run and operate anywhere.
- Easy to use: Via automation and a gradual learning curve to Service Mesh policies.
- Simple to deploy: In one step, across both Kubernetes and other platforms.
- Enterprise-Ready: Pragmatic platform for the Enterprise that delivers business value today.