6 ms·

Been a while since I worked in cloud but at least when I got out of it, the primitives where all shoring up to be generally very similar. Did multi cloud redun

by neom 1y ago

Been a while since I worked in cloud but at least when I got out of it, the primitives where all shoring up to be generally very similar. Did multi cloud redundancy end up being too expensive? Tech didn't line up enough? No good business case? The elastic cloud story that never was? https://www.slideshare.net/slideshow/pets-vs-cattle-the-elastic-cloud-story/31735707 https://www.slideshare.net/slideshow/pets-vs-cattle-the-elas... What happened?

LaurensBER 1y ago
The (cognitive) overhead of managing and deploying to multiple clouds usually isn't worth it for most teams. Hiring experts and maintaining knowledge about the ins and outs of two (or more) clouds is less feasible for small, fast moving teams. Simplicity is linked to uptime and having a single cloud solution is a simpeler solution. For large companies, its mostly cost savings. Easier to negotiate a good discount at N million versus N/2 million. Besides that no-one ever got fired for picking AWS ;)
rubiquity 1y ago
Networking leaving the cloud provider (or even just to another zone on the same cloud) is $0.02 GB. That adds up real fast.
tadfisher 1y ago
Not a justifiable expense when no one else is resilient against their AWS region going down either. Also cross-cloud orchestration is quite dead because every provider is still 100% proprietary bullshit and the control plane is... kubernetes. We settled for kubernetes.
- morshu9001 1y ago
  Also if you can't even do cross region, cross cloud won't happen
  - dylan604 1y ago
    Cross region isn't simple when you have terabytes of storage in buckets in a region. Building services in other regions without that data doesn't really do any good. Maintaining instances in various regions is easy, but it's that data that complicates everything. If you need to use the instances in a different region because your main region is down, you still can't do anything because those cross region instances can't access the necessary data.
    - TZubiri 1y ago
      Bottomline is that AWS gives you the tools to survive this outage within their own ecosystem. If there's an issue with relying only on AWS it has not been expressed in this outage.
      - dylan604 1y ago
        exactly what tools helps make your large volume of data stored in a down region available to other regions without duplicating the monthly storage fees?
        morshu9001 1y ago
        You duplicate the fees. But it's the same or worse trying to do multi cloud.
        dylan604 1y ago
        Which is precisely why it's not done
        neom 1y ago
        I seems to recall it was fairly common to have a read only versions of sites when there was a major outage - we did that a lot with deviantart in the early 2000s, did that fall out of favour or too complex with modern stacks or?
Analemma_ 1y ago
All the cloud providers have cheap compute but ludicrously expensive network egress. Trying to multicloud will stick you with a massive traffic bill, which is probably not a coincidence.
- jamesblonde 1y ago
  It's a market regulation failure. Which results in a failed market, with the cloud infra provider also providing data services. 20 years ago, there were 20+ widely used operational databases. Now, it's like DynamoDB with like half the market.
  - conductr 1y ago
    How should this have played out in a regulated market? DynamoDB gets released, then what? Has limits on the market share it's allowed to steal? Should we similarly cap say Front End frameworks on market penetration / growth? Is react too big to fail? Do we need to force some of it's users to use something else?
  - jimbokun 1y ago
    What would these regulations say, exactly?
- starman55 1y ago
  It really depends on how you will built it. You can architect it for multi cloud from top down where the client/browser talk to one region, With DNS with health check, and replication happens at the DB layer. Your services don't talk cross region at service level, so avoiding a lot of cross region/cloud communication. Most use cases can be addressed this way.
sumtechguy 1y ago
Many companies idea of a disaster plan is to make it after the disaster. You have to build it in. That takes time money and training. Do you do failovers? Do they work? What is your backup situation? What is your list of work items to do during the failover? How long does it take? Do you even HAVE a failover plan? Can your services handle being in 'split brain'? Do you have specialty services that can only run in one place? The unfortunate reality is this planning happens many times too late.
dylan604 1y ago
If you're a company providing services to people that already have data stored in VendorA's cloud, being on a different cloud would be expensive and prevent you from winning much work. If it turns out that VendorA happens to be the vendor for your clients, you build your services to run on VendorA's cloud too. This is the situation for my company that started with the intent of being platform agnostic, but it quickly became much less complex as all of the potential client pool was using the same cloud. People with buckets with large amounts of data are not going to be able to convince the bean counters that it would be worth it to have that storage bill from multiple vendors.
- conductr 1y ago
  > are not going to be able to convince the bean counters that it would be worth it to have that storage bill from multiple vendors Because it rarely is. Occasional downtime is just a cost of doing business. It is, or should be, rare enough that you just take it as it comes instead of trying to have a redundancy. We don't build tunnels everywhere as a backup for surface roads on snowy days. We just cancel school and work for the day and make up for it later. Do some important things get impacted? Sure, but most things are as mission critical as we make them out to be. The press coverage of an AWS outage makes it so easy to shrug it off and point fingers.
