You don't need the resource type in the name

2026-Feb-05 • by David Norton

When creating resources in Kubernetes, Terraform, or other declarative infrastructure tools, I often see names like book-api-deployment, user-service-service, or database-db. The resource type is right there in the configuration — why do we need to repeat it in the name?

We don't.

A Kubernetes Deployment resource can just be called book-api. The fact that it's a Deployment is already encoded in the kind field.

# BAD:
apiVersion: apps/v1
kind: Deployment
metadata:
  name: book-api-deployment
# kubectl get deployment book-api-deployment

# GOOD:
apiVersion: apps/v1
kind: Deployment
metadata:
  name: book-api
# kubectl get deployment book-api

Similarly, a Terraform aws_s3_bucket resource doesn't need -bucket appended to its name. The resource type tells you everything you need to know. In fact, there are two ways you can mess up here: the Terraform resource name, and the S3 bucket name. In neither case do you want to repeat the resource type in the name.

# BAD:
resource "aws_s3_bucket" "book_api_bucket" {
  bucket = "book-api-bucket"
}
# aws s3 ls s3://book-api-bucket

# GOOD:
resource "aws_s3_bucket" "book_api" {
  bucket = "book-api"
}
# aws s3 ls s3://book-api

This is Hungarian notation

This pattern of encoding type information in the name is a form of Hungarian notation. Hungarian notation was popularized in the 1990s, particularly in Microsoft Windows programming, where you'd prefix variables with type information like strUserName or iCount. The idea was that this would help prevent type-related bugs.

However, modern programming languages have strong type systems, IDEs with autocomplete, and linters that catch these errors for us. We don't need to encode type information in variable names anymore. Similarly, declarative infrastructure tools already encode the resource type in their configuration. Adding it to the name is redundant.

The problems with redundant type information

When you include the resource type in the name, you create several problems:

Names get longer. Character limits are real. AWS Lambda function names are limited to 64 characters. S3 bucket names are limited to 63 characters. Every character counts, and -deployment or -service wastes precious space.

It violates DRY. Don't Repeat Yourself. The resource type is already in the configuration. Repeating it in the name violates this principle.

What to do instead

Name your resources based on what they represent, not what type they are. book-api represents the book API service. Whether it's a Deployment, StatefulSet, or DaemonSet is an implementation detail that belongs in the configuration, not the name.

If you need to distinguish between multiple resources of the same type representing the same thing, use descriptive suffixes. For example, if you have both a Deployment and a Job for the book API, you might name them book-api and book-api-migration. The -migration suffix describes the purpose, not the type.

The exception

In most cases, just use book-api. Your future self will thank you when you need to refactor, and your resource names will be cleaner and more maintainable.

Shameless plug: If you need help with public cloud, declarative infrastructure -- Platformers can probably help. Please reach out today!