In cloud-based systems, service names are everywhere. They're in deployment pipelines, monitoring dashboards, cost reports, and architecture diagrams. Yet for something so fundamental, service naming remains surprisingly chaotic in most organizations.
We've seen it repeatedly: successful systems that grow into nightmares of inconsistent naming. Services called "Commerce-PaymentService-V2-Production-US-East" sit alongside "payment_svc_new" and "PaymentsAPI_GraphQL." Each name embeds different assumptions about what matters. None of them age well.
The problem compounds as systems mature. Organizations restructure, technologies change, and deployment strategies evolve. Service names that once made sense become historical artifacts—confusing remnants that no longer reflect reality but are too painful to change.
A service name should describe what the service does. That's it.
Not who owns it. Not what technology it uses. Not where it's deployed or what version it is. Those details matter, but they belong in tags, resource identifiers, and version numbers—places designed to hold information that changes.
At SPAN, we've distilled this thinking into a specification called Semantic Service Naming (SemServ). The approach is straightforward: compose service names from elements that describe the service's purpose and nothing else.
SemServ = [Namespace.] [Domain | Entity] - [Role]
Every service name consists of two required parts:
Examples: Payment-Processor, Settlement-Distributor, Ticket-Dispatcher
For larger systems with multiple subsystems, you can add an optional namespace prefix: Finance.Order-Processor, Toolchain.Build-Scheduler
The service name becomes the foundation for naming related objects:
Modern cloud providers already capture most of the information people try to cram into service names. AWS uses Amazon Resource Names (ARNs) that encode account, region, and resource type. Azure has Resource IDs. GCP has Resource Names. This information is standardized, queryable, and automatically maintained.
When you embed region or account information in a service name, you're duplicating data that's already captured elsewhere. Worse, you're creating a maintenance burden. Change regions? Restructure teams? Adopt a new deployment strategy? Now you're looking at mass renaming. A task so onerous that most organizations avoid it, leaving behind confusing names that no longer match reality.
SemServ sidesteps this by focusing on what doesn't change: what the service fundamentally does.
Semantic Service Naming won't solve every naming problem in your architecture. It's not meant to. It solves one specific problem well: creating service names that stay meaningful as systems evolve.
In environments where services proliferate rapidly and teams turn over frequently, small standards like SemServ reduce friction. Engineers can look at a service name and understand its purpose without archaeological investigation. New team members orient faster. Operators troubleshoot more effectively.
The specification is simple enough to remember without referring back to documentation. That's by design. Complexity in naming conventions creates the same problems as complexity in codebases—confusion, inconsistency, and eventual abandonment.
The full SemServ specification, including a Backus-Naur Form grammar and detailed FAQ, is available at semserv.org. It's published under Creative Commons licensing and open to community contribution through GitHub.
Start with new services. As you develop clear boundaries between domains and understand the roles services play, the names often write themselves. For existing systems, rename opportunistically when you're already making significant changes, or when the confusion cost outweighs the refactoring cost.
The goal isn't perfection. It's reducing the accidental complexity that accumulates in large systems and refocusing attention on the problems that actually matter: building software that solves real challenges for real users.
The Semantic Service Naming specification was created by John R. Harris, cofounder of SPAN Digital, and inspired by Semantic Versioning. Learn more at semserv.org
