Emerging Trends and Future Developments

Introduction and Context

Container technology has moved from a method for packaging applications to a foundation for cloud-native software delivery. Docker popularised developer-friendly containers, while the Open Container Initiative (OCI), Kubernetes, managed cloud platforms and automated software pipelines have broadened the ecosystem. The next stage is not defined by one replacement for Docker. Instead, it involves the convergence of artificial intelligence, supply-chain security, confidential computing, serverless execution, WebAssembly, edge infrastructure and sustainability.

These developments change the responsibilities of DevOps professionals. A practitioner must now evaluate not only whether an image runs, but also whether it was built reproducibly, signed, governed, efficiently scheduled and safely operated across heterogeneous infrastructure. Emerging technologies also introduce trade-offs. AI can reduce operational effort but may produce unsafe recommendations. WebAssembly can improve startup time but does not replace every container workload. Confidential containers can protect data in use but require suitable hardware and attestation mechanisms.

This chapter evaluates these developments and provides a framework for making informed adoption decisions.

Learning Objectives

By the end of this chapter, a learner should be able to:

1. Explain how AI-assisted operations are applied to container platforms.
2. Describe software-supply-chain automation, provenance and policy enforcement.
3. Compare conventional, confidential and serverless containers.
4. Explain the relationship between containers and WebAssembly.
5. Evaluate deployment patterns for edge computing.
6. Identify methods for reducing the environmental impact of containerised systems.
7. Explain the continuing role of OCI standards and modern container security.
8. Assess risks, governance requirements and adoption criteria for emerging technologies.

1. AI-Assisted Operations

AI-assisted operations, often called AIOps, applies machine learning, statistical analysis and natural-language interfaces to operational data. In a container platform, relevant data includes logs, metrics, traces, deployment events, Kubernetes objects, image metadata and security findings.

A useful distinction is between assistive automation and autonomous control. Assistive systems summarise incidents, identify correlations or suggest a remedy. Autonomous systems directly change replicas, configuration or traffic routing. Assistive automation is generally easier to govern because a human can review the proposed action. Autonomous control may respond more quickly, but an incorrect action can amplify an outage.

Operational uses

Common applications include:

• Anomaly detection: identifying behaviour that differs from a learned baseline, such as unusual restart rates or latency.
• Event correlation: grouping symptoms from several services into a probable incident rather than treating each alert separately.
• Capacity forecasting: estimating future CPU, memory or storage demand.
• Root-cause assistance: ranking likely causes using dependency graphs and historical incidents.
• Natural-language operations: translating a question such as “Which deployments changed before the error increase?” into queries against approved observability systems.
• Remediation recommendation: suggesting a rollback, resource adjustment or configuration change.

AI does not remove the need for observability engineering. Poor labels, incomplete traces and noisy alerts produce poor recommendations. Models may also learn historical mistakes, confuse correlation with causation or behave unreliably when the platform changes.

A responsible control model

A practical operating model contains five controls:

1. Data governance: restrict access to logs, credentials, customer information and personal data. Redact secrets before data reaches an AI service.
2. Evidence grounding: require recommendations to cite current metrics, events, configuration and approved documentation.
3. Least privilege: give an AI agent read-only access by default. Any write action should use narrowly scoped identities.
4. Human approval: require review for destructive actions, production deployments, access-policy changes and database operations.
5. Auditability: record the prompt or event, evidence used, recommendation, human decision and resulting change.

An AI-generated command should be treated like code supplied by an unfamiliar contributor: inspect it, test it and apply it through controlled change mechanisms.

2. Software-Supply-Chain Automation

A container image is the output of a chain involving source code, dependencies, build tools, base images, compilers, registries and deployment systems. A vulnerability or unauthorised modification in any link can affect production. Supply-chain automation aims to make this chain more observable, reproducible and enforceable.

Core concepts

• Software Bill of Materials (SBOM): an inventory of components and their versions in an image or application.
• Provenance: evidence describing how, where and from which inputs an artifact was produced.
• Attestation: a signed statement about an artifact, such as its build process, test result or scan status.
• Content digest: a cryptographic identifier derived from artifact content. A digest changes when the referenced content changes.
• Image signing: a mechanism for verifying that an artifact was approved or produced by a trusted identity.
• Policy as code: machine-readable rules that block or permit actions consistently.

A secure automated path commonly follows this sequence:

Source commit → Dependency resolution → Reproducible build → Tests and scans
      ↓                 ↓                    ↓                    ↓
   Review          Lock versions          SBOM/provenance       Policy gate
                                      → Sign artifact → Registry → Admission check → Runtime

