Cloud environments your team can reproduce.

An application environment combines its servers with network routes, configuration, secrets, storage and scheduled jobs. We set those components up around the way the software is built and operated.

Build the environment from a maintained definition

We set up infrastructure definitions and deployment configuration for development, test and production. That can include application hosting, network boundaries, storage, managed data services and scheduled workloads. The implementation follows the application and the cloud services the assignment calls for.

A test database may be smaller than production, but its schema and required extensions still need to support the release being tested. Credentials stay outside the source repository. Configuration names and environment-specific values need an agreed place in the deployment setup.

Map the request and the background work

A runtime change can affect more than the process answering a request. A worker may continue running a queued job while web instances restart. A scheduled task may use a separate connection pool or configuration file.

We examine those paths alongside the application team. The infrastructure definition needs to identify the components that start independently, the dependencies they connect to and the settings used in each environment.

Where a platform change stops

Request entry Application runtime Background worker Database dependency

Request entry

A client reaches the HTTPS entry point.

Platform work: TLS termination, ingress routing, request limits and network access.
Application behavior: The routes, authentication behavior and response the application provides.
Relevant evidence: A request through the intended entry route, with the entry and application responses distinguished.

Application runtime

The web process handles the request and uses its dependencies.

Platform work: Runtime version, environment configuration, resource limits and deployment settings.
Application behavior: Request handlers, dependency calls, query behavior and the decision to queue background work.
Relevant evidence: Startup and representative request behavior using the runtime’s intended identity.

Background worker

Queued work can continue after the web response ends.

Platform work: Worker count, concurrency, shutdown behavior and connectivity to the queue and database.
Application behavior: Job semantics, safe repetition and the treatment of partially completed work.
Relevant evidence: Job duration, queue age and the agreed interruption test.

Database dependency

Web and worker processes may share the same connection limit.

Platform work: Service configuration, runtime access, connection limits and the agreed backup setup.
Application behavior: Queries, transactions, schema changes and compatibility with the running application versions.
Relevant evidence: Application access and compatible reads/writes against the intended database state.

An illustrative application arrangement, not a client system or live service map. Select a component to read the platform work, application behavior and evidence relevant to it. Actual scope is agreed for the assignment.

Choose capacity for a stated workload

We examine memory use and worker concurrency alongside the limits of the dependencies involved. A request can wait for a database connection even when the application has spare CPU.

A capacity change may involve instance count, resource limits or scaling settings. We compare the proposed change against a stated workload and watch the relevant service measurements after it is applied.

Connection pools set a shared ceiling

Each application instance may maintain its own pool of database connections. Doubling the instance count can double the potential connections even when no individual pool setting changes. Background workers may draw on the same database limit.

Before changing capacity, account for those pools together. The useful test is the application workload through the shared dependency, including the waiting time for a connection. A host CPU chart alone cannot establish whether the change has created room for more requests.

Keep maintenance part of the platform

Runtime upgrades, expiring certificates and changes to a managed service can affect an otherwise unchanged application. We can carry out agreed maintenance and adjust the infrastructure definition with it.

Environment and deployment configuration in the agreed repository.
A documented recovery or rebuild procedure for the components included in the assignment.
A maintenance list that names the components and versions being supported.

Separate the build from its environment

Keep the application artifact identifiable as it moves through test and production. Environment-specific configuration and secret references can change without rebuilding that artifact, provided the application supports that arrangement.

A comparison of the intended definition with the deployed resources can expose manual changes that never reached the repository. We investigate the reason for a difference before replacing a working configuration or accepting the difference as the new baseline.

Read the environment-definition reference

Limit the change to the affected component

A platform assignment can be limited to a troublesome environment or a specific dependency. We identify the affected components and the application behavior that must continue during the change.

How releases cross environment changes

Check an environment with its own identity

A service that works under an engineer’s administrator account can fail under the identity used by the runtime. Validate access to secrets, data services and external destinations using the permissions the deployed application will have.

The access record should identify the service and the resources it needs. Keep protected values out of that record. Remove temporary investigation access when the agreed work is complete.

Inspect the environment specimen