5 ms·

"If you can afford it" There's a degree of complexity that comes with multi-cloud that's ill-suited for most early stage companies. Especially in the age of "

"If you can afford it" There's a degree of complexity that comes with multi-cloud that's ill-suited for most early stage companies. Especially in the age of "serverless" that has folks thinking they don't need people to worry about infrastructure. My point is that the calculus has more to it than just money. The prudent response, of course, is to do as you described. Have a plan for your provider to go away. Offsite backups and the necessary config management to bring up similar infra in another region/provider is likely sufficient for most.

jchanimal 8y ago
It's hard to get a fully multi-cloud response in a simple stack. I describe one option for a simple multi-cloud stack in this blog post: https://blog.fauna.com/survive-cloud-vendor-crashes-with-netlify-and-faunadb https://blog.fauna.com/survive-cloud-vendor-crashes-with-net...
- mmt 8y ago
  For an early startup, though, I would think it's not necessary to be "fully" multi-cloud. Rather, it would likely be enough to have a cloud-agnostic infrastructure with replication to a warm (or even mostly-cold to save on cost) standby at the alternate provider with a manual failover mechanism.
  - halbritt 8y ago
    Most folks overestimate their need for availability and lack a willingness to accept risk. There are distinct benefits that come with avoiding "HA" setups. Namely simplicity and speed.
    - mmt 8y ago
      > Most folks overestimate their need for availability and lack a willingness to accept risk. I disagree. More specifically, I think, instead, many [1] folks just don't make that assessment/estimate in the first place. They just follow what they perceive to be industry best practices. In many ways, this is more about social proof than a cargo cult, even though the results can resemble the latter, such as elsewhere in this thread with a comment complaining they had a "resilient" setup in a single cloud that was shut down by the provider. > There are distinct benefits that come with avoiding "HA" setups. Namely simplicity and speed. Indeed, and, perhaps more importantly, being possible at all, given time ("speed") and money ("if you can afford it"). The same could be said of "scalability" setups, which can overlap in functionality (though I would argue that in cases of overlap the dual functionality makes the cost more likely to be worth it). None of this is to say, though that "HA" is synonymous with "business continuity". It's much like the conceptual difference between RAID and backups, and even that's not always well understood. [1] I won't go so far as to say "most" because that would be a made up statistic on my part
      - halbritt 8y ago
        Agreed for the most part. Availability for very many is a binary operation. They either do none of it or all of it. A clever man once said, "you own your availability". An exercise in BC planning can really pay off. If infra is code, and it and the data are backed up reasonably well, then a good MTTR can obviate the need for a lot of HA complexity.
        mmt 8y ago
        > Availability for very many is a binary operation. They either do none of it or all of it. I assume I'm missing some meaning here, particularly since the premise of much of the discussion in the thread is that there can be high availability at one layer, but it can rendered irrelevant by a SPoF at another (especially when the "layer" is the provider of all of ones infrastructure). Do you consider that a version of "none"? Or are you pointing out that, despite the middle ground under discussion, the "binary" approach is more common, if not more sensible?
        halbritt 8y ago
        The binary approach is that it either isn't considered or people opt in for all of it without consideration for what is actually needed. The Google SRE book goes into this at length. For each service, they define SLOs and make a considered decision about how to meet them.
        mmt 8y ago
        Oh, so what you're saying is that they're no considering the notion that there may be a medium-availability (for lack of a better term) solution, which could be perfectly adequate/appropriate?
olefoo 8y ago
> There's a degree of complexity that comes with multi-cloud that's ill-suited for most early stage companies. Especially in the age of "serverless" that has folks thinking they don't need people to worry about infrastructure. I just heard a dozen founders sit up and think "Market Opportunity" in glowing letters. CockroachDB has a strong offering. But multi-cloud need not be complicated in implementation. A few ansible scripts and some fancy footwork with static filesystem synchronization and you too can be moving services from place to place with a clear chain of data custody.
- halbritt 8y ago
  A few ansible scripts? Nah. Everything I have runs in kubernetes. The only difficulty I have to deal with is figuring out how to deploy a kubernetes cluster in each provider. From there, I write a single piece of orchestration that will drop my app stack in any cloud provider. I'm using a custom piece of software and event-driving automation to handle the creation and migration of services. Migrating data across providers is hard as kubernetes doesn't have snapshots yet. There are already a lot of startups in this space doing exactly the kind of thing that I just described. Most aim to provide a CD platform for k8s.