The exact tools may vary. OCI image manifests and registries provide interoperable packaging, while projects such as in-toto, Sigstore and SLSA contribute approaches for attestations, signing and supply-chain levels. These frameworks should be applied according to organisational risk rather than treated as a guarantee of absolute security.

Policy gates

A policy may require that:

• the image is signed by an approved build identity;
• the image references an approved registry;
• critical vulnerabilities have an accepted exception or have been fixed;
• provenance identifies a trusted workflow;
• the container does not run as root unless justified;
• the deployment uses a digest rather than an uncontrolled mutable tag;
• the image includes an SBOM;
• only permitted capabilities, host mounts and network privileges are used.

Security scanning is not a binary proof of safety. Vulnerability databases may be incomplete, a vulnerable library may not be reachable, and a clean scan may not detect malicious logic. Therefore, automated scanning should be combined with code review, dependency maintenance, runtime controls and incident response.

Reproducibility and risk

Reproducible builds attempt to ensure that the same declared inputs produce equivalent outputs. Pinning a base image by digest, locking dependencies and recording build metadata improve reproducibility. However, a digest pin can preserve an old vulnerability if it is never refreshed. Secure practice therefore combines immutability at deployment time with a managed update process.

3. Confidential Containers and Confidential Computing

Traditional container isolation protects processes mainly through the operating system kernel, namespaces, control groups and mandatory security controls. The host kernel can normally inspect container memory. Confidential computing seeks to protect data while it is being processed by using hardware-supported trusted execution environments (TEEs).

A confidential container commonly runs inside a protected virtual machine or enclave. The platform may provide:

• encrypted memory;
• measured boot;
• remote attestation;
• restricted host access;
• cryptographic release of secrets only to an attested workload.

Remote attestation allows a verifier to check measurements of the software and platform before releasing a key or permitting access. The trust model is important: confidential computing does not automatically make an application trustworthy. A vulnerable application inside an encrypted enclave remains vulnerable, and side-channel, availability and key-management risks remain.

Appropriate uses

Confidential containers may be valuable for:

• processing regulated health or financial data;
• multi-party analytics where infrastructure operators should not see plaintext;
• protecting proprietary models or algorithms;
• workloads deployed in environments that are not fully trusted;
• confidential inference or data collaboration.

Limitations

TEEs can introduce performance overhead, restricted hardware features, operational complexity and difficult debugging. Attestation evidence must be verified correctly, and images, firmware, guest kernels and policies must be updated. A confidential workload also needs conventional application security, identity management and network protection.

4. Serverless Containers

Serverless containers provide a container execution model without requiring the user to administer the underlying servers or cluster control plane. The provider typically handles scheduling, capacity and much of the platform maintenance. The user supplies an image, resource settings and an invocation or service configuration.

This model is useful for APIs, event processors, scheduled jobs and variable workloads. It can reduce operational effort and permit scale-to-zero behaviour. The principal trade-offs include cold-start latency, execution limits, provider-specific interfaces, networking constraints and potentially higher cost for sustained workloads.

A simple cost model can support an initial comparison. If a service consumes r units of allocated resource for t hours at a price of p currency units per resource-hour, the usage charge is:

Here, C is the usage cost, r is the allocated resource quantity, t is the billed duration and p is the unit price. This model assumes linear pricing and excludes requests, networking, storage, taxes and free tiers. It is therefore a planning approximation, not a universal billing equation.

For example, 2 resource units used for 100 hours at 0.04 currency units per unit-hour gives C = 2 × 100 × 0.04 = 8 currency units before additional charges.

Serverless containers should not be selected merely because they are fashionable. A long-running, predictable service may be more economical and operationally stable on a managed cluster or virtual machine. The decision should consider latency, workload duration, utilisation, compliance and portability.

5. WebAssembly and Its Relationship with Containers

WebAssembly (Wasm) is a portable binary instruction format designed for safe, efficient execution. It was initially associated with browsers but is increasingly used for server-side workloads through runtimes such as Wasmtime, WasmEdge and Spin. WebAssembly modules are sandboxed and commonly have fast startup and small footprints.

Containers and Wasm solve related but different problems. A container packages a user-space filesystem and process with isolation provided largely by the host operating system. A Wasm module targets a virtual instruction environment and uses explicit capabilities for access to resources. A Wasm workload can also be distributed through OCI registries, allowing familiar artifact-management workflows.

Wasm is especially promising for stateless functions, plugins, policy filters and edge services. It is less suitable when an application depends on a full Linux environment, privileged device access, native libraries or complex process management. The realistic future is coexistence: containers remain important, while Wasm becomes another deployment target.

