Cloud engineering
Cloud work goes wrong in two directions: infrastructure built for a load that never arrives, and infrastructure that quietly cannot survive the load that does. We size environments, pipelines, storage and monitoring to the workload in front of us, then review the bill against it.
- Google Cloud · AWS
- Cloud Run · Cloud Functions
- CI/CD · IaC
- Backups & observability
BUILD
Product engineering & technology
The applications, interfaces, services and infrastructure your business actually runs on — mobile, web, backend, cloud and the automation around them, built by the same people who will later measure and advertise them.
Cloud engineering here means the parts of a system that are not application code: the environments it runs in, the pipeline that puts it there, where its files and data live, and how anyone finds out when something breaks. Most of it is invisible while it works. It becomes the whole conversation the first time a deploy fails at the wrong hour. We treat that as engineering work with its own design, not as configuration done at the end of a build.
Reference architectures are drawn for the largest plausible reader. Copying one gives you a multi-region cluster, a service mesh and a bill for capacity nobody is using. We start from the workload: how many requests, how bursty, how much data, what has to stay warm, what can be cold and slow. A single managed container and a managed database is the right answer more often than the diagrams suggest, and it is usually cheaper to run.
The other half of the job is making the setup legible to someone who was not there when it was built. Infrastructure defined in code where that is worth the effort, documented console state where it is not. A deployment runbook, a rollback path, alerts routed somewhere a person reads, and a restore that has actually been run rather than assumed. Accounts stay in your name. If we stop working together, nothing about the infrastructure has to change.
Why people call us about infrastructure
Almost nobody asks for cloud engineering in the abstract. They ask after a release goes wrong, after a bill arrives, or after someone senior asks a question the setup cannot answer.
- Deploys are manual and slightly frightening
- Someone builds locally, copies files to a server and hopes the environment matches. There is no record of what was deployed, no way to reproduce it, and no way back except doing the same thing again with older files. Releases get postponed because the process is stressful, so changes accumulate and each deploy carries more risk than the one before it.
- Staging and production behave differently
- Staging runs a different database version, a different runtime, different environment variables or a much smaller machine. Bugs pass staging and fail in production, so people stop trusting staging and start testing on live. The gap is usually undocumented, which means nobody can say which difference caused the failure without reproducing it by hand.
- The cloud bill grew without an explanation
- Nobody owns the account, so nothing gets switched off. Old environments, orphaned disks, logs retained forever, a database provisioned large during a launch and never resized, egress from an image pipeline that re-encodes the same asset repeatedly. The line items are visible but attributed to nothing, so the bill is treated as a fixed cost rather than a set of decisions.
- Backups exist but have never been restored
- A backup schedule is configured, the console shows green, and nobody has ever tried to bring a system back from it. Retention may be too short, the snapshot may not include the object storage bucket, and the person holding the credentials may have left. A backup that has not been restored is a belief, not a control.
What we build and operate
Scope varies with the system. Environments, the pipeline and monitoring are normally in scope whatever else is, because they decide how everything else behaves under pressure.
Environment design and parity
We define what local, preview, staging and production each mean, and keep the differences deliberate and written down. Configuration lives outside the code, the same build artefact moves between environments, and the things that must differ — data, scale, credentials — differ for a stated reason.
- Per-environment configuration held outside the repository
- One build artefact promoted between environments, not rebuilt per target
- Matched runtime, database engine and extension versions across environments
- Preview deployments per branch or pull request where the stack supports it
- Seeded, non-production data in staging rather than a copy of live records
- A written list of every intentional difference between staging and production
Deployment pipelines
Build, test and deploy run from your repository on every change, with the same steps for every environment. A deploy becomes a commit, a log line and a version you can point at. Rolling back becomes selecting a previous release, not reconstructing one from memory late at night.
- Continuous integration on pull requests: type checks, tests, build
- Automatic deployment to preview and staging on merge
- A manual approval gate in front of production releases
- Immutable, versioned build artefacts and container images
- Database migrations run as an explicit, reversible pipeline step
- A rollback path tested before the first production release
Compute sized to the workload
Serverless functions for spiky, event-driven work. Managed containers for services that need a warm runtime and predictable behaviour. A plain virtual machine when that is genuinely simpler. We choose per workload rather than standardising on one shape, and we say so when a smaller instance would do.
- Cloud Run or equivalent managed containers for HTTP services
- Cloud Functions and Lambda for event, queue and webhook handlers
- Scheduled jobs and queues for work that does not belong in a request
- Concurrency, memory and instance limits set from observed usage
- Cold-start behaviour measured and mitigated where users feel it
- Autoscaling bounds with a ceiling, so a runaway loop cannot become a bill
Storage, databases and delivery
Managed databases with automated backups and a documented restore procedure. Object storage for files, with signed access rather than public buckets. A CDN in front of static assets and media so origin capacity is spent on requests that need it. Lifecycle rules so storage does not grow forever by default.
- Managed PostgreSQL or MySQL with point-in-time recovery where offered
- Firestore or a document store where the access pattern genuinely suits it
- Object storage with signed URLs and no world-readable buckets by default
- CDN caching rules and invalidation tied to the deployment pipeline
- Image and media handling that does not re-encode the same asset repeatedly
- Retention and lifecycle policies on logs, backups and uploads
Secrets, access and account hygiene
Credentials live in a secret manager, not in the repository, a shared document or a laptop. Access is granted per person and per service at the narrowest scope that works, with a written record of who and what holds which key, and a plan for rotating them.
- Secret Manager or the platform equivalent as the only source of credentials
- Service accounts scoped per workload rather than one shared owner key
- Named human access with no shared logins
- A rotation plan for API keys, tokens and database passwords
- Repository secret scanning, including history, for keys already committed
- An offboarding checklist for anyone who leaves the project
Observability and cost review
Logs, metrics, uptime checks and error reporting configured so a failure reaches a person rather than a dashboard nobody opens. Alerts tuned to be worth interrupting someone for. Cost reviewed against actual usage on a regular cadence, with the largest line items explained in plain terms.
- Structured logs with request identifiers that cross service boundaries
- Uptime and latency checks on the paths that matter to users
- Error and crash reporting routed to email or a chat channel
- Alert thresholds set from observed behaviour, not arbitrary round numbers
- Budget alerts and per-service cost attribution
- A periodic sweep for unused resources, excess retention and oversized instances
How the work runs
Infrastructure work is easiest to get right before there is traffic on it, and most valuable when there already is. The sequence is the same either way; the risk management differs.
- 01
Read the workload before drawing anything
We look at what the system actually does: traffic shape, data volume, the slowest endpoints, what runs on a schedule, what has to stay available and what can fail quietly for an hour. Existing bills, logs and incident history answer more of this than a planning meeting does.
- 02
Design the environments and the boundaries
Environments, regions, networking, storage and database choices are decided together and written down with the reasoning attached. Where infrastructure as code earns its keep we write it; where a small setup would be buried under tooling, we document the console state instead and say plainly that we did.
- 03
Build the pipeline before the first real deploy
Continuous integration, deployment and rollback are set up while the stakes are still low. Migrations, secrets and environment configuration are wired in here rather than patched in afterwards. The first production release then uses the same path every later release will use, which is the only reliable way to learn that the path works.
- 04
Instrument, then break it on purpose
Monitoring, alerting and error reporting go in before launch. We then run the failure cases deliberately: restore a backup into a scratch environment, roll back a release, revoke a key, take a dependency offline. A control that has never been exercised is an assumption wearing the clothes of a control.
- 05
Review cost and capacity against real usage
Once real traffic has been through the system, the numbers disagree with the plan. We resize what was overprovisioned, add capacity where it is genuinely tight, prune retention and unused resources, and record what changed so the next review starts from evidence rather than from the original guess.
Environments we normally set up
Three tiers, with the differences between them chosen rather than inherited. Not every project needs all three, though the tier skipped at the start is usually the one rebuilt later, under pressure.
Local & preview
- Containerised local stack matching production runtime versions
- Emulators for cloud services where the platform provides them
- Per-branch preview deployments, each with its own URL
- Seeded fixture data, never a copy of production records
- Credentials from a developer-scoped store, not a shared file
Staging
- The same build artefact and container image that production will run
- Matching database engine and extension versions on a smaller instance
- Third-party integrations pointed at sandbox or test accounts
- Migrations rehearsed here before they touch live data
- Every intentional difference from production written down
Production
- Deploys only through the pipeline, from a tagged commit
- A manual approval gate and a rollback path that has been used
- Automated backups plus a restore that has actually been performed
- Monitoring, uptime checks and alerts routed to a named recipient
- Access limited to the accounts that need it, reviewed periodically
What we hand over with the infrastructure
Infrastructure that only one party understands is a dependency, not a deliverable. This is the material that goes with the running system, and it is written for whoever inherits it.
- Infrastructure as code in your repository, or a written record of console state where code was not warranted
- A deployment runbook: how a release goes out, who approves it, and what to check afterwards
- A rollback path, documented and exercised at least once on a real release
- Monitoring, uptime checks and error reporting, with alert routing to named recipients
- A backup schedule with retention stated, and evidence of a restore we actually performed
- A cost breakdown by service, with the drivers behind the largest line items explained
- An access inventory: every human and service account, its scope, and why it exists
- A key and credential rotation plan with intervals and an owner against each item
- An incident contact path: who is contacted, in what order, and what each person can do
- Environment configuration documented, including every deliberate difference between staging and production
- Cloud accounts, billing and domain registrations held in your name
Independence from the platforms we use
We hold no reseller agreement, partner status or certification with Google Cloud, Amazon Web Services or any other cloud provider, and we do not resell their capacity. Platform names appear here because they are the products we work with. Wherever you want it, the cloud accounts, billing relationship and domain registrations sit in your name, with us added as a user you can remove. Nothing in the arrangement is designed to make leaving difficult.
Technology we work with
These are product names used descriptively, and they are trademarks of their respective owners. Listing one implies no partnership, reseller arrangement, sponsorship or certification, and we hold none. The right set for a project is decided by the workload and by what your side can maintain, not by what we happen to know already.
- Platforms & compute
- Google Cloud
- Cloud Run
- Cloud Functions
- Firebase
- AWS
- AWS Lambda
- Amazon ECS
- Vercel
- Storage, data & delivery
- Cloud SQL
- PostgreSQL
- Firestore
- Cloud Storage
- Amazon S3
- Amazon RDS
- Cloud CDN
- Cloudflare
- Pipelines & configuration
- GitHub Actions
- Docker
- Terraform
- Cloud Build
- Artifact Registry
- Secret Manager
- AWS Secrets Manager
- Observability
- Cloud Logging
- Cloud Monitoring
- Sentry
- Firebase Crashlytics
- Uptime checks
- BigQuery log sinks
What you are left with
- Releases that go out through a pipeline instead of by hand
- Staging that predicts production, because the differences are deliberate
- A restore procedure someone has run, not a backup setting someone enabled
- Monitoring that raises a failure to a named person, not to an unread dashboard
- A cloud bill whose largest lines you can explain
What people ask before starting
01Do we have to be on Google Cloud or AWS?
No. The platform follows the workload and your constraints, including where data has to stay and what your side can operate. A small service is usually better on one managed platform with a managed database than spread across three providers. We will tell you when a simpler or cheaper host is the correct answer, even when it is the less interesting thing to build.
02Who owns the cloud accounts and the billing?
You do, wherever you want that. We prefer to work inside accounts registered in your name with our access added as named users, so removing us is a permissions change rather than a migration. Domains, DNS, container registries and repositories follow the same rule. If we hold anything on your behalf during a build, it is written down and transferable.
03What actually drives the cost, yours and the platform's?
Our side is driven by how many environments and services exist, how much of the current setup is undocumented, and whether live data has to be migrated rather than started fresh. Your platform bill is driven mostly by always-on compute, database instance size, log and backup retention, and egress. Moving a running production system costs more than building alongside it and switching over.
04Will you guarantee uptime?
No. We do not sell uptime guarantees, and we would be wary of anyone offering one for infrastructure they do not staff around the clock. What we do provide is monitoring that detects failure, a rollback path that reverses a bad release, backups that have been restored at least once, and a written contact path for when something goes wrong.
05What happens if a deployment breaks production?
The rollback path is agreed and exercised before the first release, so the first response is returning to the last known good version rather than debugging under pressure. Alerts should reach a person before your customers do. Afterwards we write down what failed and what changed as a result, because an incident with no record tends to happen twice.
06What will you not do?
We will not build a multi-region, multi-cluster architecture for a workload one managed service handles comfortably. We will not take custody of your billing account in order to mark it up. We will not leave you with infrastructure only we can operate. And we will not claim a partnership, reseller status or certification with a cloud provider, because we have none.
What this work usually connects to
Right-size the infrastructure you run
Send the shape of your workload, your current setup or last month's cloud bill. We will come back with what to keep, what to resize, what to move and what should not exist at all.
Directcontact@mnfinfotech.com