What is DC/OS?
Unlike traditional operating systems, DC/OS spans multiple machines within a network, aggregating their resources to maximize utilization by distributed applications.
DC/OS is a tool in the Cluster Management category of a tech stack.
DC/OS is an open source tool with 2.2K GitHub stars and 464 GitHub forks. Here’s a link to DC/OS's open source repository on GitHub
Who uses DC/OS?
19 companies reportedly use DC/OS in their tech stacks, including Decision6, Astronomer, and Covve.
63 developers on StackShare have stated that they use DC/OS.
Why developers like DC/OS?
Here’s a list of reasons why companies and developers use DC/OS
- High Resource Utilization
- Mixed Workload Colocation
- Container Orchestration
- Resource Isolation
- Stateful Storage
- Package Repositories
- Public Cloud
- Private Cloud
- Command Line Interface
- Web Interface
- Elastic Scalability
- High Availability
- Zero Downtime Upgrades
- Service Discovery
- Load Balancing
DC/OS Alternatives & Comparisons
What are some alternatives to DC/OS?
See all alternatives
Apache Mesos is a cluster manager that simplifies the complexity of running applications on a shared pool of servers.
Nomad is a cluster manager, designed for both long lived services and short lived batch processing workloads. Developers use a declarative job specification to submit work, and Nomad ensures constraints are satisfied and resource utilization is optimized by efficient task packing. Nomad supports all major operating systems and virtualized, containerized, or standalone applications.
Mesosphere offers a layer of software that organizes your machines, VMs, and cloud instances and lets applications draw from a single pool of intelligently- and dynamically-allocated resources, increasing efficiency and reducing operational complexity.
Apache Aurora is a service scheduler that runs on top of Mesos, enabling you to run long-running services that take advantage of Mesos' scalability, fault-tolerance, and resource isolation.
Its fundamental idea is to split up the functionalities of resource management and job scheduling/monitoring into separate daemons. The idea is to have a global ResourceManager (RM) and per-application ApplicationMaster (AM).