6. Edge Deployment

Edge computing places computation near users, sensors or operational systems rather than exclusively in central cloud regions. Edge locations may have limited bandwidth, intermittent connectivity, constrained hardware and difficult physical access.

Containerised edge systems support repeatable deployment, but centralised assumptions must be reconsidered. A robust design often includes:

• local operation during temporary disconnection;
• compact images and efficient update mechanisms;
• device identity and certificate rotation;
• remote monitoring and rollback;
• resource-aware scheduling;
• protection against physical tampering;
• data minimisation and local preprocessing.

A deployment may use a central control plane with lightweight agents at sites, or a hierarchical model in which regional nodes coordinate local devices. Updates should be staged using canary deployment or percentage-based rollout. When connectivity is intermittent, the system should retain a known-good version and define what happens when desired state cannot be reached.

Edge architectures raise data-governance questions. Local processing can reduce data transfer and improve privacy, but it may also make auditing and incident investigation harder. Organisations must identify where data is collected, processed, stored and deleted, especially when sites cross legal jurisdictions.

7. Sustainable Container Computing

Sustainable computing considers energy consumption, carbon emissions, hardware use and equipment lifecycle. Containers do not automatically make computing sustainable. They can improve utilisation through density, but large images, excessive replicas, idle clusters and frequent rebuilds can increase resource consumption.

A simplified energy relationship is:

where E is energy in watt-hours when P is average power in watts and t is time in hours. This assumes power is represented by a stable average. If power varies over time, the more general relationship is:

where P(t) is instantaneous power and the integral is taken over the operating period. Carbon impact can be approximated by:

where G is emissions, commonly expressed in grams of CO₂ equivalent, E is energy in kilowatt-hours and I is the location- and time-dependent emissions intensity in grams of CO₂ equivalent per kilowatt-hour. This estimate excludes or separately accounts for embodied emissions in hardware.

Practical measures include:

• right-sizing CPU and memory requests;
• scaling replicas according to demand;
• removing unused images and stopped workloads;
• using multi-stage builds and smaller base images;
• scheduling flexible batch jobs when lower-carbon electricity is available;
• selecting efficient hardware and regions;
• measuring energy and carbon rather than assuming improvement;
• extending hardware life where security and reliability permit.

Optimisation must not compromise availability, security or service quality. A smaller image is beneficial, but not if it omits essential security updates or makes incident response impossible.

8. Evolving OCI Practices and Security

The OCI standardisation effort has helped separate container tooling from any single vendor. OCI specifications address image formats, image distribution and runtime behaviour. This enables images to move among compliant tools and registries, although practical compatibility still depends on operating systems, architectures, extensions and platform features.

Important continuing practices include:

• use immutable digests for production promotion;
• build multi-architecture images when required, while testing each architecture;
• maintain a trusted and regularly updated base-image catalogue;
• sign images and verify signatures at admission;
• attach SBOM and provenance attestations;
• run as a non-root user where possible;
• drop unnecessary Linux capabilities;
• use read-only filesystems and seccomp or equivalent restrictions;
• restrict host namespaces, privileged mode and sensitive mounts;
• apply network policies and workload identity;
• isolate tenants and protect the container runtime;
• monitor runtime behaviour and retain forensic evidence.

Container security is a lifecycle discipline. Image scanning at build time cannot replace runtime detection, and runtime controls cannot repair a compromised build pipeline. Security should be layered across source, build, registry, admission, runtime and retirement.

9. An Adoption Framework

An organisation can evaluate an emerging capability using six questions:

1. Problem: What measurable operational or business problem does it solve?
2. Fit: Does the workload have the technical characteristics required?
3. Risk: What new failure, security, privacy or compliance risks are introduced?
4. Evidence: Can the organisation test the claimed benefit using representative workloads?
5. Operations: Can staff monitor, update, troubleshoot and recover the technology?
6. Exit: Can workloads and data be migrated if the provider, runtime or project changes?

A pilot should define success measures before deployment. Examples include deployment time, startup latency, failure recovery time, cost per transaction, vulnerability remediation time, energy per request and percentage of artifacts with verified provenance. Baselines are essential; otherwise an organisation may confuse activity with improvement.

10. Illustrative Case: A Retail Edge Platform

Background

A fictional retail company, Northstar Market, operates 600 stores. Each store uses cameras and point-of-sale systems to detect queue congestion and equipment faults. Sending all video and telemetry to a central cloud creates bandwidth costs and delays.

Problem

The company needs local decisions within seconds, secure software updates and continued operation during network outages. It also handles customer-related data and must limit unnecessary retention.

