A practical guide to infrastructure and delivery
Cloud & DevOps
Understand how infrastructure choices, repeatable releases, useful monitoring and recovery planning support a software product throughout its operation.
Infrastructure · CI/CD · Monitoring
Cloud and DevOps
Connect the place software runs with the way it changes
Cloud provides computing resources and managed services. DevOps describes collaborative working practices and automation across development and operations.
They address related questions: where will the application run, how will changes reach users, who notices problems and how will service be restored? DevOps practices can also be useful on a VPS or privately managed infrastructure.
A suitable setup begins with the application, users, information sensitivity, operating budget and the people who will maintain it. More components do not automatically create a better environment.
Choose the foundation
Match infrastructure to operational needs
Compare options using total operating effort as well as monthly resource prices.
Managed hosting
A provider handles defined platform tasks. Check supported runtimes, resource limits, backups, access and what remains your responsibility.
VPS or virtual machines
A configurable environment with more responsibility for the operating system, updates, service configuration and recovery.
Cloud services
Compute, storage, databases and other services can be combined around a workload. Plan networking, provider limits, data location and costs.
Repeatable releases
Make the route from code to production explicit
A delivery pipeline turns agreed checks into repeatable steps. It helps show which version is being released and what has been verified.
-
Build and check
Prepare a versioned application package and run relevant automated checks when code changes.
-
Test separately
Use a staging environment to inspect key workflows, integration behavior and database changes before production.
-
Approve and release
Apply the agreed release gate, which may include human approval. Record the version and verify service after deployment.
Know what is happening
Turn signals into useful operational decisions
Logs, metrics and checks answer different questions. The useful set depends on the product and the people responding.
Logs
Record relevant events and errors so an incident can be investigated. Limit sensitive data, control access and agree retention.
Metrics and checks
Track request failures, response times, resource pressure and important background tasks alongside meaningful service checks.
Actionable alerts
Use a clear condition, responsible contact, escalation route and response instructions. Review noisy alerts and missed incidents.
Access and configuration
Keep responsibilities and permissions clear
A provider’s security controls do not replace application and account responsibilities. The division depends on the selected services.
- Give individual accounts only the permissions their work needs; review privileged access and remove obsolete access.
- Keep passwords, tokens and signing keys out of public code and logs; use controlled storage and an agreed rotation process.
- Limit exposed services, maintain HTTPS and apply relevant application, runtime and operating-system updates.
- Record who owns accounts, approves changes, handles provider notices and reviews the resulting configuration.
Prepare for disruption
Agree recovery objectives and prove the process
Backups should cover the information and configuration needed to restore the application, with retention, access and storage defined.
Recovery point objective — RPO
The target maximum acceptable period of data loss after disruption. It guides backup frequency, replication and related design decisions.
Recovery time objective — RTO
The target duration for restoring agreed service after disruption. It depends on people, procedures and infrastructure.
Recovery tests
Restore into a suitable environment, check information and application behavior, record the result and correct gaps.
Move with a plan
Treat migration as a controlled operational change
Moving an application requires more than copying code. Account for stored files, databases, domain settings, email and external integrations.
-
Assess and rehearse
Inventory dependencies, access and data. Prepare the destination and test the migration using protected copies.
-
Plan the switch
Agree responsibilities, timing, communication, final data synchronization and the condition that triggers rollback.
-
Verify and hand over
Check user journeys, data, background jobs, alerts and access. Keep the previous environment available for the agreed transition period.
Ownership and cost
Make the environment understandable and affordable
Recurring costs can include compute, database, storage, traffic, backups, monitoring and third-party services.
Estimate ordinary and peak usage, set budget alerts and review actual consumption. Scaling rules need limits and testing; they do not remove the need for capacity planning. Right-size resources using measured behavior rather than assumptions.
A useful handover includes an infrastructure map, account ownership, environment configuration, release instructions, monitoring contacts, recovery procedures and access removal steps. Agree who pays providers and who maintains each component.
Cloud & DevOps establishes and operates infrastructure and delivery practices. Ongoing product support handles user requests and application fixes. Define how the two responsibilities meet when a failure crosses both areas.
Questions about Cloud & DevOps
Choose an approach that the product and its operators can maintain.
Does every project need a large cloud setup?
No. Managed hosting or a well-maintained VPS may be sufficient. Choose against workload, control, recovery needs and the team’s operating capacity.
Is Kubernetes required?
No. It adds orchestration capabilities and operating responsibilities. Use it when a justified workload and maintenance plan make it appropriate.
Does CI/CD deploy every change automatically?
Not necessarily. Build and test steps can be automated while production release still requires an authorized person’s approval.
Who owns the cloud account?
Ownership, billing and access should be agreed explicitly. The organization needs appropriate access to its resources and a documented handover or exit route.
Does a cloud provider handle all security?
No. Responsibilities vary by service. Application code, information, permissions and configuration still require accountable owners.
Can infrastructure costs grow unexpectedly?
Usage, traffic, retained data and additional services can change spending. Estimates, limits, budget alerts and regular reviews help manage that risk.
Can migration happen without interruption?
Sometimes, but it depends on architecture and data changes. Agree the transition method and expected impact rather than promising uninterrupted service in advance.
How is a backup different from recovery?
A backup is a saved copy. Recovery restores a usable application with required information and configuration; periodic tests establish whether that process works.
Official sources for further reading
These resources explain the practices behind the guide, without requiring a particular provider for every project.
- AWS: What is DevOps?
Collaboration, automation and practices across development and operations.
- GitHub Actions: core concepts
How workflows can build, test and deliver software through defined jobs.
- AWS: shared responsibility
How provider and customer responsibilities depend on selected services.
- AWS reliability: backup and recovery
Recovery objectives, protected backups and periodic restore testing.
Start with the application and its operating needs
Review the current environment, release process, recovery requirements and budget to define a practical infrastructure plan.
