Performance & data
Google Cloud Development
We build and run the backend half of an ecommerce operation on Google Cloud — serverless containers on Cloud Run, images built by Cloud Build, credentials in Secret Manager, and every service holding an identity of its own.
Serverless containers, not a pile of VMs
Most of what an ecommerce business needs from a cloud is a handful of small services that answer HTTP, hold some state, talk to Shopify and to each other, and cost nothing when nobody is shopping. Cloud Run does exactly that, and it does it without asking you to run a cluster.
What separates a Cloud Run project that ages well from one that becomes somebody's problem is the boring layer: a reproducible build, an artifact you can point at, secrets that are not in the repo, a service account per service rather than one owner key, and a deploy you can undo. That is the layer we build.
- Scales to zero
- A service that only runs when it is called costs nothing overnight. For catalogue jobs and internal tools, that is most of the day.
- Identity per service
- Each service runs as its own IAM service account with only the permissions its job needs, so one compromised token is not a key to everything.
- A build you can trace
- Cloud Build produces a tagged image in Artifact Registry, so every running revision maps back to a commit rather than to somebody's laptop.
What the engagement covers
- Cloud Run services with containers, revisions and traffic control
- Cloud Build pipelines from a GitHub repository
- Artifact Registry for versioned, traceable images
- Secret Manager for credentials, wired into the runtime
- IAM roles and per-service runtime service accounts
- Cloud Storage buckets with uniform access, CORS and lifecycle rules
Technologies
- Google Cloud Run
- Cloud Build
- Artifact Registry
- Secret Manager
- IAM
- Cloud Storage
- Node.js
- Docker
Where this helps most
An API behind a storefront
A Node.js service your Shopify theme or app calls, that needs to be fast, cheap at idle and safe to deploy on a Friday.
Catalogue and file workloads
Imports, exports, image processing and document uploads that belong in object storage and a job, not in a web request.
Shared services across several stores
One backend serving more than one storefront, where per-store configuration and per-service identity both matter.
How we deliver
Shape the services
We decide what is one service and what is three, what needs state, and what can be a job rather than a permanently running process.
Build and registry
A Dockerfile, a Cloud Build trigger and an Artifact Registry repository, so a push becomes an image and an image becomes a revision.
Identity and secrets
Each service gets a service account and reads its configuration from Secret Manager. Nothing sensitive lives in the repository or in a deploy script.
Run it
Health checks, structured logs, revision-based rollback, and a written note of what each service is and who it talks to.
Google Cloud Development
Do we need Kubernetes?
Can Cloud Run talk to our database?
What does this cost to run?
Do you also migrate existing apps?
Ready to start with google cloud development?
Tell us about your store and your goals. We'll come back with a clear, honest plan and a transparent quote.