Cloud and releases · 4 min read
Cloud Run, Lambda, or Kubernetes: what does your app need?
Choose a place to run your app by looking at its jobs, data, and the team maintaining it. Questions to ask before committing to AWS, Google Cloud, or Kubernetes.
Your customer portal needs to load pages, save records, and send updates. That does not tell you where it should run yet. Start with what each part does, how long it takes, and what happens when it fails. Our recommendation is to choose a setup your team can maintain, then test the hardest part before moving the whole app.
What to take away
- Separate work that answers a customer right away from work that can finish later.
- An existing AWS or Google Cloud setup is a useful starting point, not a reason to skip checking fit.
- Include databases, support, and recovery in the decision, not just the price of running code.
List the jobs your app needs to do
Imagine a body shop portal where a customer uploads repair photos and later receives an estimate. The upload needs a quick response. Resizing photos and preparing a report can happen afterward. This is a planning example, not a client result.
Write down the busy periods, the largest upload, and how long the slowest job takes. Include the systems it must reach, such as an older estimating tool on a private network. Those details are more useful than choosing a platform because it sounds modern.
Consider Cloud Run for a container-based app on Google Cloud
A container packages an app with the software it needs to run. Cloud Run services handle HTTP requests, while Cloud Run jobs run tasks to completion. These give a team different ways to run the customer-facing part and the later batch work.
We would consider a Cloud Run service for an existing container-based web app or REST API, especially when the business already uses Google Cloud. Check its runtime requirements and connections before treating that as a decision.
Sources: Google Cloud: What is Cloud Run?
Consider Lambda for bounded work in AWS
API Gateway can pass an HTTP request to a Lambda function and return its response. A standard Lambda invocation has a maximum runtime of 15 minutes. A longer business process needs separate steps or a different place to run; it cannot simply ignore that limit.
For the repair-photo example, a small function could react to a new file or handle an API request. That is a candidate to test, not a claim that every image or report job fits. Measure the actual work and check the limits of the services around it too.
Sources: AWS: Invoke Lambda through API Gateway · AWS: Lambda quotas
Use Kubernetes when you can name the control you need
Kubernetes manages container workloads, including their deployment and scaling. It provides building blocks rather than a complete application platform. You still need choices for release workflows, logging, and monitoring.
We would consider it when a team already operates a cluster or has requirements that a simpler managed service cannot meet. Ask which requirement makes that extra setup worthwhile, who maintains it, and who responds when it fails. A small team should have a clear answer before taking it on.
Sources: Kubernetes: Overview
Decide where records live and how retries work
Hosting is only part of the plan. Name the database, file store, permissions, and backup process. In the portal example, one customer must never see another customer's photos. Test that rule directly.
AWS recommends handling duplicate events safely in Lambda code. Apply that question to the whole workflow: if a job runs again, will it create a second estimate or send the same update twice? We recommend keeping a durable record of completed work and testing a repeat before release.
Sources: AWS: Lambda best practices
Test one complete path before committing
Build the smallest useful trial: upload a sample photo, process it, save the result, and show it only to the right test user. Try a failed upload and a repeated job. Use made-up records.
Compare the effort to deploy, find an error, and recover with the team that will own the app. Estimate costs from expected use, including data storage, network traffic, and support. We would keep the decision in a short note with the alternatives and the reason for choosing one.
Keep this handy
Your pre-project checklist
- Which requests need an immediate response, and which jobs can finish later?
- How long does the slowest job take with realistic input?
- Where do customer records and files live?
- Which private systems or networks must the app reach?
- What happens if the same event arrives twice?
- Who handles releases, alerts, costs, and recovery?
- Can you prove the hardest path with a small trial?
Prefer to write it down? Tell us about your project. No portal account required.
These examples explain how we would approach the work. They are not client results. How we write our guides or send a correction.