For this report, we compiled usage data from tens of thousands of companies and more than 2.4 billion containers, so we are confident that the trends we have identified are robust. But while Datadog’s customers span most industries and run the gamut from startups to Fortune 100s, they do have some things in common. First, they tend to be serious about software infrastructure and application performance. And they skew toward adoption of cloud platforms and services more than the general population. All the results in this article are biased by the fact that the data comes from our customer base, a large but imperfect sample of the entire global market.
We excluded the Datadog Agent and Kubernetes pause containers from this investigation.
For this report, we consider an organization to be a container organization if it runs cloud provider-managed or self-managed containers from either Kubernetes or non-Kubernetes-based services.
A container organization is considered to run serverless containers if it uses at least one of the following services:
- AWS: AWS App Runner, ECS Fargate, EKS Fargate
- Azure: Azure Container Instances, Azure Container Apps
- Google Cloud: Google Cloud Run, GKE Autopilot
We measured usage of containerized instances that were GPU-based. We considered the following instance types to be GPU-based:
- AWS: F1, G3, G4, G5, Inf1, Inf2, P3, P4, P5, Trn1
- Azure: standard_n
- GCP: g2, a2
We measured compute usage of containerized instances running on Arm-based architecture. We considered the following instance types to be Arm-based:
- EKS: Graviton-based EC2 instances
- AKS: Ampere-based VMs
- GKE: Tau T2A Arm-based VMs
We determined resource under/overutilization by computing the hourly average of CPU or memory used by each container and dividing it by the hourly average of its resource request. We compiled these values over the course of multiple days and used them to generate a representative picture of resource utilization across a diverse set of workloads.
For this fact, we grouped workloads into the following categories, based on open source container image names:
- Databases: Redis, MongoDB, Postgres, MySQL, Cassandra, etcd, Oracle, MariaDB, memcached, CouchDB, Couchbase, CockroachDB, Microsoft SQL Server, IBM Db2, HBase, SAP HANA, InfluxDB, IBM Informix, Solr.
- Messaging Kafka, RabbitMQ, ActiveMQ, RocketMQ, HiveMQ, KubeMQ.
- Streaming Kafka Streams, Spark, Flink, Airflow.
- CI/CD: GitLab, Argo CD, Jenkins, Flux, GoCD, Keptn, GitHub Actions, Argo Rollouts, Tekton, TeamCity, CircleCI, Travis CI, Bamboo.
- Analytics: Hadoop, Elasticsearch, TensorFlow, Solr, RNN, Caffe2, PyTorch, Scikit-learn, Apache MXNet, Spark MLib, Keras.
- Internal developer platforms: Crossplane, Garden, Ketch, Coherence, Mia, Humanitec, Cortex, Roadie, OpsLevel, Qovery, Argonaut, Appvia, Gimlet, Upbound.
- Web servers: Apache HTTP Server, Apache Tomcat, NGINX, CentOS Stream, LiteSpeed Web Server, Caddy, Lighttpd, Microsoft IIS, Oracle WebLogic Server, OpenResty, Apache Geronimo.
We considered organizations to be using a service mesh if they were running at least one container with an image name that corresponded to one of the following technologies: Istio, Linkerd, Consul Connect, Traefik Mesh, NGINX Service Mesh, AWS App Mesh, Kong Mesh, Kuma Mesh, Cilium Service Mesh, OpenShift Service Mesh, Meshery, or Gloo Mesh.
Kubernetes version usage is based on data from September 2023.