Old timers know - eviltoast
  • Krakaval@jlai.lu
    link
    fedilink
    English
    arrow-up
    27
    ·
    5 months ago

    Somehow I miss those days. Now you need weeks of training to understand the black magic behind all the build/deployment stuff in whatever cloud provider your company decided to use…

    • xtapa@discuss.tchncs.de
      link
      fedilink
      arrow-up
      1
      ·
      5 months ago

      We got our own platform based on kubernetes and cncf stuff and we don’t have to care anymore about the metal underneath. AWS? OTC? Azure? Thats just a target parameter, platform does the rest. It’s great.

      • widerporst@feddit.de
        link
        fedilink
        arrow-up
        2
        ·
        5 months ago

        How often do you switch cloud providers that this is even a real rather than a hypothetical benefit? (Compared to the cost of dealing with a much more complicated stack.)

        • bamboo@lemmy.blahaj.zone
          link
          fedilink
          English
          arrow-up
          2
          ·
          5 months ago

          I manage a stack like this, we have dedicated hardware running a steady state of backend processing, but scale into AWS if there’s a surge in realtime processing needed and we don’t have the hardware. We also had an outage in our on prem datacenter once which was expensive for us (I assume an insurance claim was made), but scaling to AWS was almost automatic, and the impact was minimal for a full datacenter outage.

          If we wanted to optimize even more, I’m sure we could scale into Azure depending on server costs when spot pricing is higher in AWS. The moral of the story is to not get too locked into any one provider and utilize some of the abstraction layers so that AWS, Azure, etc are just targets that you can shop around for by default, without having to scramble.