Skip to content
Search

Cloud Computing

lastmod 2025-12-11created 2015-01-1639 edits

Subfields of cloud computing

Cloud computing refers to internet-based (cloud) computing technology. It is a web-based software service in which programs are kept on utility data servers on the internet and loaded onto a computer, mobile phone, or other device whenever needed.

Software architecture

List of service providers

platform as a service

  • Vercel - Free Next.js hosting
  • Fly.io - Fast and easy container deployment
    • <del>3 free shared-cpu-1x VMs with 256MB RAM<del> - Ended
  • Netlify
  • Render - Free 100GB Bandwidth, can run Docker images
  • Koyeb
    • Supports Docker image build
    • Use a GitHub repository or a prebuilt container
    • APIs, full-stack web services, or workers
    • 3 regions worldwide
    • 20+ apps in one click
  • Heroku
  • Railway - https://railway.app/
    • Easy Deploy from a Github Repo
    • 512MB RAM / 1GB Disk free - Seems to have ended? Needs checking.

Container Registry

Managed Service Provider (MSP)

MSP stands for Managed Service Provider and refers to a cloud managed service company.

Cloud Service Provider (CSP)

Free bandwidth limits by service

Free bandwidth limits by service

  • Cloudflare Pages: Unlimited
  • GitHub Pages: 100GB soft
  • GitLab Pages: X,000 requests/min
  • Netlify: 100GB
  • AWS S3: 100GB

Issues when switching cloud services

An HN question asking about the reasons for and experiences of moving between clouds such as AWS, Azure, and Google, and the answers

  • Migrated my client's environment AWS → Google, and then Google → Hetzner, with zero downtime
    • The main reason was price. Moved to Hetzner after using up the free credits from AWS/Google
    • The cost saved by using the credits was 20 times the migration cost
    • The migration was done by connecting to the backends with a reverse proxy in each environment, setting up a VPN between the services, and then changing DNS
    • The trickiest part was database Failover, and making sure updates were retried after the master switchover
    • Through this, the client ended up with a cloud-provider-agnostic setup and made good use of the free credits they had
    • Technical details
      • Reverse proxies such as haproxy and nginx + Hashicorp Consul + ngx_mruby
      • Set up a VPN between the clouds so the reverse proxies can reach the backends on both sides
      • Replicate the database to the new cloud
      • Make it possible for the app to choose which database to use as the master (Consul)
      • Make the app handle database errors gracefully. This part is the trickiest
      • Set a low DNS TTL
      • Connect the new backends to the reverse proxies and check that there are no errors
      • Update DNS to add the new reverse proxies to the environment
      • Promote the replica in the new cloud to master
      • Drain connections on the old backends
      • Finally, remove the old reverse proxies from DNS
      • After verifying everything, remove the old environment and restore the DNS TTL
  • GitLab went from AWS to Azure and then to Google Cloud (a few years ago)
    • Like everyone, it started on AWS at first, but it cost a fortune (described as burning money)
    • YC members were offered Azure credits, and after doing the math it looked like about a year's worth of usage, so they moved
    • But the move was painful, and nobody was happy during the Azure period. On top of that, the free credits ran out fairly quickly.
    • Don't remember exactly why they moved to GCP, but it was a fairly difficult process that took quite a long time
    • The GCP experience was much better, but it can't be called perfect.
    • In particular, GCP tended to randomly terminate VMs for no clear reason
    • Sometimes they shut down cleanly, but other times they ended up in a kind of intermediate state, so other systems would try to connect and get connection timeouts instead of failing immediately
    • As I recall, it improved over time, but it felt very Google-like, as if saying "Something broke, but we can't tell you why."
    • In hindsight, if I started a company again, I would probably stick with something like Hetzner or another cheap bare-metal provider
    • Cloud services are great if you use them to the fullest, but 90% of the time you are just using them without the benefits and paying a lot
  • Google Cloud → Digital Ocean → OVH
    • Running our stuff on high-performance servers has fewer problems and is easier than expected
    • Deploying with git push and building containers is at a "Set it and forget it" level
    • We have terabytes of PostgreSQL data, which is enormously expensive on most clouds
    • Some people seem to think the cloud is like sliced bread, ready to eat, but it doesn't actually save developers time
    • The cloud is more expensive and much slower than running servers. For mid-sized workloads there is no advantage to using the cloud

