2020年DevOps云解决方案现状
每家公司都声称拥有云/混合DevOps平台，使开发人员能够远程工作。是时候整理一下混乱了。*
在当今的数字时代，软件推动着商业创新。软件交付过程的成熟度、速度、质量和安全性已经成为这个软件驱动经济中的关键区别。COVID-19的现实推动了市场更快地采用远程开发人员对IT的访问。因此，软件供应商都在竞相启用和扩展云DevOps解决方案。越来越多的团队寻求采用端到端DevOps平台或者减少他们对多个供应商的依赖和工具基础设施所有权的工具包。但是，企业应该从什么方面提出要求呢云DevOps工具，应该考虑哪些关键的区别?
在这里，您将获得当今可用的云DevOps平台解决方案的高级概述，以及在您的云DevOps旅程中您应该从供应商那里获得什么。
*本信息基于JFrog的研究，并反映了截至2020年4月市场上可用的解决方案。
企业云开发运维转型需要考虑的6件事
虽然JFrog有云产品(在每个公共云提供商和全球20多个地区)作为这些需求的解决方案，但在与任何一个DevOps数字化转型到云的供应商合作时，您应该考虑以下6件事。
- - -端到端- - -
点解决方案可以在一个或几个特定的事情上做得很好。但是云中的端到端DevOps平台应该达到运行时，具有单一的策略和支持点。自己集成遗留的DevOps系统可能会产生意大利面条式的解决方案——包括CI/CD。保持简单和快速。重要的是，这还包括DevSecOps的安全性内置了功能，否则对你来说可能是不可能的。
今天的开发人员正在寻找一个端到端解决方案和一个“一体化”的用户体验，但这并不意味着他们会在“最佳品种”的方法上妥协。因此，DevOps平台提供商除了提供强大的生态系统集成和插件之外，还应该提供a类工具堆栈作为其平台的一部分，以使开发人员的生活更轻松，尊重他们想要的选择自由。
端到端平台还要求供应商承诺提供真正的“单一浏览器解决方案”，而不是简单地将工具捆绑在一起进行集成。这确保了用户将从连接所有服务的单个UI中获得完整的体验。
- - -2022年世界杯预选赛赛程表通用包管理- - -
你的众多技术中的所有元数据和依赖项都必须得到支持(比如Docker、npm、Maven、PyPi，GolangNuGet,柯南等等，但也用于20+多种类型你可以在你的投资组合中找到。针对单一或有限技术类型的点解决方案只会使您的开发团队感到沮丧，并且需要在您的组织中采用多个解决方案和存储库。大型企业不仅拥有无数的技术，而且还拥有长期部署的任务关键型应用程序，这些应用程序必须得到本地、远程和虚拟存储库的大规模支持。
现代DevOps团队支持整个组织，并使越来越多的实体(有机的和无机的)能够轻松地与所有二进制类型的单一事实来源一起工作。
- - -完全混合:100%相同的这里，那里- - -
这与是否有云解决方案无关。许多提供云解决方案的公司没有相应的本地/自托管选项，反之亦然。更多的是完全独立的解决方案，提供不同的功能和不同的方法，彼此之间互不交流，要求你学习新的产品、用户体验和用户界面。当您过渡到云环境时，两者都是云和内部部署需要能够在100%的时间内以相同的方式工作，以确保顺利过渡(例如，当您经历一个云迁移并且需要在这两个地方使用相同的工具和功能来保持业务运行)。这比听起来要复杂得多，需要相同的代码库、相同的QA流程、相同的架构以及跨环境的更多内容。您还应该寻找支持的提供商多个区域和云一个真正的混合解决方案，是可访问的。
- - -多重云- - -
大多数JFrog的企业客户在使用单一提供商时都有一个非常明确的策略:他们不会允许自己承担只在一个云上托管DevOps和远程it工作空间的风险。虽然您可能认为一个云就足够了，但您应该选择一个跨所有主要云提供服务的供应商。通过避免任何供应商锁定并提供最大的弹性，保持您的选择开放和内心的平静。(如果需要，这对于云之间的迁移策略也很有用。)这种“DevOps民主”方法还允许您的组织拥有一个可扩展和伸缩的弹性工作空间，以实现真正的DR设置。
- - -安全- - -
DevSecOps不只是一个流行语。这是必须的。作为支持所有包类型的管道的集成部分，安全性现在是许多公司的一个项目。将离开是针对整个DevOps组织的，所以你应该考虑让它变得简单的工具。例如，云DevSecOps工具应该能够阻止包含漏洞的工件下载(或破坏构建)，这需要与存储库紧密集成。安全策略应该易于跨存储库定义和管理。任何云安全解决方案都应该允许您轻松识别整个DevOps管道中漏洞的影响。
DevSecOps中一个经常被忽视的类别是开源许可遵从性问题。软件包不仅可能包含漏洞，还可能包含未知的许可问题。解决方案应该为这两种类型的策略提供扫描和修复。
确保你在这方面所做的任何选择都能满足所有这些需求，并对开发人员具有充分的可视性甚至进入他们的ide-以达到最高的效率和内心的平静。
容器世界也带来了挑战。你的DevSecOps工具应该能够“打开”任何容器并扫描多个层，并与所有包查找包含漏洞的依赖关系。这只能通过与二进制代码库和工件管理工具的强大集成来实现。
扫描解决方案仅与驱动它的漏洞数据一样好!无论是云还是自托管，您都不能在仅包含市场上报告的部分信息的数据库上妥协。DevOps平台应该始终努力走在任何黑客和开发者的前面确保从构建到生产过程中的所有软件包的安全。
- - -云计算CI / CD- - -
可以集中和简化所有流程的大规模工具是现代的必需品。管理每个项目并创建孤岛DevOps管道自动化可能会让团队效率低下和沮丧。
传统上，应用程序开发团队负责创建本地化的CI/CD自动化。这种方法为单个团队提供了短期收益，但最终成为长期的约束，因为企业在其CI/CD实现中没有获得规模经济。
随着企业转向异构的现代体系结构、更小的部署单元、快速的发布周期和多云拓扑结构，这种情况会被放大。在这个美丽的新世界里，为每个部署单元构建特别的、定制脚本化的管道并不是一种可伸缩的方法，而且会导致创建和维护成本高昂的自动化，最终成为变革的障碍。
现代CI/CD提供商应该支持和扩展企业范围的工作流(又名“软件供应链”)，这些工作流跨越当今所有流行的技术和体系结构，并与技术发展保持同步。它应该提供一种从预包装的构建块(想想乐高积木)组装管道的方法，而不是从头开始开发管道。这些管道可以被模板化，并作为库在整个组织中共享，从而构建一个不断增长和改进的知识库。换句话说，您的CI/CD提供商应该在云中为您提供规模经济，并帮助您更快地发布代码。
比较基于云的端到端DevOps解决方案
今天有无数的工具可供从业者使用，如果您不做功课，那么选择最好的工具可能是一个反复试验的练习，需要花费太多的时间和精力。JFrog目前在AWS、Azure和GCP上提供云产品(以及与之合作)，这使您能够灵活地专注于端到端DevOps管道。下面，您将发现某些解决方案的“单打独斗”如何使您的目标受到挑战或不完整，而完全集成的云方法可能更完全地满足您的需求。
让我们来看看当今市场上一些最流行或最熟悉的选择，并将它们与什么进行比较JFrog正在做。剧透:我们将在接下来的几周内单独研究这些解决方案。
- - -JFrog vs GitHub- - -
来自微软的GitHub提供了一个端到端解决方案，包括源代码、(一些)包管理和CI/CD管道——这些被称为GitHub Actions。GitHub在SaaS上比它的自托管安装(GitHub Enterprise)更强大。除了支持自托管运行程序外，GitHub Packages和GitHub Actions目前仅作为SaaS提供，它们的自动安全更新功能也是如此。但是，action和Packages只提供基本的API支持，它们的CLI还处于测试阶段。
从存储库管理的角度来看，Github不是一个通用的解决方案，它只支持6种包类型(JFrog平台支持25种以上)，没有全局搜索功能，也不支持虚拟/远程存储库。它们的安全功能仍处于初级阶段，它们不提供对工件和容器映像漏洞的深度递归扫描，不解决许可证遵从性问题，也不配置触发不同操作的安全策略。
最后，GitHub的CI/CD解决方案不支持管道可视化，其源代码存储库和管道配置之间的紧密耦合使得企业扩展和跨团队/应用程序协作和管道共享变得困难。缺乏Docker层缓存或CI节点的自动伸缩进一步使云原生交付更慢、更麻烦。
GitHub在源代码管理、OSS团队协作和小型团队方面似乎是最强的，而它覆盖交付范围的企业能力仍在不断涌现。
- - -JFrog vs Azure DevOps- - -
同样由微软开发的Azure DevOps套件提供了一个端到端的解决方案——从源代码(Azure Repos)到工件管理(Azure Artifacts)再到CI/CD (Azure pipeline)。另外还有用于计划和跟踪团队工作的Azure Boards，以及用于测试解决方案的Azure Test Plans。
从一个构件管理从角度来看，Azure DevOps只支持四种二进制或包类型，并且没有为扫描提供持续的安全解决方案软件漏洞或者违反许可法规。
Azure DevOps是免费提供给每个Azure订阅的，或者为OSS项目提供最多10个并行作业。虽然Azure pipeline可能是微软仅在Azure云上进行标准化的明显选择，但它对关注供应商锁定或(正确地)准备支持未来多云和混合环境的组织提出了挑战。
微软缺乏对混合环境的支持，本地/自我管理版本缺少SaaS版本的许多核心特性。自我管理的版本不明显，也不经常维护。
- - -JFrog vs AWS & JFrog vs GCP- - -
AWS和GCP通常被视为高质量的基础设施和市场提供商，它们提供了一些与DevOps相关的服务和工具，但它们的解决方案并不打算提供集成或完整的DevOps平台。相反，主流云倾向于提供部署前的“最后一站”，而不倾向于提供整个Devops周期的服务。虽然有些解决方案，如简单的容器注册表和非常基本的CI/CD工具是可用的，但缺乏(或有限的)混合选项，有限或缺少软件包支持，可能的单一提供商锁定问题，缺乏企业级内置DevSecOps或安全解决方案，缺乏扩展元数据和缺乏软件分发解决方案，使大多数企业在寻找全面的提供商时犹豫不决。
值得注意的是，AWS和GCP都没有为开发人员提供包管理器(目前都只提供简单的包管理器)容器注册不支持Helm(或通用、虚拟或远程存储库功能)，更不用说通用包支持了。2022年世界杯预选赛赛程表一个通用的、混合的、生态系统集成的包管理器，具有先进的复制功能和全局分发功能，对于今天的DevOps商店来说是必须的，因为公司希望容器、Kubernetes和完整工件生命周期的管理。因此，他们会发现这些主要供应商在许多领域都存在不足。
在核心层面上，主要云提供商的DevOps解决方案主要集中在与他们提供的通用服务(消息、数据库、API网关、存储等)的集成上，以推动这些服务的更多使用。因此，这些服务在本质上大多是通用的，许多任务留给用户(关于工作流、元数据和可见性等)，以实现从代码到产品的真正端到端管道。这种缺乏重点也可能影响提供的成熟度和质量DevOps的工具，通常将它们留在非常基础的水平上。
从根本上说，AWS和GCP似乎都没有提供端到端的DevOps解决方案，也没有提供编排和管道管理工具。这使得许多公司依赖第三方或自己承担工具的缺陷——对许多企业来说，这是一种不可扩展的解决方案。
大多数情况下，我们看到公司利用云提供商和JFrog这样的公司之间的合作伙伴关系来提供端到端解决方案——通常是通过云市场。
- - -JFrog vs GitLab- - -
GitLab主要以GIT解决方案而不是DevOps平台而闻名，它提供的SaaS产品仅限于单一地区的单一提供商(GCP)。因此，虽然技术上是可用的，但企业可能会发现很难采用这种有限的产品。也没有明显的SLA保证，导致任何企业都缺乏确定性。GitLab的安全产品也处于起步阶段(尽管在不断改进)，为企业寻找关键任务工作负载的可靠解决方案留下了一个问号。此外，拥有多个SCM工具是非常常见的，并且GitLab可能会限制使用各种源代码控制工具的企业的范围。随着GitLab解决方案迁移到云端，多个租户共享一个数据库资源，问题变得更加复杂，这可能会导致扩展和/或性能问题。
GitLab的优势主要是内部部署，云选项非常有限。虽然是一个坚实的平台，但GitLab在企业云可扩展性、混合能力、SLA保证和SCM兼容性方面存在不足。
此外，GitLab不支持开发人员所需的许多包类型，这可能需要进一步的工具来支持不同的项目。这不是一个小缺点，而是触及了企业最重要的需求之一——同时大规模地支持无数语言、系统、合作伙伴和技术类型的需求。当查看GitLab的演示时，虽然他们提供了一个基本的包管理器，但他们承认JFrog是包管理领域的领导者。作为任何DevOps管道的心跳，像JFrog Artifactory这样的包/二进制管理器是关键技术，它允许公司实现企业规模、定制和自动化，并有效地满足最苛刻的sla。在全球范围内，许多公司需要混合的多云工具来支持高效复制、多种缓存选项、多种存储库类型(本地、虚拟和远程)、丰富且可查询的元数据等等。如果没有这个健壮的工件管理器作为拼图的关键部分，大多数企业将发现GitLab的产品缺乏企业工作负载。
此外，GitLab的平台增强策略似乎依赖于外部资源，即使是主要的功能更新。这可能会导致核心团队之外的人员增加，而这些人员可能没有长期的平台路线图、愿景或企业规模。
此外，GitLab产品架构本身依赖于单个服务器。该服务器必须支持不同系统需求的DevOps工具，例如I/O和数据库负载、请求缓存和吞吐量、处理能力、可用性等。
将I/ o密集型、高请求率、零停机服务(如企业二进制管理器)与报告/数据显示服务(如问题管理、wiki、代码审查和请求跟踪)混合在一起，往往会导致复杂的规模和性能问题，因为这些服务在相同的资源上竞争。2022世界杯阿根廷预选赛赛程
最后，对于希望跨云扩展或避免任何提供商锁定的企业来说，缺少SaaS的多云功能可能是一个问题。
那现在怎么办?
我们相信DevOps云解决方案应该拥有一切——在所有的云上，适用于每个开发人员的环境。无论开发人员身在何处，都需要这种高度的灵活性和健壮性。但这是JFrog的博客，所以这些事实都是基于我们自己的研究。我们欢迎你对这个话题的评论和想法。
