Live data from Hacker News

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

karlsutt.com

151–160 of 210 posts

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

#151

> - Terraform to create the API gateway, database, lambdas, queues, Route 53 records: 1 week - Terraform to create the IAM policies: 4 weeks Perhaps it's because I am very familiar with the aforementioned tool and cloud but 5 weeks for writing those resources gives me the impresion of: 1. Lack of experience on AWS. 2. Lack of experience with Terraform. 3. Both. I don't want to sound arrogant by any means but a Terraf…

Agreed here. There is no reason setting up IAM policies through Terraform takes four weeks. Anecdotally, on my own personal projects it took me maybe three hours, or more, to set up IAM policies for AWS Lambda, ECS and RDS.

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

#152
Why do you need IAM policies at all to run a service that works on localhost on AWS? I would expect that you need IAM policies if your app integrates with the AWS platform, which it definitely wasn't doing on localhost, or if you are running multiple services in the same account and want to lock them down (e.g. not have services access each other's S3 buckets and such).

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

#153
post #81

I am currently in the middle of setting up AWS and that decision graph made me chuckle because it resonates quite deeply. I need to do GPU inference but I don't want to run the machine 24x7. I may use it for about 4 hours per day at best. Lambda doesn't offer GPUs and neither does ECS+Fargate. It seems like I could setup an endpoint using Sagemaker and then destroy it when no longer needed, and automate all of this b…

Depends on what "4 hours per day" really means. If you want an interactive endpoint, putting in the work to set up an ECS task you can start and stop feels like the best approach. If you have longer-running inference tasks and just want to pick up results asynchronously, Batch (which is a layer on top of ECS) seems like the way to go.

SageMaker might have an abstraction which is a closer fit for your particular use-case, but I'd be wary of potential cost excesses; running on raw EC2 and automating the lifetime somehow is inevitably going to be the cheapest route.

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

#154
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…

Interesting, I haven't had the experience with CloudFormation.

At that scale, however, I tend to group my Lambdas as microservices not per endpoint. It helps with cold start time as well. So for example, if I have a page" resource, I don't make that 5+ endpoints, I make it a wildcard / prefix match and do the routing inside of the service lambda.

Maybe you legitimately have 100+ different microservices, in which case, I don't doubt that is a problem, I just haven't experienced it.

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

#155
post #45

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 really agree with you, what's weird though is how many mega-corps are going away from Custom Hardware in Custom Built DC towards Cloud. There's also something to be said for buying a VPS or a Colo machine, making sure it's backed up and dealing with the 9's that you get from that machine on it's own. I am routinely surprised by how far a single node machine will get you.

Data Residency. Scaling to dozens of global regions is not cost effective for running your own DCs.

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

#156

Earlier quoted context omitted.

Google Cloud Run pricing is: - 2 million requests/mo free - First 180,000 vCPU seconds free - First 360,000 GiB seconds free Then: - $0.000024 /vCPU seconds - $0.0000025 /GiB seconds - $0.40 per million requests This will get you pretty far for $2/mo. Within the free tier itself, assuming you can process each request in 250ms on a 1 vCPU container, you get 720,000 requests before you start paying for compute usage. E…

The thing that holds me back from Google cloud run Is that it is difficult to replicate that exact environment locally for testing and dev. If you’re working with stateless apps then that’s fine, But what is the typical local workflow of developing against a database, task Queue, etc.?

If you're using an IaC tool like Terraform or Pulumi, you can just setup/tear down test resources on demand (for integration/acceptance tests). Under normal usage, hopefully you can get away with mocks/stubs/fakes. Some development frameworks make this a lot easier than others

Using real resources is usually fine for smaller applications but can be very problematic as your application grows. With that in mind, it's good to create boundaries so you limit the amount of "real infrastructure" you need to test/deploy. Reference https://martinfowler.com/bliki/IntegrationTest.html

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

#157
post #56
post #45

Earlier quoted context omitted.

I really agree with you, what's weird though is how many mega-corps are going away from Custom Hardware in Custom Built DC towards Cloud. There's also something to be said for buying a VPS or a Colo machine, making sure it's backed up and dealing with the 9's that you get from that machine on it's own. I am routinely surprised by how far a single node machine will get you.

> what's weird though is how many mega-corps are going away from Custom Hardware in Custom Built DC towards Cloud It costs a lot of money to run your own datacenters, and very very few companies are capable of doing it as good as AWS or even Scaleway/OVH can. By that I mean, waiting weeks/months to get through tickets, approvals, multiple different teams just to get a server deployed. Then waiting a few more weeks fo…

> It costs a lot of money to run your own datacenters,

If you actually do the math it is pretty much a wash vs using AWS. Yes you will pay a lot more upfront, but over a 5 year period (standard warranty length, and typical deprecation time) it pretty much evens out compared to AWS. I am sure there are many uses cases where on-prem would actually be cheaper than AWS over 5 years.

At the companies I work for the red-tape isn't nearly as bad as you make it seem (or have perhaps experienced at places you have worked). The biggest time sink right now is the ongoing supply chain issues and vendors just not having equipment, the approvals/tickets are pretty quick where I work.

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

#158

> - Terraform to create the API gateway, database, lambdas, queues, Route 53 records: 1 week - Terraform to create the IAM policies: 4 weeks Perhaps it's because I am very familiar with the aforementioned tool and cloud but 5 weeks for writing those resources gives me the impresion of: 1. Lack of experience on AWS. 2. Lack of experience with Terraform. 3. Both. I don't want to sound arrogant by any means but a Terraf…

Four days sounds fair if you're experienced. If you're new to TF/AWS I could easily see it taking significantly longer. If you assume IAM is the devil and refuse to learn it, it will absolutely take a while to get correct

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

#159
post #56
post #45

Earlier quoted context omitted.

I really agree with you, what's weird though is how many mega-corps are going away from Custom Hardware in Custom Built DC towards Cloud. There's also something to be said for buying a VPS or a Colo machine, making sure it's backed up and dealing with the 9's that you get from that machine on it's own. I am routinely surprised by how far a single node machine will get you.

> what's weird though is how many mega-corps are going away from Custom Hardware in Custom Built DC towards Cloud It costs a lot of money to run your own datacenters, and very very few companies are capable of doing it as good as AWS or even Scaleway/OVH can. By that I mean, waiting weeks/months to get through tickets, approvals, multiple different teams just to get a server deployed. Then waiting a few more weeks fo…

It also lets a CFO convert capex to opex (may or may not have tax implications), and you eliminate a cost center from your balance sheets (and turns it into service payments) which makes CFOs look better, even if it's net worse for the Company

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

#160
post #45

Earlier quoted context omitted.

I really agree with you, what's weird though is how many mega-corps are going away from Custom Hardware in Custom Built DC towards Cloud. There's also something to be said for buying a VPS or a Colo machine, making sure it's backed up and dealing with the 9's that you get from that machine on it's own. I am routinely surprised by how far a single node machine will get you.

Data Residency. Scaling to dozens of global regions is not cost effective for running your own DCs.

Sorry, the next step after cloud isn't running your own DC's.

It's renting space from someone who is doing that for you.

The scale of cost savings/ownership as you scale kinda goes:

FaaS -> PaaS -> Cloud -> VPS -> Rented Hardware -> Rented space in DC -> Own DC.

Let's avoid conflating everything left of VPS with the most difficult form of it, because nobody is going there from nothing.

Post reply on HN