TZubiri 1y ago
It feels like a hat on a hat, cloud systems are already designed for redundancy, adding a redundant layer on top of that is like a double condom, or invesisting in multiple investment funds.
toast0 1y ago
It seems that clouds balance their budget on egress charges... which leads to cross cloud communication being too expensive to setup multi cloud redundancy. Cross region redundancy is often too expensive too. Even cross availability zones is too expensive for some clouds and applications. (Cross region redundancy in a single cloud doesn't always work out, if the cloud has an outage on a global subsystem, or the broken subsystem gets pushed to multiple regions before exhibiting symptoms) Additionally, moving your load to a different cloud can be challenging while one is down. It ends up being a lot of work that pays off for a few hours a year. For a lot of applications, it's better to just suffer the downtime and spend money on other things.
justapassenger 1y ago
There’s a huge difference between “similar” and “works and is ROI positive for my business across the whole lifecycle”. Multi cloud redundancy is like Java being a solution to platform independency.

by neom 1y ago

LaurensBER 1y ago

The (cognitive) overhead of managing and deploying to multiple clouds usually isn't worth it for most teams. Hiring experts and maintaining knowledge about the ins and outs of two (or more) clouds is less feasible for small, fast moving teams. Simplicity is linked to uptime and having a single cloud solution is a simpeler solution. For large companies, its mostly cost savings. Easier to negotiate a good discount at N million versus N/2 million. Besides that no-one ever got fired for picking AWS ;)

rubiquity 1y ago

Networking leaving the cloud provider (or even just to another zone on the same cloud) is $0.02 GB. That adds up real fast.

tadfisher 1y ago

Not a justifiable expense when no one else is resilient against their AWS region going down either. Also cross-cloud orchestration is quite dead because every provider is still 100% proprietary bullshit and the control plane is... kubernetes. We settled for kubernetes.

morshu9001 1y ago
Also if you can't even do cross region, cross cloud won't happen
- dylan604 1y ago
  Cross region isn't simple when you have terabytes of storage in buckets in a region. Building services in other regions without that data doesn't really do any good. Maintaining instances in various regions is easy, but it's that data that complicates everything. If you need to use the instances in a different region because your main region is down, you still can't do anything because those cross region instances can't access the necessary data.
  - TZubiri 1y ago
    Bottomline is that AWS gives you the tools to survive this outage within their own ecosystem. If there's an issue with relying only on AWS it has not been expressed in this outage.
    - dylan604 1y ago
      exactly what tools helps make your large volume of data stored in a down region available to other regions without duplicating the monthly storage fees?
      - morshu9001 1y ago
        You duplicate the fees. But it's the same or worse trying to do multi cloud.
        dylan604 1y ago
        Which is precisely why it's not done
        neom 1y ago
        I seems to recall it was fairly common to have a read only versions of sites when there was a major outage - we did that a lot with deviantart in the early 2000s, did that fall out of favour or too complex with modern stacks or?

Analemma_ 1y ago

All the cloud providers have cheap compute but ludicrously expensive network egress. Trying to multicloud will stick you with a massive traffic bill, which is probably not a coincidence.

jamesblonde 1y ago
It's a market regulation failure. Which results in a failed market, with the cloud infra provider also providing data services. 20 years ago, there were 20+ widely used operational databases. Now, it's like DynamoDB with like half the market.
- conductr 1y ago
  How should this have played out in a regulated market? DynamoDB gets released, then what? Has limits on the market share it's allowed to steal? Should we similarly cap say Front End frameworks on market penetration / growth? Is react too big to fail? Do we need to force some of it's users to use something else?
- jimbokun 1y ago
  What would these regulations say, exactly?
starman55 1y ago
It really depends on how you will built it. You can architect it for multi cloud from top down where the client/browser talk to one region, With DNS with health check, and replication happens at the DB layer. Your services don't talk cross region at service level, so avoiding a lot of cross region/cloud communication. Most use cases can be addressed this way.

sumtechguy 1y ago

Many companies idea of a disaster plan is to make it after the disaster. You have to build it in. That takes time money and training. Do you do failovers? Do they work? What is your backup situation? What is your list of work items to do during the failover? How long does it take? Do you even HAVE a failover plan? Can your services handle being in 'split brain'? Do you have specialty services that can only run in one place? The unfortunate reality is this planning happens many times too late.

dylan604 1y ago

If you're a company providing services to people that already have data stored in VendorA's cloud, being on a different cloud would be expensive and prevent you from winning much work. If it turns out that VendorA happens to be the vendor for your clients, you build your services to run on VendorA's cloud too. This is the situation for my company that started with the intent of being platform agnostic, but it quickly became much less complex as all of the potential client pool was using the same cloud. People with buckets with large amounts of data are not going to be able to convince the bean counters that it would be worth it to have that storage bill from multiple vendors.

conductr 1y ago
> are not going to be able to convince the bean counters that it would be worth it to have that storage bill from multiple vendors Because it rarely is. Occasional downtime is just a cost of doing business. It is, or should be, rare enough that you just take it as it comes instead of trying to have a redundancy. We don't build tunnels everywhere as a backup for surface roads on snowy days. We just cancel school and work for the day and make up for it later. Do some important things get impacted? Sure, but most things are as mission critical as we make them out to be. The press coverage of an AWS outage makes it so easy to shrug it off and point fingers.

TZubiri 1y ago

It feels like a hat on a hat, cloud systems are already designed for redundancy, adding a redundant layer on top of that is like a double condom, or invesisting in multiple investment funds.

toast0 1y ago

It seems that clouds balance their budget on egress charges... which leads to cross cloud communication being too expensive to setup multi cloud redundancy. Cross region redundancy is often too expensive too. Even cross availability zones is too expensive for some clouds and applications. (Cross region redundancy in a single cloud doesn't always work out, if the cloud has an outage on a global subsystem, or the broken subsystem gets pushed to multiple regions before exhibiting symptoms) Additionally, moving your load to a different cloud can be challenging while one is down. It ends up being a lot of work that pays off for a few hours a year. For a lot of applications, it's better to just suffer the downtime and spend money on other things.

justapassenger 1y ago

There’s a huge difference between “similar” and “works and is ROI positive for my business across the whole lifecycle”. Multi cloud redundancy is like Java being a solution to platform independency.