流行的开发平台GitLab得出结论，公共IaaS云不是一个有效的平台，以托管其高输入/输出需求的开源文件存储系统。所以，GitLab放弃了云计算。
在一个解释这一决定的博文GitLab的工程师们说，他们将把他们的CephFS存储工具转换为裸金属基础设施，他们将自己管理。GitLab提供了一个平台来帮助开发团队编写、测试和发布代码。
GitLab的存储问题是一个主要的例子，说明并不是所有的工作负载都适合于公共云。GitLab并不是第一家将应用程序从公共云中取出的公司;例如，DropBox今年早些时候宣布，计划建立自己的云平台，而不是使用亚马逊网络服务的云。尽管如此,许多其他企业正全力投入云计算．
这些相互冲突的例子强化了这样一种观点:每个公司都必须评估自己的环境，以确定云是否适合他们的组织。
+更多关于网络世界足球竞猜app软件：关于微服务你需要知道什么+
GitLab的工程师写道，GitLab的CephFS需要一个“真正性能好的底层基础设施”。“通过选择使用云，我们默认与许多其他人共享基础设施。云是分时的，也就是说，你可以和其他人共享提供商的资源。”因此，服务提供商必须确保每个人都得到公平的时间分配。为了做到这一点，供应商对他们提供的服务设置了性能限制和门槛。”
GitLab尝试在云上运行CephFS(它没有指明是哪一个)，但表示该应用程序成为共享服务器上CPU使用的“嘈杂邻居”请求峰值。“我们成了那种把音乐放得很大声很晚的邻居。因此，我们受到了迟到的惩罚。”博客中的一张图表显示，CephFS的延迟范围从大约10秒到一分钟不等。
GitLab
该图显示了GitLab的存储平台托管在云中时的不一致延迟。
传统观点认为，公共云适合需求可变的可扩展工作负载。资源可以根据需要增加，在负载下降时退役;与此同时，用户只需支付所需的基础设施费用。但是GitLab发现了一个问题:扩展资源需要时间。“我们发现，是的，你可以继续生成更多机器，但这是有时间门槛的，特别是当你增加了沉重的IOPS时，这会变得更低效和非常昂贵。你还得花钱买更大的机器。云的本质是时间共享，所以您仍然无法获得最佳性能。归根结底，你花了很多钱来获得低于标准水平的服务，同时还需要更多的性能。”
为了保护公共云供应商，终端用户可以通过一些方法来确保其应用程序的基础设施性能。例如，在AWS的云服务中，客户可以支付额外费用在专用的基础设施上运行应用程序不与其他用户共享。客户还可以通过Amazon EBS provisioned IOPS(公司的弹性块存储服务)支付额外费用，获得每秒有保障的供应输入/输出。然而，这两种场景都比随需应变的虚拟机实例或标准的非供应IOPS存储更昂贵。
GitLab向自管理裸金属服务器的转变也将面临挑战。该公司将预付服务器基础设施的资本成本，然后必须计划维护和替换它们的成本。云计算将用户从这些义务中解放出来，并将基础设施变成运营费用。但对于GitLab来说，运行自己的基础设施的稳定可靠性能比这些挑战更重要。