Services / Run & scale
Cloud and DevOps engineering, built to hand over
We build the platform your software runs on: Terraform infrastructure as code, CI/CD pipelines with real quality gates, container or serverless runtimes, OpenTelemetry observability, service level objectives with error budgets, and FinOps guardrails. Everything lives in your accounts and your repositories from day one, because a platform only your vendor can operate is a liability.
- Terraform by default, with a written reason when we deviate
- SLIs and SLOs defined with you, not inherited from a template
- FinOps guardrails before the first workload, not after the bill
- Paired on-call handover and a rehearsed failure exercise
At a glance
- Clouds
- AWS, Azure, Google Cloud
- Default IaC
- Terraform, with CDK and Pulumi on request
- Runtimes
- EKS, ECS Fargate, Lambda, AKS, GKE, Cloud Run
- Observability
- OpenTelemetry, Grafana, CloudWatch, Datadog
- Availability target
- 99.95% on supported architectures
- Typical first-quarter cost saving
- 25 – 40 percent on ungoverned estates
- Enquiries
- nitesh@redcubical.com
Foundations
Why we default to Terraform
Terraform, CDK or Pulumi
Terraform is our default because it is cloud-agnostic, its declarative HCL keeps plan output reviewable by someone who did not write the code, and the hiring pool is large enough that you can staff the platform after we leave. We choose CDK for single-cloud AWS estates with a strongly TypeScript-centred team, and Pulumi where the infrastructure genuinely needs general-purpose programming.
| Tool | Strongest where | Main drawback | We choose it when |
|---|---|---|---|
| Terraform / OpenTofu | Multi-cloud estates, reviewable plans, largest provider ecosystem and hiring pool | HCL is deliberately limited; complex logic becomes awkward and module abstraction can be over-applied | Default for almost everything, especially where the client team must own it afterwards |
| AWS CDK | AWS-only estates, teams already fluent in TypeScript, higher-level constructs reduce boilerplate | Synthesised CloudFormation is harder to review; drift and stack update failures are unpleasant | Single-cloud AWS with an application team that will maintain infrastructure themselves |
| Pulumi | Genuine programming constructs, strong testing story, multi-cloud | Smaller community, state service dependency unless self-managed, easier to write infrastructure nobody else understands | Complex dynamic infrastructure where HCL would need generated code |
| CloudFormation or ARM/Bicep directly | Native support, no third-party state, sometimes mandated by internal policy | Verbose, slower feature parity in ARM, and single-cloud by definition | Client policy prohibits third-party IaC tooling |
Whatever the tool, the disciplines are the same: remote state with locking, no manual console changes, plan output attached to every pull request, drift detection on a schedule, and policy-as-code checks with Checkov or OPA before apply.
Delivery
Anatomy of a pipeline we would put our name on
Nine stages. Each either passes fast or fails with an actionable message. A pipeline nobody trusts gets bypassed, and a bypassed pipeline is worse than none.
-
Commit and static analysis
Lint, format check, type check and secret scanning with gitleaks. Runs on every push and finishes inside two minutes so developers do not context-switch away while waiting.
-
Unit and contract tests
Parallelised unit tests with a coverage floor on changed lines rather than a global percentage, which is the metric that actually changes behaviour. Consumer-driven contract tests verify service boundaries without needing the whole estate running.
-
Build and sign the artefact
One immutable artefact promoted through every environment. Container image built reproducibly, signed with cosign, and accompanied by an SBOM. Nothing is ever rebuilt per environment, because that means production runs untested bytes.
-
Vulnerability and licence scanning
Image and dependency scanning with Trivy or Grype, plus licence policy checks. Critical findings with a fix available block the build. Findings without a fix are recorded with an expiry so exceptions cannot become permanent silently.
-
Infrastructure plan and policy check
Terraform plan posted to the pull request, with Checkov or OPA policy evaluation. Destructive changes to stateful resources require a second reviewer regardless of who raised the change.
-
Ephemeral environment and integration tests
A short-lived environment provisioned per pull request, seeded with anonymised data, running integration and end-to-end tests on the journeys that generate revenue. Torn down on merge, with a maximum lifetime so orphans cannot accumulate cost.
-
Progressive deployment
Canary or blue-green with automated analysis of error rate, latency and saturation against the previous version. Rollback is automatic on breach and does not wait for a human to notice a dashboard.
-
Post-deploy verification
Synthetic checks against real user journeys, plus a smoke suite against production. Deployment markers are pushed to the observability platform so any later graph anomaly can be correlated to a release.
-
Metrics emission
Every run emits lead time, deployment frequency, change failure and restore time data. DORA metrics are a by-product of the pipeline, never a spreadsheet somebody maintains by hand.
Decision
Kubernetes, ECS or serverless?
Runtime selection
Choose serverless for spiky or low-baseline workloads and event processing. Choose ECS Fargate for steady containerised services when you want containers without a control plane to operate. Choose Kubernetes when you need multi-cloud portability, dense workload packing, or ecosystem components with no managed equivalent, and you have the people to run it. The deciding constraint is usually team size, not workload shape.
| Factor | Kubernetes (EKS / AKS / GKE) | ECS Fargate | Serverless (Lambda / Cloud Run) |
|---|---|---|---|
| Operating overhead | High. Control plane upgrades, add-on lifecycle, node management, CNI and ingress ownership | Low. AWS manages the data plane; you own task definitions and networking | Lowest. No runtime to patch |
| People needed | One to two platform engineers as a realistic floor | Fractional DevOps allocation is sufficient | Application engineers with pipeline support |
| Cost at steady load | Efficient once bin-packing is tuned; control plane and node overhead are fixed costs | Slight premium per vCPU-hour, no idle node waste | Most expensive per unit of sustained compute |
| Cost at spiky or low load | Poor. You pay for nodes and control plane while idle | Good. Scales to the task count you need | Best. Genuinely nothing when idle |
| Cold start behaviour | None once pods are warm | Task start measured in tens of seconds; keep a warm baseline | Real concern for latency-sensitive paths; provisioned concurrency costs money |
| Long-running and stateful work | Strong. StatefulSets, operators, custom schedulers | Good for long-running services; weak for stateful clustering | Constrained by execution timeouts and ephemeral storage |
| Portability | Highest. The same manifests run on any conformant cluster | AWS-specific | Most provider-coupled, especially around events and IAM |
| Right for | Twenty-five-plus engineers, many services, or a genuine portability requirement | Most mid-size estates with steady containerised services | Event pipelines, scheduled work, APIs with unpredictable traffic |
Our honest bias: we recommend ECS Fargate more often than clients expect, and Kubernetes less often. Kubernetes bills more for us and costs more for you to own. If you are choosing it because it is the default answer rather than because of a requirement you can name, that is worth a conversation before the commitment.
Reliability
Observability, SLOs, error budgets and incident response
How we make systems observable
We instrument with OpenTelemetry so traces, metrics and logs share one correlation identifier and you are not locked to a vendor agent. Then we define service level indicators from the user's point of view, set objectives with you, and derive an error budget. The budget is what turns "should we slow down and fix reliability" from an opinion into arithmetic.
What gets instrumented
- Distributed traces across every service hop with tail-based sampling that keeps all errors and slow traces while sampling the healthy majority.
- The four golden signals per service: latency, traffic, errors, saturation. Recorded as histograms, so p95 and p99 are real numbers rather than estimates from averages.
- Structured logs as JSON with trace and span identifiers attached, so a log line leads directly to its trace.
- Business events alongside technical ones. Orders placed per minute detects an outage faster than CPU utilisation ever will.
- Deployment and configuration change markers on every dashboard, because most incidents follow a change.
- Synthetic journeys from the regions your users are actually in.
SLIs, SLOs and error budgets
- SLI. A measurable ratio of good events to valid events, defined from the user's perspective. "Proportion of checkout requests served under 800 ms without a 5xx."
- SLO. The target for that ratio over a rolling window. 99.9 percent over 30 days.
- Error budget. What 99.9 percent permits: about 43 minutes of failure per 30 days. Spend it on releases, or lose it to instability.
- Burn-rate alerting. Page on fast budget consumption, not on every threshold breach. This is how you cut alert volume without going blind.
- Budget policy. Agreed in advance: when the budget is exhausted, feature work pauses until it recovers. Written down before it is needed, not negotiated during an incident.
Three to five SLOs per service. Twenty SLOs means nobody looks at any of them.
Incident management that improves the system
Detection is only useful if the response is rehearsed and the review changes something. Both halves below are agreed in writing before the first production deployment, not after the first outage.
How an incident runs
- Detect. Burn-rate or synthetic alert pages the on-call engineer with a link to the runbook, the dashboard and recent deployments.
- Declare and assign. Severity set against a published matrix. Incident commander named. For P1 a scribe and a communications owner are separate people from the person fixing it.
- Mitigate before diagnose. Roll back, fail over or shed load first. Understanding the root cause is a post-incident activity, not a live one.
- Communicate on a clock. Status updates at fixed intervals even when there is nothing new. Silence is what escalates an incident into a relationship problem.
- Resolve and verify. Confirm recovery against the SLI, not against a feeling that it looks better.
- Review within five working days. Blameless, written, with a timeline and contributing factors.
What we insist on
- Blameless reviews. Human error is a symptom of system design. If a single mistyped command can take production down, the system permitted it.
- Action items with owners and dates. A review with no dated actions is a diary entry.
- A runbook per alert. If an alert has no runbook, either write one or delete the alert.
- Sustainable on-call. Realistic rotation size, compensation, and a hard rule that more than two pages per shift triggers a review of the alerting rather than the engineer.
- Rehearsed failure. Scheduled game days in non-production: kill a node, sever a dependency, exhaust a connection pool. The first practice should never be the first real incident.
FinOps
Cost guardrails that hold without constant policing
Our FinOps model
Four layers: mandatory tagging so every dollar has an owner, budgets with alerts at 50, 80 and 100 percent of forecast, machine-learning anomaly detection on daily spend by service, and commitment coverage through savings plans and reserved instances once a baseline is proven stable for 60 days. Guardrails first, optimisation second. Optimising an untagged estate means you cannot prove what you saved.
- Tag policy enforced at creation. Owner, environment, cost centre, service and data classification. Untagged resources are blocked by policy-as-code, not chased in a spreadsheet later
- Budgets per account and per service with alerts at 50, 80 and 100 percent of monthly forecast, routed to the owning team rather than to finance alone
- Anomaly detection on daily spend per service, with a monetary impact threshold so alerts stay meaningful
- Savings plans and reserved capacity sized to the proven baseline only, typically 60 to 75 percent coverage, leaving headroom for architecture change
- Spot and Graviton for fault-tolerant and batch workloads; Graviton alone often yields 15 to 25 percent on comparable performance
- Storage lifecycle policies moving objects to infrequent access and archive tiers automatically, with retention aligned to actual policy
- Non-production shutdown schedules. Development and staging idle outside working hours is typically 60 percent of their hours
- Orphan sweeps for unattached volumes, idle load balancers, unused elastic IPs, old snapshots and forgotten NAT gateways
- Egress and cross-zone traffic reviewed explicitly. Data transfer is the line item that surprises people most often
- Unit economics reported monthly. Cost per tenant, per transaction or per thousand requests. Absolute spend rising while unit cost falls is a healthy business
Measurement
DORA metrics and the ranges we work towards
Instrumented from pipeline and incident data automatically. We baseline in week one so improvement is measured rather than asserted.
| Metric | What it measures | Common starting point | Target range we work to | Main lever |
|---|---|---|---|---|
| Deployment frequency | How often code reaches production | Every two to six weeks | Daily to on-demand per service | Trunk-based development, feature flags, decoupled release from deploy |
| Lead time for changes | Commit to running in production | Two to six weeks | Under one day; under one hour for mature services | Pipeline duration, review latency, batch size |
| Change failure rate | Deployments causing degradation or rollback | 25 to 40 percent | Under 15 percent | Test quality, canary analysis, smaller changes |
| Failed deployment recovery time | Time to restore service after a bad change | Two to twelve hours | Under one hour; under 15 minutes with automated rollback | Automated rollback, progressive delivery, rehearsed runbooks |
| Reliability (added in later DORA reports) | Whether the service meets its stated SLOs | No SLOs defined at all | SLOs defined, met, and reviewed monthly | SLO definition, burn-rate alerting, error budget policy |
A caution on these numbers: deployment frequency is trivially gamed by deploying trivia. We report all four together, because throughput improvements that raise change failure rate are not improvements. Batch size is the lever that moves all four in the right direction at once.
Handover
Making your team the platform owner
How platform handover works
Handover is designed in from the start, not arranged at the end. Your accounts, your repositories, your cloud credentials from day one. Then a structured transfer: recorded walkthroughs, runbooks your engineers execute themselves, paired on-call shifts where they lead, and a rehearsed failure exercise before we step back.
-
Week 1
Your accounts, your repositories
Nothing is built in our tenancy and migrated later. Your engineers have commit access to the infrastructure code from the first commit and are named reviewers on pull requests from the start.
-
Throughout delivery
Decisions recorded as they are made
An architecture decision record for every material choice, written at the time with the alternatives that were rejected and why. Documentation written after the fact omits exactly the reasoning that matters later.
-
Final third of the engagement
Your engineers drive, ours review
Your team takes changes end to end with our engineers as reviewers rather than authors. This is where gaps surface while there is still time to close them.
-
Final month
Runbook execution and paired on-call
Your engineers execute each runbook themselves in a non-production environment. Anything they cannot follow gets rewritten. Then paired on-call shifts with your engineer as primary and ours as shadow.
-
Before exit
Rehearsed failure exercise
A scheduled game day in staging: node failure, dependency outage, connection pool exhaustion, expired certificate. We watch your team respond and fix what the exercise exposes.
-
After exit
Defined support, or none
Either a support agreement with contractual response targets, or a clean exit with a 30-day question window. What we avoid is the ambiguous arrangement where nobody is quite sure who is on call.
Answers
Cloud and DevOps engineering questions
What does cloud and DevOps engineering actually cover?
Four things: the infrastructure your application runs on defined as code, the pipeline that gets code from commit to production safely, the observability that tells you what is happening once it is there, and the cost and reliability governance that keeps both defensible. It is platform work, not a job title attached to your existing team.
Why do you default to Terraform rather than CDK or Pulumi?
Three reasons. It is multi-cloud, so the same tooling and review habits apply whether a workload lands on AWS, Azure or Google Cloud. Its declarative HCL constrains what an engineer can express, which makes plan output reviewable by someone who did not write it. And the hiring pool is far larger, so you can staff the platform after we leave. We use CDK where a team is strongly TypeScript-centred and single-cloud, and Pulumi where genuinely complex logic makes HCL awkward.
Should we use Kubernetes?
Probably not, unless you already have a platform team or genuinely need what it provides: multi-cloud portability, dense multi-tenant workload packing, or an ecosystem component with no managed equivalent. Kubernetes has a real operating cost in people, not just compute. Most teams under about twenty-five engineers get better outcomes from ECS Fargate or serverless, and we say so even though Kubernetes work bills more.
How long does it take to rebuild a CI/CD pipeline?
Four to eight weeks for a typical application estate. Weeks one and two are assessment and the first pipeline end to end for one service. Weeks three to six migrate the remaining services and add quality gates. The last two weeks cover environment promotion, rollback rehearsal and handover. The variable that dominates is test suite quality, not pipeline tooling.
What is an error budget and why does it matter commercially?
If your availability objective is 99.9 percent over 30 days, you have roughly 43 minutes of permitted unavailability. That is the error budget. While budget remains, ship features. When it is exhausted, reliability work takes priority until it recovers. It converts an argument about whether to slow down into an arithmetic question, which is why engineering and product stop having the same fight every quarter.
How much can you reduce our cloud bill?
On estates that have never had cost governance we typically find 25 to 40 percent within the first quarter, mostly from rightsizing, removing orphaned resources, storage lifecycle policies and committing baseline compute to savings plans. On an estate already under active FinOps management the realistic figure is 5 to 12 percent. Anybody promising a fixed percentage before seeing your billing data is guessing.
Will our own team be able to run the platform after you leave?
That is the delivery goal, and it is why everything lives in your repositories and your cloud accounts from the first day. Handover includes runbooks, architecture decision records, a recorded walkthrough of each pipeline, and paired on-call shifts where your engineers lead and ours observe. We also run a deliberate failure exercise in a non-production environment so the first real incident is not the first practice.
Do you work across AWS, Azure and Google Cloud?
Yes, with the deepest bench on AWS, then Azure, then Google Cloud. Where a client has no incumbent we usually recommend a single primary cloud rather than a multi-cloud posture, because multi-cloud doubles the operational surface and rarely delivers the negotiating leverage it promises. Multi-cloud makes sense for specific data residency or regulatory requirements, not as a default.
Start with a platform and cost review
Three weeks, fixed fee. You get an architecture assessment, a pipeline and environment audit, a costed remediation plan and a cloud spend analysis with named savings. The output is yours whether or not you engage us for the work.