Ephemeral Environments, Durable Cloud Architecture
The Problem
Most solutions are part code, part configuration. The code lives in a repository, under source control. The configuration - databases, queues, secret stores, role assignments, network rules - lives in the cloud, clicked into place over time. Ask which parts of the system live where, and the answer is often "we'll have to check."
That ambiguity is the cloud-scale version of "it works on my machine." A service runs in production because the environment was tweaked into the right shape months ago. If it had to be recreated tomorrow, no single artifact would describe what to build. The answer is scattered across a portal, a wiki, and someone's memory.
Two Halves, One Repository
SoftAtomic ships its solutions with the environment completely defined in source control. Every resource is declared in Bicep, Microsoft's first-class infrastructure-as-code language for Azure: every database, every queue, every secret, every diagnostic setting, every role assignment, every network rule. The Bicep templates live in the repository alongside the application code and are the only sanctioned way the environment changes. The portal serves as a viewer, not an editor.
The two halves of the system - code and configuration - become a single source-controlled artifact. There is no question about which parts live where, because all parts live in the same repository, on the same branches, under the same pull-request review.
Ephemeral Environments
When the environment is fully declared in source control, environments stop being scarce. A single workflow stands one up from scratch, in minutes, against any subscription. Tearing one down is the same gesture in reverse. An environment becomes an output of the deployment system rather than a permanent asset in the cloud.
This enables two practices.
The first is design validation. A team that recreates the whole stack from source - every time, end-to-end - discovers gaps in the declaration the moment they appear. If a resource was missed, the deployment fails. If a permission was added by hand in production, the recreated environment surfaces the omission. The infrastructure code is continuously validated against reality rather than left to rust between releases.
The second is environment fluidity. Development environments can be spun up for a long-lived feature branch, a security review, a customer-specific test, or a one-off experiment, with no operational ceremony. When the work concludes, the environment goes away. Cost stops accruing, yesterday's misconfiguration does not carry over into today, and a team that once rationed a single shared development environment can give each branch - or each engineer - its own.
Reviewed Change, Detected Drift
Bicep ships with a what-if command that compares the declared architecture against the live state and reports the differences without applying anything. Every production deployment runs as a two-step dispatch: a what-if for visual review, then an apply once the diff looks right. The deployment becomes a reviewed change rather than a leap of faith.
The same command runs on a nightly schedule against production, with results archived for audit. A manual portal change - a setting adjusted, a role added, a tag edited - surfaces in the next morning's report. Drift is detected continuously rather than at the next deployment.
Disaster Recovery from Source
A production environment whose architecture is fully declared is recoverable from that declaration. If the resource group disappeared - accidental delete, region-scale failure, compromise requiring a full rebuild - the path back is a deployment workflow plus a data restore. Hours, not weeks. The ephemeral-environment practice keeps the capability tested: every fresh build of a development environment is an end-to-end rehearsal of the recovery procedure.
Why This Matters
Much of today's cloud infrastructure is still clicked into existence. Resources accumulate in portals, configurations get tweaked by hand, role assignments are added during incident response and never documented. Six months in, the system runs - but no one can confidently explain how to recreate it. Tribal knowledge becomes the source of truth.
When the architecture is in source control and deployment is automated, the calculus changes. Every change is a diff. Every review catches drift. The team's mental model of the system matches what is actually deployed, because the deployment is generated from the model. Six months in, anyone can answer how to recreate the system: read the templates, dispatch the workflow.
Applications
Onboarding new engineering staff: a personal environment is a workflow dispatch, not a setup guide
Per-branch or per-feature development environments: each long-lived branch can have its own end-to-end stack
Multi-region or multi-tenant deployments: the same templates render the same architecture against any subscription
Disaster recovery and incident response: the path back is the path forward; rebuilding production is a known procedure
Security and compliance audits: auditors read the source rather than interpret a portal walkthrough
Due diligence and acquisition review: "how would you recreate this system" has a clear answer in the repository
Technical Architecture
Infrastructure as code: Bicep, Azure Resource Manager, declarative role assignments, custom RBAC roles, resource locks
Environment parametrization: shared Bicep codebase, separate parameter files per environment
Deployment & review: GitHub Actions, OIDC federation to Microsoft Entra ID, Bicep what-if previews, two-stage prod deploys (review → apply)
Ephemeral environments: dispatch-only workflows, fresh resource group per cycle
Drift detection & audit: scheduled az deployment sub what-if against production, results archived to a dedicated audit storage account
Closing Thought
If you're building a cloud platform on Azure, or want to bring an existing one under source control, SoftAtomic does this. We design new systems with the environment fully declared from day one, and we retrofit existing systems toward the same discipline. Contact us.