Analysis

The workload contains two categories. A computer-vision inference service requires native libraries and GPU support, making a conventional container appropriate. Small event filters and policy checks are portable and stateless, making WebAssembly a possible fit. Store hardware is physically accessible to attackers, so device identity, encrypted storage and remote attestation are considered. Central operators need evidence that only approved software is running.

Approach

Northstar adopts a layered design:

• inference runs in signed, digest-pinned containers;
• lightweight filters run as Wasm modules where performance tests support the choice;
• a local edge agent queues events during disconnection;
• updates are staged to 5% of stores before wider rollout;
• admission policy requires signatures, SBOMs and approved provenance;
• sensitive video is processed locally and deleted according to a retention policy;
• operational AI groups alerts and recommends remediation, but production changes require approval;
• power and device utilisation are measured to identify over-provisioning.

Outcome

In this illustrative scenario, local processing reduces bandwidth and improves response time, while staged rollout reduces the blast radius of a defective update. The organisation does not replace every container with Wasm or every human decision with AI. It selects technologies according to workload characteristics and retains conventional controls.

Learning points

The case demonstrates that emerging technologies are architectural choices, not isolated products. Security evidence, updateability, observability and failure recovery are as important as raw performance. Edge deployment also shows why technology selection must include physical, legal and environmental context.

11. Challenges, Ethics and Governance

Emerging infrastructure can concentrate power in cloud providers, model vendors, registries or hardware manufacturers. Lock-in may arise through proprietary APIs, identity systems, monitoring formats or confidential-computing dependencies. Teams should document portability assumptions and maintain export and recovery procedures.

AI-assisted operations raise accountability questions. If an automated recommendation causes an outage, responsibility remains with the organisation that authorised and governed the system. Training data may contain personal information or operational secrets. Models should not be granted broad production access simply because they can generate commands.

Supply-chain controls can create surveillance and administrative burdens. Provenance should support assurance without collecting unnecessary personal data. Vulnerability exceptions must have owners, expiry dates and compensating controls. Security policies should be proportionate: blocking every image with any low-severity finding may encourage unsafe workarounds.

Accessibility and workforce development also matter. New tools should provide understandable explanations, documentation and training. A platform that only a small group can operate creates resilience risk.

Best-Practice Checklist

• Begin with a documented problem and baseline.
• Prefer open formats and standards where practical.
• Automate SBOM generation, provenance and signature verification.
• Pin production artifacts by digest and refresh them through controlled updates.
• Use least privilege for humans, workloads and AI agents.
• Test confidential, serverless, Wasm and edge technologies with realistic workloads.
• Design for disconnected operation and recovery where edge sites are involved.
• Measure cost, performance, reliability, security and energy together.
• Keep humans accountable for high-impact operational decisions.
• Review legal, privacy, environmental and portability implications.

Chapter Summary

The future of containerisation is an ecosystem rather than a single successor to Docker. AI-assisted operations can improve detection, analysis and remediation, but require grounded evidence, least privilege, human oversight and audit trails. Software-supply-chain automation strengthens trust through reproducible builds, SBOMs, provenance, signatures and policy gates, although no scanner proves that software is safe.

Confidential containers protect data in use under hardware-supported trust models, while serverless containers reduce infrastructure administration for suitable event-driven workloads. WebAssembly offers a portable, lightweight sandbox for selected functions and edge services, but containers remain essential for broad Linux compatibility. Edge deployment requires resilience, compact updates, device security and local data governance. Sustainable container computing depends on measurement, right-sizing, efficient images, appropriate scheduling and responsible hardware use.

OCI standards, image signing, digest pinning, runtime restrictions and layered controls remain central as platforms evolve. The professional DevOps response is evidence-based adoption: define the problem, test the technology, measure outcomes, govern risk and preserve recoverability.

Key Terms

AIOps: Use of analytics and AI techniques to assist IT operations.

Attestation: A signed statement providing evidence about an artifact, build or execution environment.

Confidential computing: Protection of data while it is being processed using hardware-supported trusted execution environments.

Content digest: A cryptographic identifier derived from artifact content.

Edge computing: Processing data near its source or users rather than only in a central cloud.

Immutable artifact: An artifact addressed by a fixed content identity that is not silently changed.

OCI: Open Container Initiative specifications for container images, distribution and runtimes.

Provenance: Evidence describing how and from which inputs software was produced.

Remote attestation: Verification of a remote platform’s measured state before granting trust or secrets.

SBOM: Software Bill of Materials; an inventory of components in software.

Serverless container: A container executed through a managed service without user-managed servers or cluster infrastructure.

