Live data from Hacker News

Cloud services like AWS or Google Cloud Platform may be the wrong choice

karlsutt.com

181–190 of 210 posts

Re: Cloud services like AWS or Google Cloud Platform may be the wrong choice

#181

ITT: people who spent many hours learning proprietary (often unnecessarily complex) cloud platforms trying to convince others (and themselves) that it was the best use of their limited time alive. Stockholm syndrome à la Big Cloud. It's okay to be interested in elaborate cloud architecture things and learn them because of that, but don't sell it as one-size-fits-all thing that every little company needs. Most compani…

Exactly. Of course GCP/Azure/AWS have great development kits, of course they make it easy to get a Docker application running for the first time within 1 minute. That is the sales model.

However, to be cost effective, you need to adapt your application to be more cloud native using their propietary SDKs. Azure Functions/Lambdna, CosmosDB, Blob Storage/S3, etc. The application gets cheaper, but you've now also bought yourself into the ecosystem and you're never migrating anywhere else.

And now the pricing increases. Or the cloud provider decides you shouldn't be a client anymore. Too bad. No easy way back.

There is still not much wrong with a webapp on a VM. You still need sysops, except classic sysops instead of cloud certified sysops.

Re: Cloud services like AWS or Google Cloud Platform may be the wrong choice

#182

Earlier quoted context omitted.

> it lets you avoid up to about $50/month of digitalocean bills. Wish I'd know about this AWS free tier, because that sounds a lot like my monthly digital ocean bill :')

What are you running that costs $50/month? Several services with decent amounts of traffic?

The pattern that is free on AWS and costs a fair amount on digital ocean is one or two VPS-es (or equivalent serverless/kubernetes compute) plus a managed database instance. If you don't have the managed database, the AWS free tier is a lot less attractive.

Re: Cloud services like AWS or Google Cloud Platform may be the wrong choice

#183
post #150

Earlier quoted context omitted.

Yeah I can’t agree with you at all. Without setting up your own NAT Gateway on EC2 on a t2.micro instance (or something cheap like that), it runs you about $30. This isn’t even accounting for database costs, usage costs, development costs, etc. So right away that “I can’t believe they even charge my CC for $0.02” is real suspect. Do you have a completely empty AWS account? We haven’t even spoken about dev experience…

> Without setting up your own NAT Gateway on EC2 on a t2.micro instance... The problem is that you're using EC2 instead of AWS App Runner, Google Cloud Run, or Azure Container Apps. > We haven’t even spoken about dev experience yet. I'd strongly recommend that you give Google Cloud Run a try. You can go from empty codebase to running, on demand serverlesss runtime via GitHub with only a Dockerfile. I can build an app…

Where do you store your secrets? Persistent data? How do you handle authentication and authorization when using cloud run only?

Re: Cloud services like AWS or Google Cloud Platform may be the wrong choice

#184
> Terraform to create the IAM policies: 4 weeks

In Netflix more than 10 years ago, it's more like this: a single engineer builds a deployment/management tool: 1 - 2 months. Every other engineer creates a new and fully configured cluster: minutes.

Seriously, can we please get over the fetish of using anything this DSL that YAML or whatever "specification language"? Such tools are powerful, flexible, but should not have a place for engineers who just want to provision resources. The tools violate almost every UX principles, in particular the following:

- Discoverability. Very little. One has to read tons of docs and SO posts to figure out what needs to be done. You want to pass in some environment variables? A typical answer from those who use Nomad/TFE: easy, just pass in this 200 lines of Jinja template. Really? Really? You call this ease of freaking use?

- Affordance. None.

- Constraints. If you call the errors only after you submit your 1000-line yaml scripts.

- Consistency. Maybe, but still, embedding a Jinja template to pass in variable is an insult to UX.

It's a unrepentable sin to ask me to learn your shit.

Re: Cloud services like AWS or Google Cloud Platform may be the wrong choice

#185
post #49

Earlier quoted context omitted.

API gateway is simply how you expose Lambdas to an HTTP interface in AWS. It was the easiest way until they recently unveiled a way to expose the Lambda directly. You can also use ALBs (Application Load Balancers) and CloudFront to expose Lambdas to HTTP. Either way, Lambdas are hard to debug locally, often I just deploy them to test (since deploying is easy). Or I write my code such that it bootstraps differently wh…

But don’t try to create a REST API Gateway with more than 200 resources, or CloudFormation will randomly start failing. Or try to add more than 100 rules to your ALB, because it’ll be impossible. My biggest issue with AWS is that the limits are so arbitrary, and seem to solely exist due to terrible design decisions. If my local express server, or nginx can deal with 100 endpoints, how is it possible for this multi bi…

The 200 resources thing has been a really frustrating problem for us too. We've started migrating ours to separate API Gateways at a "service" level and then mapping paths to different APIs using the Custom Domain API Mappings.

Re: Cloud services like AWS or Google Cloud Platform may be the wrong choice

#186
post #114

Earlier quoted context omitted.

At small scale, you can lower your complexity using cloud. You don't need k8s for a small operation, just spin a couple of VMs and set them up via a few lines of Ansible. OTOH you can pick a managed datsbase: you just get a connection string to a Postgres with failover and backup already taken care of. Same with queue services, email services, etc. They have really simple APIs. You only need platform-specific knowled…

