Descriptions of example purposes of workload environments

This section provides descriptions of each of the example purposes of workload environments shown in the Example worksheet. These examples and descriptions are meant to act as a reference and starting point for you to modify and extend to suit your needs.

Self-paced learning and experimentation workload environments

Builders learning and experimenting on their own, ideally with access to a wide variety of technologies.

Development workload environments

Work done by builder teams up and down the stack to develop and support their workloads and services. Examples of code includes proprietary application code, test scripts, test data, data models, machine learning models, security roles and policies, and Infrastructure as Code (IaC). Generally, it’s most efficient for builders to carry out development tasks locally on their corporate desktops.

Static analysis, build, and unit testing workload environments

Teams naturally develop, test, and carry out static analysis, builds of draft artifacts, and unit tests in their corporate desktop and/or cloud development environments. More formally controlled executions of these processes including builds of formal candidate artifacts typically occur through either continuous integration (CI) jobs or in early CI stages of continuous delivery (CD) pipelines.

CI jobs and CD pipelines workload environments

CI jobs and CD pipelines are developed and tested by teams in their development environments before they are potentially formally validated in a test environment. Given the common requirements to formally control creation of candidate artifacts and orchestration of validation stages, formal execution of CI jobs and CD pipelines typically occurs in production environments.

Smoke testing workload environments

Smoke testing is often used to quickly determine the overall success or failure of either deploying or releasing a change to any workload environment. A smoke test is an initial indication of the success or failure of a deployment or release. Unlike many other types of system level testing, smoke testing is also typically used against production workloads to initially validate that release of a change was generally successful.

Development integration testing workload environments

Development integration testing is the early integration testing of code and configurations that typically occur prior to formal types of system testing. This is done so that basic integration issues are detected early in the lifecycle.

Production-like system testing workload environments

System level testing is the end-to-end testing of services and applications that occur in production-like environments prior to changes being promoted for use in production. In the spirit of shifting left so that issues are found earlier in the lifecycle, builder teams can take advantage of automation and the on-demand and elastic nature of the cloud to perform early system level testing in their development environments.

Common examples of system level testing include, but are not limited to:

• Functional acceptance testing – Verification that the service meets the business requirements. In mature situations, this testing is often largely automated.

• User acceptance testing – Validation from a user’s perspective or through a proxy, such as a product owner, that the service meets their expectations.

• Exploratory testing – Functionality testing by humans in an ad hoc manner.

• Performance testing – Systems level testing to ensure a service is able to meet the expected performance goals with the supporting capacity.

• Workload-recovery testing – Testing the ability of your workloads to recover from component-level and workload-level failures in the face of sustained failures.

• Penetration testing – Also known as pen testing, testing services to identify security vulnerabilities.

• Multi-region testing – Testing that a workload is deployed in an active-active mode across multiple AWS Regions.

• Disaster recovery / business continuity testing – Business testing to ensure that services can be restored when in the event of a large-scale disaster.

Stable shared test workload environments

Teams who own shared services are sometimes responsible for managing stable test instances of their workloads that are loaded with test data in support of development and integration testing.

Resiliency testing workload environments

Also known as chaos engineering, this scenario is where failures are purposely introduced into the environment to ensure that the workloads respond in the expected manner. More advanced scenarios include running such tests against production workloads.

Demo workload environments

Internal teams demonstrating services and capabilities to internal and/or external customers throughout the lifecycle.

External pre-release workload environments

Sometimes referred to as alpha, beta, or early access, these workloads are typically accessed by external customers. Given the external access nature of these workloads, it’s common for these workloads to be contained in either production or test environments.

Production workload environments

Formally managed and monitored workloads that are deployed to distinct production environments.