Software supply chain: The people, processes, tools and components involved in producing and delivering software.

TEEs: Trusted Execution Environments that isolate protected computation from unauthorised inspection.

Wasm: WebAssembly, a portable binary instruction format with sandboxed execution.

Image signing: Cryptographic proof that an artifact was associated with a trusted signing identity.

Policy as code: Machine-readable rules used to enforce governance decisions automatically.

Reproducible build: A build designed to produce equivalent output from the same declared inputs.

Sustainability: Management of environmental impacts, including energy, emissions and hardware lifecycle.

Review Questions

Short Answer Questions

1. What is the difference between assistive and autonomous AIOps?
2. Define an SBOM and state why it is useful.
3. What security problem does confidential computing address?
4. Give two characteristics of workloads suitable for serverless containers.
5. Why might WebAssembly and containers coexist rather than compete completely?

Long Answer Questions

1. Explain how provenance, signing, digest pinning and admission policies work together in a container supply chain.
2. Compare confidential containers with conventional containers, including benefits, trust assumptions and limitations.
3. Discuss the operational requirements of deploying containers to intermittently connected edge sites.
4. Explain how container platforms can reduce environmental impact and identify risks of measuring sustainability poorly.
5. Evaluate the governance controls required before granting an AI system permission to change production workloads.

Analytical / Application Questions

1. A company has a short-lived, unpredictable API workload and a predictable batch workload. Recommend whether each should use serverless containers, a managed cluster or another model, and justify the decision using latency, utilisation, cost and operational factors.
2. Design a supply-chain policy for a production container platform. Specify requirements for source review, image construction, SBOMs, signatures, provenance, vulnerability exceptions and runtime admission.
3. An edge deployment must continue operating for 24 hours without connectivity and must process sensitive data locally. Propose an architecture and explain its update, identity, recovery, observability and privacy controls.

Multiple Choice Questions with Answers

Question 1

Which practice most directly provides evidence about how a container image was produced?

A. Provenance attestation

B. Horizontal scaling

C. Log rotation

D. Port mapping

Correct Answer: A. Provenance attestation

Question 2

What is a primary purpose of remote attestation in confidential computing?

A. To increase image compression

B. To verify platform measurements before releasing trust or secrets

C. To replace all application authentication

D. To eliminate network latency

Correct Answer: B. To verify platform measurements before releasing trust or secrets

Question 3

A workload uses 3 resource units for 50 hours at 0.02 currency units per unit-hour. Under the stated linear pricing model, what is the usage charge?

A. 0.30 currency units

B. 1.00 currency unit

C. 3.00 currency units

D. 30.00 currency units

Correct Answer: A. 0.30 currency units

Question 4

Which workload is generally a strong candidate for WebAssembly?

A. A kernel-dependent database requiring privileged device access

B. A portable stateless filter with limited system requirements

C. A full virtual machine image

D. A hardware driver requiring unrestricted host access

Correct Answer: B. A portable stateless filter with limited system requirements

Question 5

Why are production image digests valuable?

A. They guarantee the application has no vulnerabilities

B. They identify content immutably unless the referenced artifact changes

C. They automatically reduce CPU consumption

D. They remove the need for access control

Correct Answer: B. They identify content immutably unless the referenced artifact changes

Question 6

Which control is most appropriate before allowing an AI agent to execute a destructive production action?

A. Disable all audit logging

B. Grant unrestricted administrator access

C. Require scoped permissions and human approval

D. Use an untested generated command

Correct Answer: C. Require scoped permissions and human approval

Question 7

If average power is 200 watts for 5 hours, what energy is consumed under E = P × t?

A. 40 watt-hours

B. 205 watt-hours

C. 1,000 watt-hours

D. 10,000 watt-hours

Correct Answer: C. 1,000 watt-hours

Question 8

Which characteristic is especially important for an edge workload?

A. Dependence on continuous high-bandwidth connectivity

B. Ability to operate or degrade safely during disconnection

C. Requirement that all data be sent to a central region

D. Inability to perform local updates

Correct Answer: B. Ability to operate or degrade safely during disconnection

Question 9

What does an SBOM primarily provide?

A. A list of software components and versions

B. A real-time network firewall

C. A hardware temperature reading

D. A replacement for application testing

Correct Answer: A. A list of software components and versions

Question 10

Which statement best describes serverless containers?

A. They require users to manage every host kernel directly

B. They provide container execution while the provider manages much of the underlying infrastructure

C. They can only run WebAssembly modules

D. They cannot scale according to events

Correct Answer: B. They provide container execution while the provider manages much of the underlying infrastructure