mmt 8y ago
> There's a degree of complexity that comes with multi-cloud that's ill-suited for most early stage companies. Especially in the age of "serverless" that has folks thinking they don't need people to worry about infrastructure. Perhaps we'll start seeing a new crop of post-mortems from the "fail fast" type of startups failing due to cloud over-dependency issues. They're (presumably rare) edge cases, but easily fatal to an early enough startup.

jchanimal 8y ago

It's hard to get a fully multi-cloud response in a simple stack. I describe one option for a simple multi-cloud stack in this blog post: https://blog.fauna.com/survive-cloud-vendor-crashes-with-netlify-and-faunadb https://blog.fauna.com/survive-cloud-vendor-crashes-with-net...

mmt 8y ago
For an early startup, though, I would think it's not necessary to be "fully" multi-cloud. Rather, it would likely be enough to have a cloud-agnostic infrastructure with replication to a warm (or even mostly-cold to save on cost) standby at the alternate provider with a manual failover mechanism.
- halbritt 8y ago
  Most folks overestimate their need for availability and lack a willingness to accept risk. There are distinct benefits that come with avoiding "HA" setups. Namely simplicity and speed.
  - mmt 8y ago
    > Most folks overestimate their need for availability and lack a willingness to accept risk. I disagree. More specifically, I think, instead, many [1] folks just don't make that assessment/estimate in the first place. They just follow what they perceive to be industry best practices. In many ways, this is more about social proof than a cargo cult, even though the results can resemble the latter, such as elsewhere in this thread with a comment complaining they had a "resilient" setup in a single cloud that was shut down by the provider. > There are distinct benefits that come with avoiding "HA" setups. Namely simplicity and speed. Indeed, and, perhaps more importantly, being possible at all, given time ("speed") and money ("if you can afford it"). The same could be said of "scalability" setups, which can overlap in functionality (though I would argue that in cases of overlap the dual functionality makes the cost more likely to be worth it). None of this is to say, though that "HA" is synonymous with "business continuity". It's much like the conceptual difference between RAID and backups, and even that's not always well understood. [1] I won't go so far as to say "most" because that would be a made up statistic on my part
    - halbritt 8y ago
      Agreed for the most part. Availability for very many is a binary operation. They either do none of it or all of it. A clever man once said, "you own your availability". An exercise in BC planning can really pay off. If infra is code, and it and the data are backed up reasonably well, then a good MTTR can obviate the need for a lot of HA complexity.
      - mmt 8y ago
        > Availability for very many is a binary operation. They either do none of it or all of it. I assume I'm missing some meaning here, particularly since the premise of much of the discussion in the thread is that there can be high availability at one layer, but it can rendered irrelevant by a SPoF at another (especially when the "layer" is the provider of all of ones infrastructure). Do you consider that a version of "none"? Or are you pointing out that, despite the middle ground under discussion, the "binary" approach is more common, if not more sensible?
        halbritt 8y ago
        The binary approach is that it either isn't considered or people opt in for all of it without consideration for what is actually needed. The Google SRE book goes into this at length. For each service, they define SLOs and make a considered decision about how to meet them.
        mmt 8y ago
        Oh, so what you're saying is that they're no considering the notion that there may be a medium-availability (for lack of a better term) solution, which could be perfectly adequate/appropriate?

olefoo 8y ago

> There's a degree of complexity that comes with multi-cloud that's ill-suited for most early stage companies. Especially in the age of "serverless" that has folks thinking they don't need people to worry about infrastructure. I just heard a dozen founders sit up and think "Market Opportunity" in glowing letters. CockroachDB has a strong offering. But multi-cloud need not be complicated in implementation. A few ansible scripts and some fancy footwork with static filesystem synchronization and you too can be moving services from place to place with a clear chain of data custody.

halbritt 8y ago
A few ansible scripts? Nah. Everything I have runs in kubernetes. The only difficulty I have to deal with is figuring out how to deploy a kubernetes cluster in each provider. From there, I write a single piece of orchestration that will drop my app stack in any cloud provider. I'm using a custom piece of software and event-driving automation to handle the creation and migration of services. Migrating data across providers is hard as kubernetes doesn't have snapshots yet. There are already a lot of startups in this space doing exactly the kind of thing that I just described. Most aim to provide a CD platform for k8s.

mmt 8y ago

> There's a degree of complexity that comes with multi-cloud that's ill-suited for most early stage companies. Especially in the age of "serverless" that has folks thinking they don't need people to worry about infrastructure. Perhaps we'll start seeing a new crop of post-mortems from the "fail fast" type of startups failing due to cloud over-dependency issues. They're (presumably rare) edge cases, but easily fatal to an early enough startup.