Only the 3 most upvoted answers were picked. The answers above also have various follow-up questions, opinions, and counterargument comments, so check those too.

(Almost) every infrastructure decision I liked/regret after 4 years of running infrastructure at a startup

Every choice is marked as Endorse or Regret

Choosing AWS

  • AWS vs Google Cloud: Endorse choosing AWS. AWS focuses on its customers. Google Cloud feels like it relies on robots and automation.
  • EKS: Endorse using EKS. EKS offers deep integration with AWS services, and Kubernetes has caught up in many areas (such as integrating with Route53 using external-dns)
  • EKS managed add-ons: Regret using EKS managed add-ons. Needed to customize the installation, and operations were better after switching to helm charts

Databases and caching

  • RDS: Endorse using RDS. Data is the most important part of the infrastructure, and the cost of RDS is worth it
  • Redis ElastiCache: Endorse using Redis. Redis is very effective for caching and general use
  • ECR: Endorse moving from quay.io to ECR. ECR is more stable and has deeper permission integration

Networking and support

  • AWS VPN: Endorse using AWS VPN. The VPN is very simple to set up and understand. Okta is used to manage VPN access, and it gives a very good experience
  • AWS Premium Support: Regret. AWS Premium Support is very expensive and not worth it unless you lack in-house AWS knowledge
  • Control Tower Account Factory for Terraform: Endorse the AFT integration. Helps automate account creation and standardize tags

Process automation

  • Automating postmortems with a Slack bot: Endorse automating the postmortem process. Helps nudge people to write postmortems
  • Using PagerDuty incident templates: Endorse using templates when incidents occur. Some customization is possible by taking advantage of Notion's flexibility
  • Regular review of PagerDuty tickets: Endorse regularly reviewing alert settings. Ensures that even non-critical alerts are not ignored
  • Managing postmortems in Datadog or PagerDuty: Regret using an integrated management tool for postmortems. Both make it hard to customize the postmortem process. Using a powerful tool like Notion seems better

Other

  • Monthly cost tracking meeting: Endorse a monthly meeting to review SaaS costs. Check whether costs are reasonable and take action as needed. In AWS, items are grouped by tag and separated by account. Recommend not stopping at AWS but looking at all of the company's major sources of spending
  • Not using FaaS more: Regret not being able to use FaaS fully because there were no FaaS options for GPU workloads. Many CPU workloads could have been handled with FaaS. Another hidden benefit of Lambda is that it is very easy to track costs with high accuracy
  • GitOps: Endorse using GitOps. GitOps is used for much of the infrastructure, and investing in tool development helps understand the deployment state
  • Prioritizing team efficiency: Endorse prioritizing raising the team's efficiency. Have never regretted investing time in automation or documentation
  • Multiple applications sharing one database: Regret having multiple applications share one database. This caused several problems

SaaS adoption

  • Adopting an identity platform late: Used Google Workspace to assign permissions, but regret not adopting an identity solution like Okta sooner. Okta integrates well and solves security and compliance issues
  • Notion: Endorse using Notion for writing documentation. Notion was a great choice and works much more easily than what was used before (Wikis, Google Docs, Confluence, etc.). The database concept for organizing pages is useful
  • Slack: Endorse using Slack. Effective as the primary tool for communication

