The Remote Work Stress Test — Is Our Infrastructure Ready?

This week, the conversation in tech shifted rapidly from “should we cancel the conference?” to “can our entire company work from home?” Twitter announced an optional work-from-home policy. Amazon told Seattle employees to work remotely if possible. Google is doing the same in Dublin. Microsoft, Square, and others are following suit. Mobile World Congress was cancelled weeks ago. Google I/O and Facebook F8 are looking increasingly uncertain.

What interests me as an engineer isn’t the virus itself — I’ll leave that to the epidemiologists — but the sudden, large-scale stress test being applied to remote work infrastructure. We’re about to find out which companies actually invested in distributed-work capabilities and which ones just talked about it.

The VPN Bottleneck

#

Here’s a dirty secret about enterprise remote work: most companies’ VPN infrastructure was never designed for 100% of employees connecting simultaneously. VPN concentrators are typically sized for 10-30% concurrent usage, because historically, remote work was the exception. If a company with 10,000 employees suddenly needs all of them on VPN, the existing hardware simply won’t handle it.

I’ve been talking to infrastructure leads at several companies this week, and the scramble is real. VPN licenses are being purchased urgently. Split-tunnel configurations are being rolled out to reduce load — routing only corporate traffic through the VPN while letting YouTube and Spotify go direct. Some companies are discovering that their VPN infrastructure hasn’t been load-tested at these levels… ever.

The smarter organizations moved to a zero-trust networking model over the past few years. Tools like Google’s BeyondCorp approach, or products like Cloudflare Access and Zscaler Private Access, authenticate users and devices without requiring a traditional VPN tunnel. If your applications are already accessible through an identity-aware proxy, scaling to 100% remote is primarily about bandwidth, not VPN capacity.

Collaboration Tools Under Pressure

#

Slack, Microsoft Teams, Zoom, and Google Meet are about to experience usage spikes they’ve never seen. Zoom in particular has been riding a wave of adoption, and their infrastructure will be tested at scale. Video conferencing is bandwidth-intensive and latency-sensitive — the kind of workload that’s hard to scale gracefully.

For engineering teams specifically, the collaboration challenge goes beyond video calls. Code review, pair programming, incident response, and design discussions all have established in-office patterns that need remote equivalents:

• Code review translates well — GitHub and GitLab pull requests work the same regardless of where you sit
• Pair programming is harder — tools like VS Code Live Share and Tuple help, but they’re not yet standard
• Incident response needs a virtual war room — Slack channels plus a persistent video call, with clear communication protocols
• Whiteboarding is the biggest gap — Miro and Figma help, but the spontaneity of walking up to a whiteboard is hard to replicate

Companies that already have distributed teams have solved most of these problems. GitLab, with its all-remote model and public handbook, is often cited as the gold standard. Basecamp and Automattic (the WordPress company) have been remote-first for years. The rest of the industry is about to get a crash course in what these companies learned the hard way.

The Development Environment Question

#

Here’s one that catches companies off guard: can your developers actually build and test the product from home? This sounds obvious, but many organizations have development dependencies that only work on the corporate network:

• Internal package registries and artifact repositories
• Shared development databases and staging environments
• License servers for commercial tools
• CI/CD pipelines that run on-premises
• Hardware test labs and device farms

If your development workflow requires access to resources that are only reachable from the office network, you need a plan. The VPN approach works but adds latency and bandwidth constraints. A better long-term solution is making development infrastructure accessible securely from anywhere — containerized development environments, cloud-hosted CI/CD, and remote development servers.

I’ve been running my development environment in Docker containers for the past year, with all dependencies defined in docker-compose.yml. When I work from home, my setup is identical to the office — same container images, same configurations, same behavior. The initial investment in containerizing the dev environment pays dividends in exactly this scenario:

# docker-compose.yml — portable dev environment
version: '3.8'
services:
  app:
    build: .
    volumes:
      - .:/workspace
    ports:
      - "3000:3000"
  postgres:
    image: postgres:12
    environment:
      POSTGRES_DB: myapp_dev
  redis:
    image: redis:6-alpine

What Companies Should Be Doing Right Now

#

If you’re in a position to influence your company’s technical infrastructure, here’s what I’d prioritize this week:

1. Load-test your VPN at 3x current peak usage. If it breaks, you need split-tunneling at minimum, and zero-trust networking as a strategic investment.
2. Document everything that requires on-premises access. Create a spreadsheet of every service, tool, and resource that only works from the office. Each one is a single point of failure for remote work.
3. Test your video conferencing at scale. Have a large all-hands meeting over video and see what breaks. Bandwidth, audio quality, screen sharing — find the problems before they’re critical.
4. Ensure your CI/CD pipeline works for remote developers. If builds are triggered by pushing to a repository (as they should be), this is probably fine. If there are manual steps that require office access, fix them now.
5. Write down your incident response process for a fully remote team. Who gets paged? What’s the communication channel? How do you coordinate when you can’t walk over to someone’s desk?

My Take

#

I’ve worked remotely on and off for years, and I’ve long believed that most knowledge work can be done effectively from anywhere with a decent internet connection. What’s different about this moment is the speed and scale of the transition. Companies that planned for gradual adoption of remote work are being forced into it over the course of days.

The good news is that the tooling has never been better. Cloud infrastructure, container orchestration, modern collaboration tools, and fast home internet connections make remote work technically feasible for most software teams. The challenge is organizational, not technical — communication patterns, meeting culture, trust, and management practices all need to adapt.

I suspect — and hope — that this forced experiment will permanently shift how the tech industry thinks about remote work. Even after the immediate health concerns pass, companies that discover their teams can be productive from home may not go back to mandatory office attendance. That would be a genuine silver lining.

But right now, the priority is making sure the infrastructure holds. Check your VPN. Test your tools. Document your dependencies. The stress test is coming.

This post is part of my Infrastructure Notes series. I have a feeling this topic is going to be a recurring one in the weeks ahead.