The network is part of the application.
Many bugs that look like application bugs are network facts: a name that resolves differently inside a container, a proxy that rewrites a header, a cookie the browser refuses to store.
Why developers should care
When software runs on someone's own network, the developer inherits that network. OrderRestro depends on every till, tablet and kitchen screen reaching one server on a LAN. If I cannot reason about addressing, DNS and DHCP, I cannot support it.
What I work with
- TCP/IP, DNS and DHCP: stable addresses for servers, names that resolve the same inside and outside containers.
- Routing, switching and VLANs: separating management, services and untrusted devices.
- VPNs and tunnels: reaching services behind a home or office connection without opening ports.
- Firewalls and segmentation: deciding what may talk to what and denying the rest.
- Reverse proxies: one entry point, TLS in one place, a single origin for the browser.
- Container and virtual networking: compose networks, published and unpublished ports, virtual bridges on Proxmox.
- Storage networking: dedicated links for backups and replication between storage and compute.
Applied examples
KinetiRx and Rechvix never publish PostgreSQL to the host. The database is reachable only from other containers on the compose network, which removes a whole class of exposure. KinetiRx and Submify put nginx in front so API and interface share an origin and avoid cross-origin configuration in production.
OrderRestro taught me how much a protocol detail matters. Behind an HTTPS tunnel the session cookie must be Secure, but the same flag on a plain HTTP LAN deployment makes the browser silently discard the cookie.
Service exposure
Before exposing a service I decide who needs it, through which path, with what authentication, and what happens if that path is closed. For most small-business software the answer is that it should not be on the public internet at all.