4 ms·

There's always a cheaper way to do something, but it's important to remember that 'lower price' often doesn't mean 'lower cost'. In order to get the lower price

There's always a cheaper way to do something, but it's important to remember that 'lower price' often doesn't mean 'lower cost'. In order to get the lower price you need to spend on whatever the alternative option isn't doing in order to give that price saving. For example, moving from AWS to onprem means you need to configure the infrastructure yourself; you save on AWS fees but you spend more on devops. And then you have to factor in things like the cost of downtime (on both sides of the equation, especially if you use us-east-1), the price of building your own services, the price of software you need to buy, and so on. You only save money if the differential cost based on all the factors is lower. AWS is expensive for some things so it often does save some money, but not always, and if you haven't done a proper analysis you can't know.

username_my1 3y ago
usually you're right but the cost mentioned here is specific to BLOB data storage ... a very specific problem that can be isolated and run on external services and save the company lots of money.
- CogitoCogito 3y ago
  ^^^ The cloud vs. on-prem argument often seems to ignore the (enormous) middle-ground. Just because one portion of your architecture would do well to be run outside the cloud, doesn't mean you take out all the other parts you don't want to deal with yourself. Furthmore, "on-prem" might mean in your building, in someone else's building co-located and you rent space and control it, or in someone else's building where they deal with most hardware, etc. That said, maybe Canva has considered a non-AWS solution and decided against it. Or maybe they've gotten certain better deals from AWS. We can't really know for sure on the outside.
  - maccard 3y ago
    My team uses AWS for _everything_. There's three reasons for this on our team (and I've researched it for our use cases. - Consistency. Instead of saying "Oh look in AWS for this app, Azure for this one, and hetzner for this app, except it's test env is in AWS", it all just lives in AWS. It massively simplifies docs, onboarding, and reduces the amount of one-person specialised knowledge. - Engineering Costs. Similar to above, but in terms of engineering, there's less to know and understand. Instead of needing to know how the AWS load balancer routes/connects to a VM somewhere else, and how that VM gets it's blob-storage-data from azure, we only need to understand AWS concepts. - Vendor Lock In. Yeah, it's there. If we have a service that uses data from S3, there's egress costs from S3 to <other provider>, but not with EC2. We've consciously accepted this lock in for the time being. Now, we're a 50 person company so YMMV, but the above tradeoffs plus an "opinionated" setup in AWS (everything on ECS, logging to Cloudwatch, RDS for DB) drastically reduced the "ops" overhead on our side after the initial setup. If I started over, I'd make the same decisions again.
    - CogitoCogito 3y ago
      > My team uses AWS for _everything_...If I started over, I'd make the same decisions again. Okay? I never said that sticking to a single cloud provider isn't appropriate for some (or maybe even most) people. It's good that you have a setup that you believe works well for you.
    - martinald 3y ago
      But you're missing the point above. S3 is probably the easiest service to replace - there are loads of providers which use the _exact_ same protocol as S3. It's a drop in replacement. It literally uses AWS concepts, there is nothing else to learn apart from putting a different url into your application. Very few people should really be using S3 at any serious scale is my thoughts. The cost savings are enormous (plus cloudflare for example replicates your data a lot closer to users for no extra cost, significantly improving performance). The cost savings can be absolutely enormous for very little/no additional complexity given how many providers are compatible with S3, and the fairly 'boring' nature of S3 compared to other technologies.
      - tough 3y ago
        People really have to be afraid of running VPS or whatever if they can't spun up a min.io instance to have their own S3 without dealing with Amazon's Bullshit
        vasco 3y ago
        How big of a production deployment have you ran on min.io in terms of data transfer / month and total storage? Because I've done small scale and can tell you I'd run S3 in the future.
        tough 3y ago
        Point taken as I haven't used it in prod properly, I'll cross that bridge when I find it but Id rather keep my money and put some time into making it work. There's also cloudflare R2 now if S3 is too expensive but self-hosted is out of the question
