How We Knew It Was Time to Leave the Cloud
I appreciate that you didn&#x27;t sling mud at Azure, but re-reading the commit for the move to Azure [1] there were tell tale signs then that it might be bumpy for the storage layer.<p>For what it&#x27;s worth, hardware doesn&#x27;t provide an IOPS&#x2F;latency SLA either ;). In all seriousness, we (Google, all providers) struggle with deciding what we can strictly promise. Offering you a &quot;guaranteed you can hit 50k IOPS&quot; SLA isn&#x27;t much comfort if we know that all it takes is a single ToR failure for that to be not true (providers could still offer it, have you ask for a refund if affected, etc. but your experience isn&#x27;t changed).<p>All that said, I would encourage you to reconsider. I know you&#x27;re frustrated, but rolling your own infrastructure just means you have to build systems even better than the providers. On the plus side, when it&#x27;s your fault, it&#x27;s your fault (or the hardware vendor, or the colo facility). You&#x27;ve been through a lot already, but I&#x27;d suggest you&#x27;d be better off returning to AWS or coming to us (Google) [Note: Our PD offering historically allowed up to 10 TiB per disk and is now a full 64 TiB, I&#x27;m sorry if the docs were confusing].<p>Again, I&#x27;m not saying this to have you come to us or another cloud provider, but because I honestly believe this would be a huge time sink for GitLab. Instead of focusing on your great product, you&#x27;d have to play &quot;Let&#x27;s order more storage&quot; (honestly managing Ceph has a similar annoyance). I&#x27;m sorry you had a bad experience with your provider, but it&#x27;s not all the same. Feel free to reach out to me or others, if you want to chat further.<p>Disclosure: I work on Google Cloud.<p>[1] <a href="https:&#x2F;&#x2F;gitlab.com&#x2F;gitlab-com&#x2F;www-gitlab-com&#x2F;merge_requests&#x2F;1097&#x2F;diffs" rel="nofollow">https:&#x2F;&#x2F;gitlab.com&#x2F;gitlab-com&#x2F;www-gitlab-com&#x2F;merge_requests&#x2F;...</a>