Server Environments

11 min readFeb 6
Adapted from photo by wocintechCC BY 2.0

When maintaining large software systems, you will likely have multiple environments with names like Prod, Staging, Dev, Eval, UAT, Daily, Nightly, or some remix of these names. To distinguish this type of environment from the dozen other things in software development that we give that same name, these are often formally referred to as Deployment Environments.

One question I’ve never been asked directly is: “What is an Environment?” This is surprising; because not understanding what Deployment Environments actually are is one of the most common pitfalls I see in my day-to-day work.

What is a Deployment Environment

A Deployment Environment is a consistently connected set of

  1. processes
  2. datastores, and
  3. any ecosystem around them (e.g., cron jobs, analytics, etc.)

making up a fully functioning software system.

This definition is quite intuitive, but the devil is in the details. In this case, that detail is the phrase “consistently connected”.

A Note

  1. In most architectures, processes are also known as services. In this context, any server-side program interacting with the rest of your system (e.g., an API endpoint, a Service that makes or receives RPCs, a long-running process that writes to and reads from a database, etc.) is a process that makes up an environment.
  2. Datastores are often databases, but can also include any storage or service that persists data long-term (e.g., writing data to disk or an S3 Bucket).
  3. The ecosystem around these can include a lot of other infrastructure, like pubsub channels, offline cron jobs that process data, and others.

What consistently connected entails

Ideally, environments should be perfectly isolated; no data or RPC should leak between processes and data stores across environments during normal operation.

A Case Study

An Architecture Diagram representing a simple To-do system. An HTTP endpoint calls TodoApi and PeopleApi. Todo API is connected to a database called TodoStore, while PeopleApi is connected to some People graph service called PeopleStore. There’s also a ReminderService that reads TodoStore and sends push notifications to the HTTP endpoint. The user communicates only with the HTTP endpoint via a browser.
An architecture representing a To-do system with some interdependencies.

Software Engineer living in Brooklyn, NY. MIT Computer Science S.B. ’13, M.Eng. ‘14. From Amman, Jordan. Interested in politics, current affairs, and technology