I enjoy "bending" the English language, but this post is more about getting things straight.
Software folks tend to banty-about the terms "server", "service", "endpoint", "session", and "serverless" without hesitation. These aren't exactly jargon words, and most of the time we just need to roll with them, but they do lack precision in many conversations.
In an architecture meeting you may hear these terms used interchangeably, and stopping the conversation to debate the nuanced differences in meaning probably wouldn't have been helpful. But it *is* helpful for a team to share an understanding of what they each mean in the context of their work and avoid the friction and "in the box thinking" imprecise definitions can cause.
So, let's untangle these terms with some clear, practical definitions I'll reference in future articles.
Server
A "server" has evolved to have several meanings:
- Physical hardware: Originally, this was the primary meaning -- a physical computer, likely in a rack and accepting connections from clients.
- Virtual machine: Today, a server is often a virtual machine (VM) running on a physical server (or within another VM), likely in a data center.
- Process: An executable that listens on a port and handles requests (nginx, Apache, PostgreSQL), likely running in a VM or container but perhaps on a physical machine.
What a server is not: A domain name or IP address, and port. Those identify an *endpoint* where a service is accessible, not the server itself. A domain, or even a single IP may afford connections to a set of machines.
This matters because when we say "we need an XYZ server," we're conflating the implementation (a server) with the capability we actually need (a protocol implementation). This narrows our thinking before we've even begun solving the problem.
Service
A service is a capability offered over a network. It:
- Implements specific functionality (authentication, data storage, message processing)
- Requires an application protocol and drives some business capability
- Is available at one or more endpoints
- Is defined by what it does, not how it's implemented
For example, a RADIUS service provides authentication, authorization, and accounting -- regardless of whether it runs on physical hardware, VMs, or as serverless functions. A DNS service provides name resolution.
The "what it does" of a service is often implemented with business-specific configuration and customizations.
When we focus on services rather than servers, we expand our solution space. We start asking better questions: "What capability do our clients need?" instead of "How many servers should we provision?"
Endpoint
An endpoint is where a service is accessible. It typically consists of:
- A network address (IP address or host/domain name)
- A port number
- Sometimes a path or resource identifier
Clients connect to endpoints, not directly to servers or services. An endpoint is essentially the "front door" to a service. Most often domains are use for their flexibility, but "anycast" IPs are becomming more
This distinction helps when designing resilient systems. Multiple endpoints might lead to the same service, or a single endpoint might be backed by multiple service instances for reliability.
Serverless
Despite the name, serverless doesn't mean "no servers." It means:
- Servers exist but are abstracted away from the developer
- Resources scale automatically with demand
- You pay only for what you use
- The focus shifts to functions and event or message handlers rather than server management
Serverless is more about the sharing of servers and outsourcing of the operational model, rather than the actual absence of servers.
When we talk about "going serverless," we're really saying: "Let's focus on the business logic of our service without managing the underlying infrastructure."
Does this matter? Consider this scenario: Your team needs to process UDP messages arriving sporadically from a large fleet of IoT devices. Thinking (or say)ing "we need a UDP server" might lead to considering options to spin up EC2 instances or containers. It's a familiar and well-worn path.
But those servers will need updates and patches, scaling groups, other operational complexity (VPN, NAT, etc.). More subtly, and perhaps most impactful, when you choose software designed to run on a "server" you also accept submlime architectual constraints. Much of the server software available today was designed long ago to run synchronously and in lock-step, perhaps even in a single thread. That means that calls to downstream services (databases, storage, etc,) must also be synchronous, and that the server must be able to support the load of the network handling, business logic and waiting for responses from downstream. All solvable, but neccessary?
A slight rephrasing, aaying "we need a XYZ service" opens thinking to more options: maybe what you really need is a way to process XYZ requests synchronously, or asynchronously, or both? Thought can shift to the workload -- is it constant, cyclical or episodic? Local or global (a server can't be split between regions, but a service can).
This shift in perspective -- from server to service -- can lead to architectures that are more flexible, cost-effective, and focused on the actual business needs.
Let's see how these terms manifest in a real-world scenario:
- Your users need to authenticate to use your network (service: authentication)
- This is available at radius.example.com:1812 (endpoint)
- Traditionally, this would run on a dedicated machine (server)
- In a modern approach, this might be a function that processes RADIUS packets, scales on demand, and has no visible server (serverless)
Server or serverless, clients are connecting to the same endpoint to use the same service. The implementation differs, but the capability doesn't.
Using precise terminology may seem pedantic and breaking old habits can be frustrating, but it's practical in eastablishing a common understanding and widening our perspectives during design. When we separate servers (implementation) from services (capability), we can think more clearly about what we're building and why.
So the next time someone states "we need a server," you might ask: "Do we need a server, or do we need a service?" The answer might lead to a better solution.