github.com/anth0d/nomad@v0.0.0-20221214183521-ae3a0a2cad06/website/content/docs/nomad-vs-kubernetes/supplement.mdx (about)

     1  ---
     2  layout: docs
     3  page_title: Supplement to Kubernetes
     4  description: Comparison between Nomad and Kubernetes
     5  ---
     6  
     7  # Supplement to Kubernetes
     8  
     9  Enterprises are comprised of multiple groups of people (business units) with different projects, infrastructure environments, technical competencies, team sizes, budgets, and SLAs. Each group has different requirements and leverages technologies based on their particular needs and constraints.
    10  
    11  Medium to large scale enterprises run into challenges when trying to standardize hundreds to thousands of software developers and administrators onto one single orchestrator (Kubernetes, Nomad, Mesos) as no scheduler today fits all applications, environments, projects, and teams.
    12  
    13  Companies in the Global 2000 today such as Intel, Autodesk and GitHub with multiple products and business units organically run Nomad and Kubernetes to supplement each other. They leverage each scheduler to its strengths with Kubernetes for its cutting edge ecosystem and Nomad for simple maintenance and flexibility in core scheduling.
    14  
    15  ![How organizations leverage Nomad and Kubernetes](/img/nomad-kubernetes.png)
    16  
    17  These are the characteristics we see in teams that typically adopt self-hosted Kubernetes:
    18  
    19  - Greenfield use-cases such as machine learning (ML), serverless, and big data that require the Kubernetes ecosystem and Helm chart
    20  
    21  - High budget and full-time staffing to maintain Kubernetes
    22  
    23  - High-profile projects with significant investment and long-term timeline (multi-year)
    24  
    25  - Deploying and managing new, cloud-native applications
    26  
    27  - Public cloud environment such as AWS, GCP, Azure
    28  
    29  Characteristics of teams that typically adopt Nomad:
    30  
    31  - Run a mix of containerized and non-containerized workloads (Windows, Java)
    32  
    33  - Small/medium-sized teams with limited capacity to maintain an orchestrator
    34  
    35  - Deploying and managing core, existing applications
    36  
    37  - On-premises environment, or hybrid environments
    38  
    39  - Require simplicity to move fast and fulfill business needs with hard deadlines
    40  
    41  We continue to see small enterprises continue to standardize on a single orchestrator given the natural staffing and organizational constraints. There are not enough DevOps members to maintain more than one orchestrator, not enough developers to warrant diverging workflows, or simply not enough workload diversity to require more than one orchestrator.