4 ms·

Yes. If you use and manage AWS resources as you would your own on-prem resources then you're not going to have a good time. As soon as you think you need EC2 in

Yes. If you use and manage AWS resources as you would your own on-prem resources then you're not going to have a good time. As soon as you think you need EC2 instances you need to re-think your architecture. You're probably not using AWS most effectively.

shudza 4y ago
So what should you use for let say, a backend API service? Don't tell me beanstalk/fargate/etc, because they're actually more expensive.
- joshstrange 4y ago
  Lambda is an option, it's been a very attractive one for me.
  - jjav 4y ago
    AWS lambda is super cheap at tiny scale. But if you get into any real constant load, it is way more expensive than a VM. The other drawback of lambda is the flip side of having the server opaquely managed by AWS. It is so opaque you can't debug anything. At one startup we had a weird connectivity issue from lambda to RDS but it was impossible to diagnose given the lack of access so it went on for months. Had it been running in a VM, I could've diagnosed that within an hour with tcpdump and bpf et.al.
- 300bps 4y ago
  Lambda, SQS and SNS. That’s how just about everyone does backend API services with AWS. You’ll be shocked at how cheap, scalable and bullet-proof it can be.
  - cj 4y ago
    Until you reach scale, and then you’ll typically end up migrating off of those services onto EC2 where a $10k/yr machine can process many orders of magnitude more requests for the same price. Lambda, etc, just doesn’t scale well financially if you’re doing millions of requests per day.
    - taylodl 4y ago
      Then as the OP said, AWS isn't for you if you have a constant 24/7 compute load. In my case the load is very bursty. I sometimes do millions of requests per day, but I typically don't. We lowered our TCO by 75% by moving from on-prem to AWS and using Lambda. It really comes down to your compute load profile.
  - PetahNZ 4y ago
    Unless your app is doing a lot of compute. We tried moving our workers to lambda, it was 10x the cost vs an EC2 auto scaling group
  - icedchai 4y ago
    The Lambda "developer experience" is mediocre at best. Performance is often highly variable. And when you reach a certain point, you'll get much better bang for the buck with EC2. Everything can be cheap when you have very little traffic.
ryanisnan 4y ago
Using Karpenter for AWS has been a game changer. Set your instance family designations, set up a compute savings plan, and let it ride.
macinjosh 4y ago
What I don't understand is why anyone would spend, precious and expensive engineering resources on coding to a proprietary API owned by one of the largest companies on the planet to whom you are nothing. Ok so you save money on the monthly bill but what happens when Amazon decides they want to enter your market? What happens if they decide your service is too controversial and they kick you off? If you were deploying your own services to EC2 instead of using AWS's own services you could at least setup shop elsewhere with just a bit of work. To me it is antithetical to building a sustainable product. People just hoping their startup gets bought and then it is someone else's problem.
- pooper 4y ago
  > To me it is antithetical to building a sustainable product. Continuing what you said, Google uses macOS and Windows for client machines. That is ok because if Apple or Microsoft were to decide to cut off Google altogether, Google would have bigger problems. However, I think from a business point of view, this is similar to how so many businesses use cloudinary. Cloudinary is a software as a service company that provides cloud based image and video management services. What if cloudinary kicks you out? There is a lot of custom code out there to interface with cloudinary API. Where do we draw the line between using Cloudinary is ok but Amazon aws lambda is not?
  - macinjosh 4y ago
    I can't find the quote, but I think it was Joel Spolsky on an old stackoverflow podcast with Jeff Atwood. They were discussing why stackoverflow built their own servers and did not use cloud or other hosting. He said something like companies should fully own and control their product and any direct dependencies thereof. If you think of it as a concentric set of rings you at least want to have full control over your ring and the ring below it. In the terms of a web app it meant the code for your application and the hardware it runs on. To me that seems reasonable.
    - RussianCow 4y ago
      That doesn't sound reasonable at all to me. Unless you are building your own cloud service or doing something out of the ordinary (for which cloud wouldn't be a good fit anyway), the hardware you run on has absolutely nothing to do with your business. Take the shortest/cheapest path and move on. To be fair to the Stack Overflow guys, AWS had fewer offerings when SO was built, so the comparison wasn't the same then as it is now.
MajimasEyepatch 4y ago
I think that statement about EC2 is a little too strong. You definitely shouldn't be managing individual EC2 instances in most cases, and you probably shouldn't be deploying directly to EC2. But if you're running EKS (Kubernetes) or ECS (non-k8s containers), then you're probably going to get more bang for your buck with EC2 nodes than Fargate nodes, especially if you have a large cluster.
- taylodl 4y ago
  That's a good distinction. Maybe instead of saying avoid EC2 what we should be saying is try to utilize AWS' managed services whenever possible.
  - MajimasEyepatch 4y ago
    Yup, that's generally true. Otherwise, you really might not be better off with AWS.