> You don't need k8s for a small operation, just spin a couple of VMs and set them up via a few lines of Ansible. You can replace "couple VMs" with a dedicated Hetzner/OVH/Kimsufi server, it'll be the same except you won't get ripped off on egress bandwidth and performance.

I agree that AWS egress bandwidth is a rip-off, but cloud != AWS only. Many cloud providers, from DO to Vultr, offer sane egress prices.

The cheapest dedicated server at Hetzner (an excellent provier indeed) is €44.39 / mo, while their cheapest VM option is €4.51 / mo, literally an order of magnitude less. If you don't need the power of a dedicated server for your small project (and even 10 small projects), you don't need to buy it.

You can't have a free dedicated server, but many small projects can run either entirely within free tiers of some cloud providers, or for pennies a month based on usage.

OTOH you of course can run such small projects from your desktop at home, or maybe even from your NAS or router if they are beefy enough, entirely under your control, and for free!

The key value prop of the cloud for me is elasticity. Say, our project spins up more nodes in anticipation of daily waves of traffic, and then spins them down to save cost when the load goes way down. This won't work so well with long-term dedicated servers.

Re: Cloud services like AWS or Google Cloud Platform may be the wrong choice

#187

This article is written in kind of a controversial way but it seems like the throughline of the argument is something like "use heroku until you have 100k users". This seems very reasonable to me. I thought it was going to be a pitch for on prem, which is also fine for certain scales. I think generally the scaling steps from startup to megacorp go: Heroku/Dokku > Public Cloud >Dedicated servers in someone else's DC >…

I don't think this is a good advice in general and I haven't seen many companies to do it practice. The initial decisions which a company makes most of the time are hard to change. Moving a successful business with clients from one platform to another 3 or 4 times is very difficult to do or hardly impossible.

It may work for a simple website, but for any more complicated project with web clients, mobile clients third party integrations, migrating from Heroku to cloud provider to on prem means refactoring big parts of the project.

What is even bigger problem a migration like this is hard to do incrementally.

Re: Cloud services like AWS or Google Cloud Platform may be the wrong choice

#188

This article is written in kind of a controversial way but it seems like the throughline of the argument is something like "use heroku until you have 100k users". This seems very reasonable to me. I thought it was going to be a pitch for on prem, which is also fine for certain scales. I think generally the scaling steps from startup to megacorp go: Heroku/Dokku > Public Cloud >Dedicated servers in someone else's DC >…

I don't see the point of public cloud. In practice, it still requires a sysadmin (now called "DevOps engineers") so it's not any better than rented bare-metal in terms of maintenance overhead, while still being extremely expensive. Use a managed PaaS to begin with (you pay more but it does genuinely save you time as there is no management overhead), then when you're ready to do things yourself go straight to hosted b…

> so it's not any better than rented bare-metal in terms of maintenance overhead

In my experience the maintenance overhead of the cloud is much lower. My dayjob (B2B SaaS) spent about 75% of the infrastructure team’s time on things like patching switch firmware, balancing UPS loads, diagnosing flaky switch ports or transceivers, managing logging growth, etc. None of that made our products better from a customer perspective.

Since our cloud move those same infra staff support many more services and apps with much faster turnaround for product teams. And we traded upcoming multi-million capex investments in servers/switches/appliances into a monthly cloud bill that scales much more closely with revenue.

The public cloud is for businesses constrained by people; we simply could not afford to hire enough people to do the same stuff on-prem or in colo.

Re: Cloud services like AWS or Google Cloud Platform may be the wrong choice

#189
post #170
post #105

Earlier quoted context omitted.

What happens if your server's hardware seriously breaks?

Then there are a few other physical servers with load balanced redundant VMs, and it fails over seamlessly. HAProxy makes this pretty easy to handle. But we almost never had any hardware issues, servers are pretty reliable.

Sounds pretty much like a... cloud? :-D

Actually I think that private cloud-like architecture (a bunch of physical servers with e.g. Dokku running on them) can be a good solution in some circumstances.

Re: Cloud services like AWS or Google Cloud Platform may be the wrong choice

#190
post #183

Earlier quoted context omitted.

> Without setting up your own NAT Gateway on EC2 on a t2.micro instance... The problem is that you're using EC2 instead of AWS App Runner, Google Cloud Run, or Azure Container Apps. > We haven’t even spoken about dev experience yet. I'd strongly recommend that you give Google Cloud Run a try. You can go from empty codebase to running, on demand serverlesss runtime via GitHub with only a Dockerfile. I can build an app…

Where do you store your secrets? Persistent data? How do you handle authentication and authorization when using cloud run only?

Authentication and authorization: I hand it off to Firebase identity management. But you can also just issue your own JWTs. You can run full applications in GCR like KeyCloak or IdentityServer. But the Firebase identity solution is really good.

Example here: https://github.com/CharlieDigital/dn6-firebase

Persistent data: Firestore (or Supabase, Planetscale, or CockroachDB if you want relational). On other platforms, I've used Azure CosmosDB which has a pay-as-you-go model which is practically free for hobby/POC use cases.

Secrets: depends on how secret it is; actual keys go into secrets manager in GCP which integrates with Cloud Run. Otherwise, you can configure it as an environment variable.

Post reply on HN