PaywallBuster 3y ago
or just consider different providers and easily lower costs by 50% depending on balance storage/bandwidth
andrewstuart 3y ago
>> moving from AWS to onprem means you need to configure the infrastructure yourself; you save on AWS fees but you spend more on devops This is the traditional “sell” for cloud computing and I don’t buy it at all. The clouds would have you believe it doesn't make sense to run your own systems because you need too much specialist expertise to run your own systems. The clouds sales pitch is the if you go cloud then you don’t need all these specialists. That’s rubbish. Cloud operations need the same or more headcount if technical specialists, they’re just doing different things. The old “don’t run your own systems, it’s cheaper and easier to go cloud” is just sales fiction. Don’t believe it.
- onion2k 3y ago
  Don’t believe it. You don't need to 'believe'. You need to do an analysis of what you need and how much each option will cost. Then you can know. If your argument is "I believe onprem saves money" or "I bet AWS is cheaper" or "Jim Morrison came to me in a dream and said I should use Azure" then you haven't done enough research.
  - chii 3y ago
    > you haven't done enough research. the research isn't free either. The more indepth and time it takes to do such research, the slower you come to a decision and ship. Cloud allows you to ship fast. It allows you to go without research - just accept the marketing, and pay up. You pay above-cost (compared to on-prem) when you grow to a certain size. But this is usually a worthy trade off tbh.
    - willcipriano 3y ago
      It's a good way to bypass legacy IT teams. A onprem server will have a bunch of snake oil endpoint protection products running on the box, bespoke config changes and take a couple months to get up and running, a ECS container is up and running in minutes and has whatever you shipped in the container without all the commentary from the peanut gallery.
deleted 3y ago
[deleted]
amluto 3y ago
> And then you have to factor in things like the cost of downtime (on both sides of the equation, especially if you use us-east-1) This is an important factor to remember when evaluating could costs. If you want to survive a cloud outage, you need a multi-AZ or multi-region deployment, and that costs developer hours. And you need to deal with the potentially catastrophic cost of inter-AZ or inter-region traffic, which can be catastrophic and/or cost more developer hours to mitigate.
- mschuster91 3y ago
  > If you want to survive a cloud outage, you need a multi-AZ or multi-region deployment, and that costs developer hours. RDS databases are one click to set up in multi-AZ, and if your stack is Kubernetes based or at least EC2 autoscale capable it isn't much more work to make it multi-AZ as well. Multi-Region deployments however, these are indeed expensive and nasty to set up.

username_my1 3y ago

usually you're right but the cost mentioned here is specific to BLOB data storage ... a very specific problem that can be isolated and run on external services and save the company lots of money.

