VLAN. CIDR. Subnet mask. Security zone. IP address.
If those fields exist in a network request today, there is a temptation to reproduce them when the request becomes automated. Put them in a portal, expose them through an API, connect the workflow to IPAM or a controller, and the manual ticket becomes self-service.
The implementation may be automated. The service is not.
The customer is just filling out a network engineer’s build sheet.
I think about this when I look at the kinds of network services that are good candidates for self-service: DNS, load balancing, VPC or segmented-network creation, application connectivity, and other repeatable requests. In many of those cases, the network team can determine most of the implementation from a surprisingly small amount of information.
That leads me to a different starting question for automation:
What is the smallest amount of information a customer could give us that would allow us to fill out the rest correctly?
That question changes what gets automated.
Ask for what the customer actually knows
Consider a request for a new network.
A traditional form might ask for a CIDR, subnet size, VLAN, routing context, location, security zone, and several other implementation details. Some of those questions may be necessary inside the workflow. I am not sure they all need to be answered by the person requesting the service.
The customer may know something much simpler:
How many devices or workloads need to be addressed?
From there, the platform could potentially determine an appropriate network size, select available address space, follow organizational standards, create the required network objects, and apply whatever policy belongs to that environment.
Whether the result is a VLAN on a traditional network, a construct inside a fabric, or a subnet in a cloud VPC is important to the engineers operating the infrastructure. It may not be important to the person who needs a workload to have an IP address.
The implementation details still exist. The difference is who has to understand them.
The network team built the standards and has access to the address-management system, controllers, routing design, security policy, and available capacity. If we are the subject-matter experts, it seems strange to require the customer to reverse engineer our environment before they can consume it.
The network already knows quite a bit
Application connectivity is another example.
Imagine an application team knows that orders.internal.example needs to communicate with payments.internal.example. Depending on the environment, those two names may be enough to discover quite a bit.
DNS can identify addresses. IPAM or inventory can add ownership and location. Firewall policy may show the current security zones. Cloud APIs or network controllers may expose routing context. Existing telemetry may help identify the path.
Correlating all of that reliably may be considerably harder than asking someone to paste source and destination IP addresses into a ticket. But the difficulty does not make the customer the right integration point. If the network already has tools that can answer those questions, asking an application engineer to find and return them mostly transfers our discovery work to someone with less network context.
Good self-service probably does the opposite. It accepts the artifact the customer naturally understands and enriches it with the context the infrastructure already owns.
Intent does not mean guessing
There is an obvious limit to inference.
A load balancer can illustrate it.
The network or platform team can probably determine where a load balancer belongs, allocate an address, apply standard policy, create the required objects, and choose an implementation pattern. What we cannot necessarily determine is what “healthy” means for an application we do not understand.
A TCP connection to port 443 might prove that something is listening. It may say very little about whether the application is actually able to serve a customer.
The application owner may need to tell us the URL or URI to check, the response that represents health, or some other application-specific behavior. That is not implementation detail we should hide. It is information the application team is authoritative about.
DNS has a similar boundary. The platform can own zones, records, delegation, TTL defaults, and organizational standards. The application or product team may still be the right group to decide what name will be useful and memorable to its users.
This is the distinction I find more useful than trying to make every request as short as possible:
Each team should provide the information it is actually authoritative about.
Application teams should not have to become network engineers to request connectivity. Network engineers should not invent application semantics just because the infrastructure requires a value.
The trap works both ways.
Better abstractions move complexity behind them
None of this makes the automation simpler.
It probably makes the platform more complicated.
A form that asks for a VLAN and CIDR is easy to understand from the automation side. A system that determines those values may need organizational standards, source-of-truth data, available-capacity checks, address-allocation logic, location context, security classification, API integrations, and decisions about what happens when any of those inputs are missing.
That logic then has to be administered.
The platform and its dependencies have versions. APIs change. Integrations fail. Logic that worked for the first three use cases may not work for the fourth. Troubleshooting moves from an individual configuration toward the system that produced it.
This is why I do not particularly like the cliché that automation allows network engineers to stop doing routine work and finally do “more important work.”
Making a VLAN was never the hard part.
The hard part was understanding what the customer needed, deciding how the network should support it, and putting together all of the disparate pieces that make the result work. That engineering does not disappear. Some of it becomes encoded into the platform, and now the platform itself has to be operated.
The goal is not to eliminate complexity.
The goal is to put the complexity where the expertise is.
The abstraction also creates room to change
There is another benefit that is easy to miss if self-service is treated only as a better user experience.
A useful abstraction can become an architectural boundary.
If a customer requests “a network for these workloads” rather than a particular VLAN, fabric object, or vendor-specific construct, the network team retains some freedom to change how that service is delivered later.
A switching platform can change. A fabric can be introduced. Addressing standards can evolve. A backend implementation can be replaced without requiring every consumer to learn the new operating model at the same time.
The customer may not know which switching vendor provides the network today. In many cases there is no reason they should have to care tomorrow.
That flexibility depends on the abstraction being real. If the API contract exposes every backend implementation detail, those details eventually become dependencies. What looked like self-service becomes another interface the network team is afraid to change.
A paved path still needs an exit
There will be exceptions.
A customer may have a legitimate reason to request a specific prefix size, address, load-balancing behavior, or connectivity pattern. An inferred choice may be wrong. A new requirement may simply not fit the abstraction yet.
I don’t think the answer is to prohibit overrides. An exception could become a separate workflow, an optional field, or require engineering review. If the same exception appears repeatedly, it may be evidence that the paved path needs another capability.
What I would avoid is designing every possible exception into the default request on day one. At some point the abstraction accumulates enough knobs that the customer is back to administering the implementation.
A paved path is useful partly because it has opinions.
Hiding implementation raises the observability requirement
I have not seen many network teams mature this model far enough to know exactly where abstraction goes too far.
One boundary I do think matters is observability.
If automation chooses the network, address space, security constructs, routing, and other implementation details, engineers still need to understand what it created and why. The platform should be able to answer questions such as:
- What was provisioned?
- Which inputs and policies produced that result?
- Is the service healthy?
- What changed?
- Is capacity becoming constrained?
- Can the system reconcile an unhealthy or drifted state?
The customer may not need every implementation detail, but abstraction cannot become opacity for the team operating the service.
Validation still matters. Customer acceptance tests, regression tests, connectivity checks, application health signals, and other evidence can confirm that the requested outcome exists without making the customer specify every network object required to produce it.
Inference is not a substitute for validation.
It is a way to put responsibility for the inference in the right place.
Do not automate the form too quickly
There is a lot of useful work involved in automating an existing network process. Connecting APIs, building reusable modules, handling errors, testing changes, and creating a reliable deployment path are all worthwhile.
I just think a different question should come first.
Take the existing request and look at every field.
For each one, ask whether the consumer is actually the best source of that information. Could the value come from an organizational standard? Can it be discovered from DNS, IPAM, a controller, a firewall, inventory, or another source of truth? Can policy derive it? Is it an application semantic that really does need to come from the customer?
Then ask the harder question:
What is the smallest amount of information we could receive and still fill out all of these fields correctly?
Maybe the answer is a hostname.
Maybe it is a URL and a health check.
Maybe it is the number of workloads that need addresses.
Maybe the customer truly does need to provide several details because the platform cannot safely infer them yet.
That is fine.
The point is to make those fields earn their place before we automate them.
Otherwise we can build an impressive amount of automation and still leave the customer filling out a network engineer’s build sheet.