• rainwall@piefed.social
    link
    fedilink
    English
    arrow-up
    29
    arrow-down
    2
    ·
    edit-2
    1 day ago

    Only if you engineered your stack using vendor neutral tools, which is not what each cloud provider encourages you to do.

    Then the adminstrative overhead of multi-cloud gets phenomenally painful.

      • rainwall@piefed.social
        link
        fedilink
        English
        arrow-up
        8
        ·
        edit-2
        20 hours ago

        Yeah, Terraform or it’s FOSS fork would be ideal, but many of these infrastructures are setup by devs, using the “immediately in front of them” tools that each cloud presents. Decoupling everything back to neutral is the same nightmare as migrating any stack to any other stack.

        • felbane@lemmy.world
          link
          fedilink
          arrow-up
          3
          ·
          14 hours ago

          Definitely. I go through that same nightmare every time I have to onboard some new acquisition whose devops was the startup cfo’s nephew.

      • Lysergid@lemmy.ml
        link
        fedilink
        arrow-up
        2
        arrow-down
        1
        ·
        16 hours ago

        Infrastructure is there to be used by apps/services. It doesn’t matter how it’s created if infrastructure across providers does not provide same API. You can’t use GCP storage SDK to call AWS s3. Even if API would be same, nothing guarantees consistent behavior. Just like JPA provides API but implementations and DBs behavior are inconsistent

        • felbane@lemmy.world
          link
          fedilink
          arrow-up
          2
          ·
          14 hours ago

          You can use the S3 API to interop with basically every major provider. For most core components there are either interop APIs or libraries that translate into provider-native APIs.

          It’s 100% doable to build a provider-agnostic stack from the iac all the way up to the application itself.