In the software development industry, we often say, “We deploy stuff.” But what exactly is that “stuff”? Behind each deployment lies a layered stack of elements, each playing a distinct role in getting an application running and keeping it operational over time. To understand deployments holistically, we must examine them from both the Day 1 perspective — when a workload is deployed fresh — and the Day 2 perspective, which covers its ongoing operation, maintenance, and evolution.

At the heart of every deployment is a workload. But a workload is not just the application code (sometimes there isn’t even application code). It includes everything required to make that code work in a real-world, production environment. That means infrastructure, configuration, data, secrets and context— all defined and maintained across tools, processes, and lifecycle stages.

Let’s break down the constituent parts of a workload and examine what’s involved in deploying each of them.

Infrastructure Code

Deploying an application isn’t just about pushing code. It’s about setting up the environment in which that code can reliably run. This requires configuring a blend of infrastructure and application-specific settings, which can be grouped into several categories.

1. Application Configuration

This refers to the knobs and switches that the application uses internally — flags, parameters, and settings that affect how the application behaves. These configurations are typically not dictated by infrastructure but are essential to the application’s core logic. They determine feature behavior, toggles, thresholds, and operational modes. These items sit squarely in the application developer’s creative writing lexicon. So if you are an app developer — go nuts.

2. Application/Infrastructure Integration Configuration

These are settings that connect the application to the platform it runs on. This is what I call “where the body meets the soul”. It’s where the application interfaces with its underlying infrastructure.

Think connection strings, service endpoints, or message bus topics. These are critical for enabling the application to interact with the broader environment — databases, APIs, identity providers, or other services.

3. Infrastructure Configuration

This is the code that defines the cloud platform resources themselves — virtual networks, compute instances, load balancers, etc. Tools like Azure ARM/Bicep, AWS CloudFormation, and Terraform are used to define and provision this configuration declaratively, enabling consistent, repeatable infrastructure deployments.

4. Host Configuration

This includes everything at the OS or container level that supports the application at runtime. This might be a VM image pre-baked with system-level dependencies or a container that encapsulates both the app and its execution environment.

The distinction between host and app code may blur — like in the case with Docker images, but it’s crucial to recognize that the base image or environment setup is part of what you deploy.

5. Identity Configuration

Every modern app interacts with other services — and identity is the gatekeeper. This includes defining the identity provider (e.g., Entra ID for Azure), the service identities the application impersonates, and how access is controlled.

Complex workloads often involve multiple personas or identities, each mapped to specific roles and use cases. Configuration here spans from tenant IDs to role assignments to fine-grained claim-based access control.

6. Secrets Configuration

Secrets — like API keys, passwords, and tokens — are central to secure operations. Where these are stored (e.g., Azure Key Vault or HashiCorp Vault), how they’re encrypted, how they’re accessed by the app, and how they are rotated or managed all fall under this domain. Secrets management is not just a security concern — it’s a deployment and operations concern, too.

Application Code

When we think of deployment, most people instinctively think of the application code. And rightly so. This is the logic — the business functionality — that users interact with. It’s typically compiled or packaged into an immutable artifact, like a zip archive or Docker image. That artifact is then deployed into a host environment that’s been configured to support it.

But without the surrounding configuration and infrastructure, the application code is inert. It’s only one piece of the deployment puzzle and it has contracts or interfaces with the other components of a deployment.

Data

Data plays a dual role in deployment, especially when viewed through the lens of both Day 1 and Day 2 operations.

Day 1: Seed Data and Stored Configuration

On Day 1, a fresh deployment often requires seed data to be inserted into its database. This seed data is essential for the application to function — default users, plans, product catalogs, or workflow definitions.

In many cases, it also includes configuration that is stored in the database itself. This database-stored configuration governs aspects of the app’s behavior that operators can control without changing the code or re-deploying the service.

The key distinction here is functional vs. operational. Seed data enables the application to fulfill its intended purpose — users can interact with it from the get-go. Database stored configuration, by contrast, empowers operators to fine-tune or control runtime behavior post-deployment.

Day 2 Ops: Transformation, Backup, and Continuity

On Day 2, the focus shifts to maintaining, evolving, and protecting the data. This includes schema migrations — common when implementing new features or iterating on existing functionality.

Backup and restore strategies, failover readiness, and data integrity checks are additional actions that need to be performed on an ongoing basis but are less about the functionality changes and more about operational changes — when the proverbial s**t hits the fan. Deployments at this stage may include migration scripts, archive jobs, or tooling to transform legacy data structures.

As a result, data becomes a living part of the system, changing shape over time while retaining its criticality to the application’s ongoing operation.

Conclusion

A workload is more than just a docker image or the application code — it is an ensemble of configurations, infrastructure definitions, identity and secret management, and data that enable Infrasfructure, Application and Security Lifecycle Management.

When we say we “deploy,” we’re not just moving artifacts; we’re standing up entire systems — sets of interconnected parts that together make up a functioning application or service. Day 1 is about getting everything up and running. Day 2 is about keeping it running, evolving it, and ensuring its reliability, security, and resilience.

So the next time someone says, “We deploy stuff,” it’s worth unpacking that simple phrase. Because what we deploy is a deeply layered, carefully orchestrated set of components, each vital to the successful operation of modern software.