CogitoCogito 3y ago
^^^ The cloud vs. on-prem argument often seems to ignore the (enormous) middle-ground. Just because one portion of your architecture would do well to be run outside the cloud, doesn't mean you take out all the other parts you don't want to deal with yourself. Furthmore, "on-prem" might mean in your building, in someone else's building co-located and you rent space and control it, or in someone else's building where they deal with most hardware, etc. That said, maybe Canva has considered a non-AWS solution and decided against it. Or maybe they've gotten certain better deals from AWS. We can't really know for sure on the outside.
- maccard 3y ago
  My team uses AWS for _everything_. There's three reasons for this on our team (and I've researched it for our use cases. - Consistency. Instead of saying "Oh look in AWS for this app, Azure for this one, and hetzner for this app, except it's test env is in AWS", it all just lives in AWS. It massively simplifies docs, onboarding, and reduces the amount of one-person specialised knowledge. - Engineering Costs. Similar to above, but in terms of engineering, there's less to know and understand. Instead of needing to know how the AWS load balancer routes/connects to a VM somewhere else, and how that VM gets it's blob-storage-data from azure, we only need to understand AWS concepts. - Vendor Lock In. Yeah, it's there. If we have a service that uses data from S3, there's egress costs from S3 to <other provider>, but not with EC2. We've consciously accepted this lock in for the time being. Now, we're a 50 person company so YMMV, but the above tradeoffs plus an "opinionated" setup in AWS (everything on ECS, logging to Cloudwatch, RDS for DB) drastically reduced the "ops" overhead on our side after the initial setup. If I started over, I'd make the same decisions again.
  - CogitoCogito 3y ago
    > My team uses AWS for _everything_...If I started over, I'd make the same decisions again. Okay? I never said that sticking to a single cloud provider isn't appropriate for some (or maybe even most) people. It's good that you have a setup that you believe works well for you.
  - martinald 3y ago
    But you're missing the point above. S3 is probably the easiest service to replace - there are loads of providers which use the _exact_ same protocol as S3. It's a drop in replacement. It literally uses AWS concepts, there is nothing else to learn apart from putting a different url into your application. Very few people should really be using S3 at any serious scale is my thoughts. The cost savings are enormous (plus cloudflare for example replicates your data a lot closer to users for no extra cost, significantly improving performance). The cost savings can be absolutely enormous for very little/no additional complexity given how many providers are compatible with S3, and the fairly 'boring' nature of S3 compared to other technologies.
    - tough 3y ago
      People really have to be afraid of running VPS or whatever if they can't spun up a min.io instance to have their own S3 without dealing with Amazon's Bullshit
      - vasco 3y ago
        How big of a production deployment have you ran on min.io in terms of data transfer / month and total storage? Because I've done small scale and can tell you I'd run S3 in the future.
        tough 3y ago
        Point taken as I haven't used it in prod properly, I'll cross that bridge when I find it but Id rather keep my money and put some time into making it work. There's also cloudflare R2 now if S3 is too expensive but self-hosted is out of the question

PaywallBuster 3y ago

or just consider different providers and easily lower costs by 50% depending on balance storage/bandwidth

andrewstuart 3y ago

>> moving from AWS to onprem means you need to configure the infrastructure yourself; you save on AWS fees but you spend more on devops This is the traditional “sell” for cloud computing and I don’t buy it at all. The clouds would have you believe it doesn't make sense to run your own systems because you need too much specialist expertise to run your own systems. The clouds sales pitch is the if you go cloud then you don’t need all these specialists. That’s rubbish. Cloud operations need the same or more headcount if technical specialists, they’re just doing different things. The old “don’t run your own systems, it’s cheaper and easier to go cloud” is just sales fiction. Don’t believe it.

onion2k 3y ago
Don’t believe it. You don't need to 'believe'. You need to do an analysis of what you need and how much each option will cost. Then you can know. If your argument is "I believe onprem saves money" or "I bet AWS is cheaper" or "Jim Morrison came to me in a dream and said I should use Azure" then you haven't done enough research.
- chii 3y ago
  > you haven't done enough research. the research isn't free either. The more indepth and time it takes to do such research, the slower you come to a decision and ship. Cloud allows you to ship fast. It allows you to go without research - just accept the marketing, and pay up. You pay above-cost (compared to on-prem) when you grow to a certain size. But this is usually a worthy trade off tbh.
  - willcipriano 3y ago
    It's a good way to bypass legacy IT teams. A onprem server will have a bunch of snake oil endpoint protection products running on the box, bespoke config changes and take a couple months to get up and running, a ECS container is up and running in minutes and has whatever you shipped in the container without all the commentary from the peanut gallery.

deleted 3y ago

[deleted]

amluto 3y ago

> And then you have to factor in things like the cost of downtime (on both sides of the equation, especially if you use us-east-1) This is an important factor to remember when evaluating could costs. If you want to survive a cloud outage, you need a multi-AZ or multi-region deployment, and that costs developer hours. And you need to deal with the potentially catastrophic cost of inter-AZ or inter-region traffic, which can be catastrophic and/or cost more developer hours to mitigate.

mschuster91 3y ago
> If you want to survive a cloud outage, you need a multi-AZ or multi-region deployment, and that costs developer hours. RDS databases are one click to set up in multi-AZ, and if your stack is Kubernetes based or at least EC2 autoscale capable it isn't much more work to make it multi-AZ as well. Multi-Region deployments however, these are indeed expensive and nasty to set up.