Development tools and services

  • Moving from JIRA to Linear: Endorse using Linear instead of JIRA. JIRA seems too complex and heavy
  • Not using Terraform Cloud: No regrets about not using it, since the cost of Terraform Cloud could not be justified. Moved to Atlantis and added the needed automation to the CI/CD pipeline
  • GitHub Actions for CI/CD: Somewhat endorse (Endorse-ish) using GitHub Actions. Marketplace actions and the syntax are easy to use. Sees limited support for self-hosted workflows as a drawback

Technology choices

  • Datadog: Regret using Datadog. Very expensive, and its cost model is a poor fit for Kubernetes clusters and AI companies
  • PagerDuty: Endorse using PagerDuty. The product is good and the price is reasonable
  • Schema migration by Diff: Somewhat endorse using a tool for schema migration. Data is important, and schema migrations can be risky
  • Ubuntu for dev servers: Endorse using Ubuntu for development servers. Well supported and has most of the packages needed
  • AppSmith: Endorse using AppSmith for process automation for internal engineers. Self-hosted, and satisfying enough. Initially looked at retool for deeper integration, but at the time could not justify the price for just a few integrations
  • helm: Endorse using Helm v3. There are problems with CRD deployment and developer training, but it is good enough for packaging and deploying Kubernetes objects
  • helm charts in ECR(oci): Endorse storing helm charts in an OCI repository. Fewer problems than the previous approach using S3 and a plugin
  • bazel: Unsure about bazel. Seems excessive for deploying Go services, and GitHub Actions is easier for more engineers to use
  • Not using OpenTelemetry: Regret sending metrics using the DataDog API directly. Recommend using OpenTelemetry from the start
  • Choosing renovatebot over dependencyabot: Regret not thinking sooner about keeping dependencies up to date. Renovatebot is customizable, but setup and debugging are complex
  • Kubernetes: Endorse using Kubernetes. A means of hosting long-running services is needed, and Kubernetes is popular and works well
  • Buying our own IPs: Endorse buying your own IP block when working with external partners. This helps give external partners a larger CIDR block to whitelist
  • Choosing Flux for k8s GitOps: No regrets about choosing Flux as the GitOps tool for Kubernetes. Developing tools to help understand the deployment state is necessary
  • Karpenter for node management: Endorse using Karpenter when using EKS. More reliable and cost-effective than other autoscalers
  • Using SealedSecrets: Regret using SealedSecrets. Complex for developers, and lost AWS's existing password rotation automation
  • Using ExternalSecrets: Endorse AWS -> Kubernetes password sync using ExternalSecrets. Easy for developers to understand, and passwords can easily be created/updated within AWS using terraform
  • Using ExternalDNS: Endorse using ExternalDNS. Syncs Kubernetes -> Route53 DNS entries and has had almost no problems over the last 4 years
  • Using cert-manager: Endorse using cert-manager for managing SSL certificates. Very intuitive and trouble-free for creating Let's Encrypt certificates
  • Bottlerocket for EKS: Regret running EKS clusters with Bottlerocket. Networking CSI problems occur frequently and are hard to debug
  • Choosing Terraform vs Cloudformation: Endorse using Terraform. Easy to extend to other SaaS providers, and has more readable syntax than CloudFormation
  • Not using a code-based IaC solution: No regrets. Terraform and CloudFormation use data files, whereas Pulumi and CDK describe infrastructure in code. The restrictive nature of Terraform's HCL helps reduce complexity
  • Not using a network mesh: No regrets. Network meshes are cool, but companies tend to underestimate their complexity. The general advice for infrastructure is "less is more"
  • Nginx load balancer for EKS ingress: No regrets. Endorse using Nginx. Old, but stable and proven technology
  • homebrew for company scripts: Endorse using homebrew to distribute company scripts. Good enough for distributing scripts and binaries to both Linux and Mac users
  • Go for services: Endorse using the Go language for services. Easy for new engineers to learn and a good choice overall

See also

Favorite site

References

  1. Oss_kr-CloudStack,Eucalyptus,OpenStack,vCloud.pdf ↩

author Zer0 sitemap