shudza 4y ago

So what should you use for let say, a backend API service? Don't tell me beanstalk/fargate/etc, because they're actually more expensive.

joshstrange 4y ago
Lambda is an option, it's been a very attractive one for me.
- jjav 4y ago
  AWS lambda is super cheap at tiny scale. But if you get into any real constant load, it is way more expensive than a VM. The other drawback of lambda is the flip side of having the server opaquely managed by AWS. It is so opaque you can't debug anything. At one startup we had a weird connectivity issue from lambda to RDS but it was impossible to diagnose given the lack of access so it went on for months. Had it been running in a VM, I could've diagnosed that within an hour with tcpdump and bpf et.al.
300bps 4y ago
Lambda, SQS and SNS. That’s how just about everyone does backend API services with AWS. You’ll be shocked at how cheap, scalable and bullet-proof it can be.
- cj 4y ago
  Until you reach scale, and then you’ll typically end up migrating off of those services onto EC2 where a $10k/yr machine can process many orders of magnitude more requests for the same price. Lambda, etc, just doesn’t scale well financially if you’re doing millions of requests per day.
  - taylodl 4y ago
    Then as the OP said, AWS isn't for you if you have a constant 24/7 compute load. In my case the load is very bursty. I sometimes do millions of requests per day, but I typically don't. We lowered our TCO by 75% by moving from on-prem to AWS and using Lambda. It really comes down to your compute load profile.
- PetahNZ 4y ago
  Unless your app is doing a lot of compute. We tried moving our workers to lambda, it was 10x the cost vs an EC2 auto scaling group
- icedchai 4y ago
  The Lambda "developer experience" is mediocre at best. Performance is often highly variable. And when you reach a certain point, you'll get much better bang for the buck with EC2. Everything can be cheap when you have very little traffic.

ryanisnan 4y ago

Using Karpenter for AWS has been a game changer. Set your instance family designations, set up a compute savings plan, and let it ride.

macinjosh 4y ago

What I don't understand is why anyone would spend, precious and expensive engineering resources on coding to a proprietary API owned by one of the largest companies on the planet to whom you are nothing. Ok so you save money on the monthly bill but what happens when Amazon decides they want to enter your market? What happens if they decide your service is too controversial and they kick you off? If you were deploying your own services to EC2 instead of using AWS's own services you could at least setup shop elsewhere with just a bit of work. To me it is antithetical to building a sustainable product. People just hoping their startup gets bought and then it is someone else's problem.

pooper 4y ago
> To me it is antithetical to building a sustainable product. Continuing what you said, Google uses macOS and Windows for client machines. That is ok because if Apple or Microsoft were to decide to cut off Google altogether, Google would have bigger problems. However, I think from a business point of view, this is similar to how so many businesses use cloudinary. Cloudinary is a software as a service company that provides cloud based image and video management services. What if cloudinary kicks you out? There is a lot of custom code out there to interface with cloudinary API. Where do we draw the line between using Cloudinary is ok but Amazon aws lambda is not?
- macinjosh 4y ago
  I can't find the quote, but I think it was Joel Spolsky on an old stackoverflow podcast with Jeff Atwood. They were discussing why stackoverflow built their own servers and did not use cloud or other hosting. He said something like companies should fully own and control their product and any direct dependencies thereof. If you think of it as a concentric set of rings you at least want to have full control over your ring and the ring below it. In the terms of a web app it meant the code for your application and the hardware it runs on. To me that seems reasonable.
  - RussianCow 4y ago
    That doesn't sound reasonable at all to me. Unless you are building your own cloud service or doing something out of the ordinary (for which cloud wouldn't be a good fit anyway), the hardware you run on has absolutely nothing to do with your business. Take the shortest/cheapest path and move on. To be fair to the Stack Overflow guys, AWS had fewer offerings when SO was built, so the comparison wasn't the same then as it is now.

MajimasEyepatch 4y ago

I think that statement about EC2 is a little too strong. You definitely shouldn't be managing individual EC2 instances in most cases, and you probably shouldn't be deploying directly to EC2. But if you're running EKS (Kubernetes) or ECS (non-k8s containers), then you're probably going to get more bang for your buck with EC2 nodes than Fargate nodes, especially if you have a large cluster.

taylodl 4y ago
That's a good distinction. Maybe instead of saying avoid EC2 what we should be saying is try to utilize AWS' managed services whenever possible.
- MajimasEyepatch 4y ago
  Yup, that's generally true. Otherwise, you really might not be better off with AWS.