If you want to know how an organisation builds software, ask to see its infrastructure invoice rather than its architecture diagram.
What the invoice tells you about the architecture
Cloud spending is frequently treated as a procurement problem, addressed by negotiating discounts and asking teams to be careful. It is better understood as a measurement of engineering decisions, and it is unusually honest.
Several patterns recur.
Capacity provisioned for a peak that lasts an hour a day. Infrastructure sized for the worst case and paid for continuously, because scaling was never built and now feels risky.
Data moving between places it did not need to move between. Transfer charges are a direct tax on a design where components that talk constantly were placed apart.
Storage that nobody deleted. Backups, logs, snapshots and abandoned volumes accumulating indefinitely because no lifecycle policy was ever written.
Environments running out of hours. Development and test infrastructure at full size overnight and at weekends.
Managed services chosen for convenience at volumes where they stopped being economical, which was the right choice originally and was never revisited.
A persistent overspend is an architecture telling you something, and the person who can read it is an engineer rather than an accountant.
This is the practical argument for teaching cost as an engineering property, alongside latency and availability. Teams that see the cost of their own decisions make different decisions, and the effect is usually larger than any negotiated discount.
What the direction covers
The scope: the major cloud platforms, containers, orchestration, continuous integration and delivery, reliability and scaling.
Four areas.
Cloud platforms. Compute, storage, networking, identity and the managed services that replace things teams used to run.
Delivery. Pipelines, automated testing, deployment strategies and release practice.
Operations. Observability, incident response, capacity and cost.
Infrastructure as code. Defining environments in version-controlled definitions rather than by hand.
DevOps was a change in responsibility, not a job title
The original idea was straightforward: the separation between the people who build software and the people who run it produces poor outcomes on both sides. Developers ship things that are difficult to operate because they do not carry the consequences. Operations teams block changes because they carry the consequences and have no influence over the design.
The proposed fix was shared responsibility. The people who build a system are involved in running it, which changes what they build.
What happened in many organisations was different. A DevOps team was created, given the pipelines and the infrastructure, and positioned between development and production. Which is the previous arrangement with a new name and the same handoff.
Three things that distinguish the real change from the relabelling.
Who gets called when it breaks. If the answer is never the people who wrote it, the feedback loop that makes the idea work does not exist.
Whether teams can deploy without a ticket. Self-service infrastructure with guardrails is the point. A queue in front of a different team is not.
Whether operability is designed in. Logging, metrics, health checks, graceful degradation and safe rollback are design features, and they are absent when nobody building the system has to operate it.
The platform engineering framing that has become common is a reasonable evolution: a platform team builds the paved road, and product teams own their services on it. That works when the platform reduces friction and fails when it becomes a gatekeeper again.
Where this sits in the domain
Cloud computing and DevOps is the sixth of eight directions in Astra Trainer's AI, data and computing domain, and it is where software engineering meets operations. It rests on computer science for the systems and networking model and on IT systems and computer networks for the infrastructure understanding that cloud abstractions hide rather than remove.
It connects tightly to cybersecurity, since a large share of modern exposure comes from cloud misconfiguration, and to data science, whose pipelines and platforms run here. You can see the eight directions here.
Kubernetes is a distributed system you now operate
Container orchestration has become close to a default, and the honest assessment is more mixed than the adoption rate suggests.
What it gives you is real: consistent deployment, self-healing, declarative configuration, portability across environments and a common vocabulary that transfers between employers.
What it costs is a distributed system with substantial operational surface area. Networking, storage, identity, upgrades, resource management and a large ecosystem of components that must be kept current and compatible. Debugging a problem may require understanding several layers at once, and the failure modes are unfamiliar to people arriving from traditional infrastructure.
Three questions worth asking before adopting it, and worth revisiting afterwards.
Do you have the scale that makes it pay? The benefits grow with the number of services and teams. For a handful of services, simpler managed compute frequently delivers more with far less to operate.
Who operates it? Either a dedicated capable team, or a managed service where the provider handles the control plane, or an honest acknowledgement that the operational burden will land on people who did not sign up for it.
What is the alternative you are rejecting? Managed container services and serverless platforms cover a wide range of workloads with a fraction of the complexity, and are frequently dismissed without comparison.
Adopting it because it is standard, without the scale or the operational capacity, is one of the more expensive patterns in modern infrastructure, and it shows up as reliability problems attributed to something else.
Reliability is a decision, not an aspiration
The most useful reframing in this direction, because it converts an argument into a calculation.
Everyone says they want high availability. Availability has a cost curve that rises steeply, and each additional level of reliability requires materially more engineering, more redundancy and more operational discipline than the one before.
Four ideas that make the conversation tractable.
Define reliability from the user's perspective. Not whether a server is running but whether the thing people need is working, measured in terms someone outside engineering recognises.
Set an explicit target and accept its consequences. A target implies an allowance for failure. That allowance is a budget, and spending it on planned risk is legitimate.
Use the allowance to govern change. When reliability is comfortably within target, deploy faster and take more risk. When it is not, slow down and stabilise. This turns the permanent argument between velocity and stability into a shared measurement.
Learn from incidents without assigning blame. A review that identifies which person made a mistake produces people who hide mistakes. A review that identifies which conditions made the mistake possible produces systems that resist it.
The roles, named
Cloud engineers and architects.
DevOps and platform engineers.
Site reliability engineers.
Infrastructure engineers working in code rather than consoles.
Kubernetes and container platform specialists.
Observability engineers, a growing specialism.
Cloud cost and efficiency specialists, combining engineering and commercial understanding.
Release and delivery engineers.
Cloud migration specialists, where the work is as much organisational as technical.
Who can be trained into it
Systems administrators. The largest and most natural pool. They understand operating systems, networking and what breaks in production. What they need is programming practice: version control, testing, code review and treating infrastructure as software.
Network engineers. Into cloud networking, which is conceptually familiar and differs enough in implementation to require real learning.
Software engineers. Into platform and reliability roles, needing the operational and networking half.
Database administrators. Into managed data services and reliability.
Support and operations staff. Into observability and incident response, already holding the instinct for what matters at three in the morning.
Security engineers. Into cloud security engineering, which is one of the scarcest combinations available.
Finance analysts working alongside engineers, into cost engineering, where the commercial half is already present.
Configuration, data location and continuity obligations. Cloud misconfiguration is a leading cause of data exposure, and access to production systems should be controlled, logged and subject to change management. Where data is stored and processed carries legal consequences under data protection and sector-specific regimes, and requirements differ by jurisdiction. Regulated sectors have additional obligations covering outsourcing, resilience testing and exit planning. Astra Trainer builds engineering capability and awareness of where these duties apply. It is not legal or compliance advice and does not substitute for qualified assessment.
What to take from this
The infrastructure bill is a readout of architectural decisions, and persistent overspend is an engineering problem wearing a procurement costume.
DevOps described a change in who carries the consequences of running software, and a separate DevOps team frequently rebuilds the wall it was meant to remove.
Kubernetes delivers real value at real scale and brings a distributed system you now operate, which is a cost regularly underestimated.
Reliability targets are business decisions with steep cost curves, and making the target explicit turns a permanent argument into a shared measurement.
And your systems administrators are the best available source of cloud engineers. The gap is software practice, not infrastructure understanding.
Why is cloud cost an engineering issue?
Because the bill reflects design decisions: capacity provisioned for rare peaks, data moving between components that should have been co-located, storage nobody deletes, environments running out of hours, and managed services chosen at volumes where they stopped being economical.
What did DevOps actually mean?
Shared responsibility for building and running software, so the people who design a system carry the consequences of operating it. Creating a separate DevOps team between development and production recreates the handoff it was meant to remove.
Should every organisation use Kubernetes?
No. It pays off with many services and teams, and it brings a distributed system with substantial operational surface. For a handful of services, managed container or serverless platforms often deliver more with far less to operate.
How should reliability targets be set?
Explicitly, from the user's perspective, with the understanding that each additional level of availability costs substantially more. The resulting allowance for failure becomes a budget that governs how much change risk the team takes.
Who converts well into cloud and DevOps roles?
Systems administrators first, needing software practice rather than infrastructure knowledge. Then network engineers into cloud networking, developers into platform and reliability work, and support staff into observability and incident response.